Thanks for the correction, I'm still new to iroh and looking to learn more!

Seems that the relays in iroh play the role of STUN and TURN (maybe even implement these)?

I'd have to read more about DNS discovery (and dht), very interesting.

I work on connet [1] and from what I've seen iroh seem pretty cool. A few random thoughts I had while watching the presentations/reading the docs:

* the relays serve both for discovery and relay. In connet these are separate responsibilities, e.g. it has control server for discovery and a relay server for relaying connections.

* it seems that the connections to the relays in iroh are TCP (at least what was said in one of the videos), while connet uses QUIC in all cases. This probably makes iroh more resilient, but multiplexing on top of TCP might suffer from head of line blocking.

* it is pretty cool that iroh can seamlessly upgrade from relay to direct connection, connet doesn't do that on a connection level. It will however use direct in the subsequent virtual connections.

* using ALPNs for protocol selection is pretty cool, connet only offers "virtual connections" protocol, where one of the peers is "server" and the other is a "client".

* since there is a separate discovery server (with auth), in connet the endpoints are named separately with logical names, they don't represent peers necessarily. Because of this, you can have multiple peers with "server" role and "client" roles.

Anyhow, thanks for posting this, iroh looks great and I will draw some inspiration from it for sure.

[1] https://github.com/connet-dev/connet

Looks very cool. Another self-hosted, open source, and private solution in this space is my own https://github.com/connet-dev/connet/

connet itself doesn't have a notion of public share at all - you need clients/peers on both ends (destination and source) to "project" a remote service. connet.dev do enhance this, by running the source clients publicly, but you need to specifically enable this, and it is best used as a break-glass option, since obviously makes things less-private.

In any case, zrok.io is cool, it is certainly more mature and feature rich project.

If I understand correctly the terminology/case, all shares in connet a private. You access a remote resource as it was local, but that doesn't mean the resource is publicly visible. For example, my local network clients, do not need public IP or special firewall rules to communicate with remote clients.

What I was describing above is a specific way to route traffic - by default if direct connection between clients can be made (e.g. peer-to-peer), connet uses that. However, in cases where this is not possible, connet can use relays to send traffic between peers. In this scenario, you can in addition encrypt traffic end-to-end, so if you are using a public/untrusted relays, the relay itself cannot inspect/see traffic between peers.

Of course, you can also configure peers to never use relays and always communicate directly. A relay (or a third-party) is only used when both peers allow it and no direct route can be used.