https://github.com/connet-dev/connet

Just finished a major (v0.10) revamp of the API (you can use connet as part of an application, not through the CLI) which also fixed a few issues I've been seeing before.

Now, I'm gearing to update the relay protocols - currently relays are closed off by the control server (e.g. you ask it to provision you a relay resource) which requires the relay to communicate with the control server itself. In the new version, the relays will be operating on their own (there might be a shared secret with the control server, in case you want a closed off relay) and peers will reserve directly with the desired relays. Maybe in future, the relays might form clusters on their own to take advantage of better relay-to-relay network and peers will reserve only at the relay closest to them.

Another stream of work, is giving peers identities. Right now the server will give them an internal identity to better support reconnects, but these are not stable (e.g. they don't survive client restarts). In future, the peer will advertise their identity and then other peers may choose what peers to allow comms with and what to ignore, pushing more decisions into peers themself.

Yet another change I'm thinking about is exposing raw endpoints to enable users of the system to implements other protocols - I'm not quite sure if this is really needed (the destination/source, e.g. server/client) covers a lot of ground by itself, but it would be great if these are not the only options.

Many options how to continue, but if I'm out of ideas, there is always a Rust rewrite to throw in /s

Actually, I realized that I've used `/s` incorrectly. I've been thinking about rewriting the clients in Rust, mostly to allow simpler embedding in other languages - java and swift for example (I think it would be great if connet was available on mobile - for android you can Termux to compile/run it, but it is a pain). This will make it harder to embed in golang tho.

Another option is to try to rewrite clients in each of the language, but most fare poorly on QUIC support - in Java for example, I'm not aware of one that is advertised as production ready (looking at kwik with their fork of TLS).