[gz5]

the closest comparison is openziti:

+ iroh and openziti can both be app-embedded

+ so the app developer embedding in their service is a good use case for both

+ openziti is used for services in which scale and security are critical

+ whereas iroh allows participation from parties which don't have any prior relationships - which can be very convenient

[embedding-shape]

> the closest comparison is openziti:

Except without all the ceremony about setting up daemons, servers, controllers, "networks" and what not that openziti seems to have. Iroh is more "define protocol and hook two clients together" with everything in one binary.

Unless I understand https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... wrong, it seems to require a "controller-url", is that controller embeddable as well?

[gz5]

yes, openziti includes a full mesh, programmable overlay. agree not all apps need that.

[embedding-shape]

> agree not all apps need that

It's less that "not all apps need that" and more that "openziti can be app-embedded" is actually completely false.

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

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