61 ms·

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

by gz5 3mo ago

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 3mo ago
> 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/a6e5f1697a9dc34a41c1ed398d667b349f2b04b4/example/chat-p2p/setup.go https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... wrong, it seems to require a "controller-url", is that controller embeddable as well?
- gz5 3mo ago
  yes, openziti includes a full mesh, programmable overlay. agree not all apps need that.
  - embedding-shape 3mo ago
    > 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 3mo ago
      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 3mo ago
        Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a41c1ed398d667b349f2b04b4/example/chat-p2p/setup.go 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 3mo ago
        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 3mo ago
        > 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.

by gz5 3mo ago

embedding-shape 3mo ago

> 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/a6e5f1697a9dc34a41c1ed398d667b349f2b04b4/example/chat-p2p/setup.go https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... wrong, it seems to require a "controller-url", is that controller embeddable as well?

gz5 3mo ago
yes, openziti includes a full mesh, programmable overlay. agree not all apps need that.
- embedding-shape 3mo ago
  > 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 3mo ago
    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 3mo ago
      Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a41c1ed398d667b349f2b04b4/example/chat-p2p/setup.go 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 3mo ago
        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 3mo ago
        > 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.