Live data from Hacker News

Iroh 1.0

iroh.computer

431–440 of 488 posts

Re: Iroh 1.0

#431

Earlier quoted context omitted.

> VPNs do not allow you to connect two devices directly, they have to go through the VPN Not true. Depends on the VPN protocol.

It sounds like the key difference people are missing is that VPN's operate at the network layer, so they require separate integrations for every device os/arch and network stack, where Iroh is embedded at the application layer, so any app can be a P2P VPN client without worrying about device network integrations. Sounds great to me, and would be a boon for self-hosting and decentralization in general, which is sorely…

[deleted]

Re: Iroh 1.0

#432

Earlier quoted context omitted.

It's backwards! Unlike webrtc, iroh doesn't work inside a browser. It's for the case where you have two native apps that need to talk to each other p2p. For browser / webapps you want webrtc.

> We built & continually check that iroh can compile to WASM & run in the browser

We do have browser support, but as of now it is relay only.

Re: Iroh 1.0

#433
post #62

Earlier quoted context omitted.

Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way. Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work. In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth a…

isn't this exactly what tailscale (and also zerotier, netmaker) do? https://tailscale.com/blog/how-nat-traversal-works

[deleted]

Re: Iroh 1.0

#434

Earlier quoted context omitted.

Is that not what libp2p already offers? Not sure if it has QUIC out of the box, but hole-punching to UDP connectivity and then running QUIC over it isn't that hard.

Libp2p does have quic, at least the rust implementation.

Will this be a boom for the web3 world as polygon and many others now uses libp2p now.

Re: Iroh 1.0

#435
post #401

Earlier quoted context omitted.

> "iroh is a modular networking stack written in Rust. You can omit the "written in Rust" part, but then you'd lose street cred.

It's not for street cred, it's what makes it usable everywhere: Rust, JavaScript (server or browser), Python, Kotlin, Swift, C. Written in JavaScript or Python means limited use, Kotlin or Swift means it could be tricky outside their main platforms, C means worrying about potential vulnerabilities and core dumps. I.e. "written in Rust" is definitely relevant here.

> C means worrying about potential vulnerabilities and core dumps

Rust guarantees no vulnerabilities?

Re: Iroh 1.0

#436
post #181

Earlier quoted context omitted.

Establishing fast/secure P2P connections between computers.

Establishing fast/secure P2P connections between ~computers~ *apps. If you want to connect 2 computers use Tailscale. If you want to write an app which offers peer to peer connection for some feature, then use iroh.

By far the most easy to understand explanation of iroh. I still kept thinking to myself "But why not just Tailscale?" when reading the other comments.

For me, I find more value in connecting computers together than connecting applications together, but I'm not building P2P apps...

Re: Iroh 1.0

#437
post #312

Earlier quoted context omitted.

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

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

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

Re: Iroh 1.0

#438
post #305

Earlier quoted context omitted.

No idea why this is downvoted, it's exactly the pitch for DNS. Others and I are asking the same question. There's no value proposition here.

Different network layer, no centralization, no authorities, DNS has nothing to do with making p2p connections, it's like the ballpark is not even in the same country

Bullshit, someone has to be an authority, even if it's p2p, then every connection is an authority.

Re: Iroh 1.0

#439
post #312

Earlier quoted context omitted.

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

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

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?

Re: Iroh 1.0

#440

This might sound pointed, but it truly isn't - why is this approach not already commonplace? As a concept, looking up a verifiable identity makes sense, but often ideas that made sense were looked into and discarded for valid reasons. Would be good to understand those to better understand when/when not to use the project?

You're right, it does make sense. This is how the internet was designed but not how it was implemented.

Originally, every machine was a directly reachable peer, but a finite supply of addresses (IPv4) forced most devices behind translation boxes (NAT) that let them dial out without ever being dialable. Once traffic had to route through the few hosts that stayed reachable, those hosts became toll booths, which is partially where the more centralized internet we actually got came from.

iroh basically patches the internet

Post reply on HN