[dovholuknf]

OpenZiti has numerous SDKs. If you are a developer and you can integrate an SDK into your application, it 100% is application-embedded. It is incorrect stating that it can't be app-embedded... (i am a maintainer on the project). Perhaps I just don't understand the response?

[embedding-shape]

Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... mentions a "controller url", I'm assuming it's just the particular example then and in reality you could build and ship one golang binary that doesn't require any other external processes to connect the two processes together via OpenZiti?

[PLG88]

I’d separate “app-embedded” from “no external coordination.” OpenZiti SDKs are app-embedded: the app can directly dial/bind Ziti services without a local tunnel daemon. Ziti also supports tunnelers and non-embedded options where app modification is not practical. But yes, the app is still participating in a Ziti network with controllers, routers, services and policies.

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.

So to me the distinction is not “embedded vs not embedded”; both can be embedded. It is “P2P connectivity substrate” vs “governed zero-trust service overlay.” Iroh optimises for low-friction key-based peer connectivity. OpenZiti optimises for centrally governed, least-privilege service reachability, including identity lifecycle, revocation and policy control at fleet scale.

Note, I also work for NetFoundry, which develops and maintains OpenZiti.

[embedding-shape]

> 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.

[PLG88]

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.

[dovholuknf]

At this time OpenZiti still operates in relay pattern. All your traffic travels through an OpenZiti router. It's also a zero trust overlay so having an external server is important to make policy decisions about whether an identity is authorized to dial a service or not. OpenZiti also allows for bespoke pathing via OpenZiti routers so that path traversal over the overlay is also coordinated.

The project has been moving to supporting directly connecting to other identities but it hasn't been a priority yet.

The connections an OpenZiti identity makes to another OpenZiti identity are direct-over-OpenZiti (not direct over IP underlay) if that makes sense. I don't know if you'll ever be able to have two process communicate without that third 'arbiter' process (I'll call it). It might happen, but right now it seems less likely than the direct connect approach.

hope that helps. But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.

[embedding-shape]

> But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.

Yes, but that's the thing, when people say "Iroh lives in the app" they mean the entire thing, the relays are optional hole-punching mechanisms, otherwise it is distributed P2P embedded in the app. It's slightly confusing when you claim OpenZiti to be the same, with "fully app embedded" but in reality there is a server/overlay/controller/coordinator running somewhere that isn't actually embedded in the app.

I'm not saying the idea is bad, I think both have their use cases, OpenZiti seems like a solid project otherwise, I'm not trying to say it's a bad choice. I'm merely trying to help you, as an outsider, to maybe use/don't use certain words/definitions when you talk about it as it gets confusing then once you actually start looking at the code and things look very different from the expectations you set.

I do wish you luck with the project, all sorts of P2P projects are needed and they all have their place, I don't think it's a "one eats them all" ecosystem, and the more the merrier :)

[dovholuknf]

I appreciate your thoughtful reply and I didn't think you were tossing any shade for what it's worth. I was just arguing that to me, both are "app embedded". IMO, the fact that traffic relays or not to me is non-consequential, what's important is where the encryption starts and where it ends (and where authorization happens but that's also separate). If it starts the client and ends at the 'server' then it's fully e2ee -- it doesn't matter if traffic traverses only IP-based underlays or if it traverses over an overlay at that point.

I very much appreciate the "outsider" perspective though and thank you very much for sharing it. That perspective is impossible to obtain after you work on a project for long enough! :)

Cheers!