Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iroh 1.0

iroh.computer

Post reply on HN
Print view View original

471–480 of 488 posts

Re: Iroh 1.0

#471

Post by dovholuknf »

embedding-shape wrote: post #469
dovholuknf wrote: post #464

Earlier quoted context omitted.

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 movi…

> 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 w…

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!

Re: Iroh 1.0

#472

Post by PLG88 »

embedding-shape wrote: post #470
PLG88 wrote: post #461

Earlier quoted context omitted.

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

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

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.

Re: Iroh 1.0

#473

Post by keepupnow »

40four wrote: post #405
Thaxll wrote: post #46

I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS. There is already IPv6 and quic, you need vendor and major software to have any traction in that field.

I’ve recently been building some hobby projects that focus on local first, decentralized architecture and that’s how I discovered Iroh. In my apps, I want the user data to be stored local only, no server, and have p2p sync ability. So for something like that, Iroh appears to be the state of the art.

local-first, offline-first, no server holding the data and simply p2p sync is a great shout for projects. Have you thought any further about it?

Re: Iroh 1.0

#474

Post by bsenftner »

GreenWatermelon wrote: post #466
bsenftner wrote: post #394

Earlier quoted context omitted.

That amazement is due to one of our largest and least realized critical mistakes as a civilization: no where are people taught how to effectively communicate. We have entire Colleges of Communications at every university, and what do they teach? How to execute mass manipulation, not how to convey understanding, not how to manage disagreements. These are not "mistakes" either, this distinct lack of teaching real commu…

Is the LLM-tone of this comment intentional? Or is it just how you normally write? Honest question.

It is how I write. This is what happens when one gets 7 college degrees, people accuse you of writing with AI. I've even been accused of rehearsing AI for how I talk; no, that is how I talk.

Re: Iroh 1.0

#476

Post by tecleandor »

apitman wrote: post #255

If you're new to Iroh, my mental model is roughly "Tailscale at the application layer instead of the network layer". If your question is, "why not just use Tailscale?", look at it from an app developer's perspective. If you want to release an app and have instances of your app be able to easily connect to each other, you could theoretically embeded Tailscale functionality into your app, but then the users of your app…

Well, Iroh is more P2P (direct connections) and less VPN (subnet routing).

If anyone really wants to use Tailscale (or I think Headscale should work too) at application layer, you can use tsnet [0]

--

  0: https://tailscale.com/docs/features/tsnet

Re: Iroh 1.0

#478

Post by ben-schaaf »

kkapelon wrote: post #467
ben-schaaf wrote: post #163

Earlier quoted context omitted.

Everyone I'd like to connect to isn't on my tailscale, nor do I want them to be.

They don't need to be https://tailscale.com/docs/features/tailscale-funnel For this simple scenario (just exposing your laptop to a public IP) there are already a gazillion alternatives (e.g. ngrok)

Funneling means opening up the device for the entire internet to access, not just to those with my public key like in iroh. It's limited to 3 ports. It requires setup for each device. It's not peer-to-peer. It has throttled bandwidth.

No, this does not do the same thing as iroh. Not even close.

Re: Iroh 1.0

#479

Post by wronex »

Me and my friend wanted git for a game project. Setting up a VPN for this felt overkill. Turns out git provides a very nice transport abstraction though. So I built an iroh transport for git. Now we can push directly to a shared repo running on an old computer behind NAT. All for free.

https://github.com/wronex/iroh-git

Re: Iroh 1.0

#480

Post by kkapelon »

ben-schaaf wrote: post #478
kkapelon wrote: post #467

Earlier quoted context omitted.

They don't need to be https://tailscale.com/docs/features/tailscale-funnel For this simple scenario (just exposing your laptop to a public IP) there are already a gazillion alternatives (e.g. ngrok)

Funneling means opening up the device for the entire internet to access, not just to those with my public key like in iroh. It's limited to 3 ports. It requires setup for each device. It's not peer-to-peer. It has throttled bandwidth. No, this does not do the same thing as iroh. Not even close.

The goal posts keep moving.

First iroh was marketed as "solves communication behind NAT". Then we went to application level NAT busting vs node level NAT busting. Then we went to distributed vs client-server, then we went to stable IPs for non-server devices (your original comment). Now we moved to "true peer to peer" and "public keys".

This just tells me that the marketing site doesn't explain what Iroh actually does.

The fact that so many other people (apart from me) asked about the connection to Tailscale is also interesting.

Post reply on HN