After some weeks of prototyping, what are the results?

Libp2p as such was working as specified. Nevertheless, there are couple of issues regarding the Mles protocol:

1. frame check works only for the frames we receive on the channel

This means that to be able to check the validity of the first frame, the server would need to be on the same channel as the clients. This is problematic, as the channel should be selected by client to be anything…

OK, let’s assume that we pick reserved “__mlesv2” channel for the first frames. It looks hacky already, but anyway, what would work or not? And we come to the second issue:

2. retransmit during reconnection does not work per channel

For new clients, we cannot really select any connection to send to as there no existing api to publish only to a peer. The server would need to flood the network to be able to send the message history to a new client. And if we have the “__mlesv2” way of communication, all clients of any channel would receive them. Not a way to go.

Well, that’s what prototyping is for. We quickly spot possible issues with the design.

When I think about it, perhaps a simple TLSv1.3 connection would be fine even for direct server connection. There is some hassle with the certificates, but it may be possible to use the TLS-ALPN-01 way for public server and manual methods otherwise.

If no one comes up with a better idea, this is in the focus of next prototyping effort and very likely the first alpha implementation for Mles v2.

Comments are welcome! You can also comment if you think this is the way to go!