[Fabricio20]

One thing I seem to struggle to understand is, a simple invite code system is showcased, but how does host Alice in one country know how to contact host Bob in another country with just the invite code? This seems to require a coordination server at least right, or does the invite embed some sort of information that'd allow Bob to directly reach Alice with just the invite code?

[tom1337890]

Iroh or n0 seems to solve that. It's they're underlying network protocol. When you're behind some cgnat, iroh falls back to public iroh relays hosted by n0: https://docs.iroh.computer/concepts/relays#public-relays

However you could self host one of these on a public server you own. Then you're independent.

[polycancel]

Seems like nothing can really get around this without a server/relay/TUN/STUN server. Peer to Peer messaging just doesn't work otherwise.

Saw Iroh post on HN. Just wonder how it differ from Nostr, Scuttlebutt or Yggdrasil or DHT etc? Many from Nostr claim that they are successor of scuttlebutt, but many devs from Scuttlebutt highly dispute that.

Be good to get a comparison between these protocols for devs who want to use them.

[inigyou]

IPv6 gets around it!

[Groxx]

Stable IP addresses solve it as well, but these kinds of things are not generally aimed at contexts where those are an option. Even IPv6 isn't generally stable - the prefix is ISP-defined and tends to vary similarly to IPv4 with CGNAT.

There's also "dynamic DNS", which is basically just caching one side of that server/relay/TUN/STUN handshake, and relying on DNS for global discovery.

For Iroh vs Scuttlebutt / DHT, I'll break that into two parts:

1) Iroh uses DHT for host discovery: https://docs.iroh.computer/about/faq#how-is-iroh-different-f... , and Iroh is more about "use that DHT to get a usually-direct connection globally and then you can do whatever you want", while Scuttlebutt is strictly "... and use that connection to exchange append-only logs via gossip, to implement the Scuttlebutt protocol". (Iroh does have some first-party protocols you can use, but it's lower level in general)

2) Scuttlebutt isn't DHT-based, it's "connect to a known IP to get its data and discover connections" -> "connect to them and repeat..." -> "connect further..." -> etc, plus limited-hop feed replication by default. There isn't a global lookup to connect to any member or retrieve any data, it's all friend-of-a-friend connections and you can (and do) lose connection to someone if they get a new IP address and there's no F-o-a-F(-o-a-F(...)) replication route from them that reaches you (rare in practice since they likely re-connected to people they follow, which eventually trickles data through the mesh similarly to before). This is also part of the reason that it works instantly when you're on the same network as someone - it's less "it can work locally if you don't have internet access" and more "local is just a discovery method, the internet isn't special at all because it's all just direct connections".

And as far as I understand Nostr, it's conceptually similar to Scuttlebutt, but with direct support for centralizing for performance (relays) and some degree of mutability / forgetfulness / etc. Scuttlebutt is a bit extreme about its logs being immutable and the only way to exchange data, and it's part of the reason it can have rather major perf issues (like needing to pull gigabytes of data before you can discover a feed's display name). (I say this as a fan of Scuttlebutt in principle, but not in practice - there are lots of practical issues with existing implementations that could be solved, but haven't, and it's a large part of why the ecosystem split into other protocols)

It may also be worth pointing out that DHTs also need stable hosts to serve as initial bootstrappers, and apps that use them tend to hard-code a web URL where they can get a small list of those nodes. They just use them to discover other nodes, and save them for next time so the bootstrappers aren't constantly needed.

[Arqu]

One of the n0/iroh devs here.

Iroh doesn't use DHT as its main discovery mechanism. It uses DNS/pkarr and relays as the primary method. DHT is a separate feature if folks like to do that, we don't have it on by default and don't have it on the public relays.

The whole idea is p2p but trying to be realistic about what network environments actually look like.

[Groxx]

There has definitely been a lot of blind-idealism in a lot of P2P systems, yea. Though sometimes that's because it was/is just a PoC to see if it works at all, and then it grows too large to change / needs to be forked.

Iroh is definitely near the top of my "play with it some time" list, that pragmatism is very important for building normal things that normal people will be using :)

[polycancel]

> It uses DNS/pkarr and relays as the primary method.

Thanks for clarifying that. So does that mean Iroh still require a DNS server or domain name even though it doesn't rely on IP address?

I thought dial by key means the other party just need to be on internet and has the right key/pubic identifier then they can reached.

Where does the message resides if the other end is NOT online?

[Fabricio20]

I see, so a coordination server is necessary which kinda somewhat defeats the "mesh" claim, though I do wonder if achieving this in a manner similar to DHT could eliminate the centralized entity controlling the servers at least, allowing the "peer-to-peer mesh" claim to be there in spirit.

Not that I have anything against the software or company to be clear, just that I wish one of these p2p vpns would be _totally_ actually independent of any coordination server or central entity!

[drdexebtjl]

It’s not a coordinator server, it’s a relay, a dumb pipe, for when the peers can’t talk to each other directly because of a CGNAT.

Presumably you could disable it and the VPN would continue to work, just not on CGNATs.

[utilize1808]

I think for this kind of system to work, there has to be SOME kind of public/shared server to do the coordination. If the inviting node is behind a firewall then no amount of information can enable a guest node to connect to it without a node reachable by both.