undefined | Better HN

0 pointsembedding-shape9d ago0 comments

> Iroh is definitely lighter-weight and developer-first, but it is not always “two binaries and nothing else” either (at least from what I have read). Once you need arbitrary peers across NATs/firewalls, you may need relays, address lookup, relay URLs/tickets, and for production likely dedicated/authenticated relays.

Indeed, for hole-punching you need something external, I don't think anyone found an mechanism to do it without some "signaling" server or similar, if it's even possible at all.

> OpenZiti SDKs are app-embedded

I think this is a good clarification, the SDKs that communicate with OpenZiti are app-embedded, while the server/coordinator/whatever runs somewhere else. That's why the comparison with Iroh feels weird, as both the SDK+"server" runs embedded in the application (except if hole-punching is needed, then some external signalling server is needed, as mentioned earlier), so it is in practice, what the developer cares about, two binaries and not much else.

> So to me the distinction is not “embedded vs not embedded”; both can be embedded

This is where you lose me and others, as when they talk about Iroh being embedded, they do mean everything you need to say run a P2P chat application on two computers, there are usually no URLs/coordinators/whatnot involved there (again unless hole-punching is needed), while with OpenZiti you need that chat application + OpenZiti running. The distinction people are trying to understand is very much this, so it's confusing when you call it "embedded" while still having an external thing running alongside it.

0 comments

1 comments · 1 top-level

PLG889d ago

I dont disagree with any of that. I am thus thinking, I think the cleanest distinction is probably not “embedded vs not embedded”, or even “relay vs no relay”.

It is: who is supposed to control admission to the service?

Iroh seems great when the app itself wants lightweight peer connectivity: keys, protocols, NAT traversal, optional relays, and the application decides what those peers are allowed to do. That is especially attractive for local-first, ad hoc, P2P, or cross-party cases where there may not be a shared operator or prior trust relationship.

OpenZiti starts from a different assumption: there is a service owner/operator who wants to define which identities may reach which services, under which policies, with central lifecycle/revocation/routing control. In that model the controller/router fabric is not accidental ceremony; it is where the zero-trust service network is governed.

So I’d say Iroh is closer to “embed P2P connectivity into the app.” OpenZiti is closer to “embed a zero-trust service edge into the app, while the app participates in a governed overlay.”

Both are useful; they just optimize for different trust and operating models.

That said, I also dont think its useful that many in this thread are saying, more or less, 'Iroh is Tailscale at the application layer instead of the network layer'... based on my understanding of Iroh, which you have helped with, its not that at all as Tailscale also aims to provide centralised governance and orchestration.

j / k navigate · click thread line to collapse