Mles v1.0 has a hierarchical structure with a centralized-looking main server. It is in theory possible to have a ring of servers but that is not available anywhere at the moment and the such environment might become hard to maintain.

More optimal would be just being allowed to use peer-to-peering. The relevant features would be similar to 1.0 still, guaranteed message delivery for the message history and scalable publish and subscribe for the selected shared channel (i.e. topic) in a secure way. With the rise of crypto-blockchains, such peer-to-peer libraries are nowadays available, widely used, tested, and maintained, such as libp2p. As a protocol e.g. gossipsub with noise + yamux would be fairly good from the requirements perspective. Veilid is also a newer option, but is less documented at the moment.

In the end, the library implementations and their APIs matter the most. Libp2p in Rust allows to check messages received in their API and this would allow to check the SipHash checksum/authentication in the connection init.

The Mles v2.0 server itself would then listen to client connections and connect to bootstrap server (list) during startup. A good question is how would the clients connect then? They could indeed connect via a selected libp2p connection to port 8077 or via wss to port 443. A non-secure connection would not be allowed anymore.

Would this be then simple for clients to implement? I think so. Clients could be easily written with libp2p API or a netcat-like simple implementation could be created with websocat. A prototyping is needed to finish the details, of course. That’s enough for today. In case you end up prototyping the above things, let me know how it worked!