351–360 of 488 posts
Correct me if I'm wrong but assuming there is only Alice and Bob in the network, each with their key-as-address, and they are both behind a CGNAT, Iroh will still need a third party to host the relay?
> Dial keys Maybe it's in the video I didn't watch, but I really think paragraph one should make clear what kind of keys and why. Cryptographic? Asymmetric? How do they do the job, at even the most basic level? It never explains, just dives into abstract claims of superiority and usage stats. I gather relays are involved; this would be a good thing to mention right away instead of making me sift it from the HN discus…
when i read "keys" i figured "names" like in my .ssh/config a named host that i access with a key... but listening more it sounds like a new way to do networking over QUIC...
If you look at an iroh connection in wireshark it is just a QUIC connection. If you configure a SSLKEYLOGFILE so wireshark can actually look into the packets, you will see a few TLS extensions and somewhat unusual packets flying by during the handshake, but once established it is a completely normal QUIC connection.
That is also why we are relatively confident regarding encryption security. It is just TLS. And we can also leverage new encryption like post quantum key exchange with just a few config changes, without any code changes.
See https://www.iroh.computer/blog/iroh-post-quantum-handshakes
One thing that is genuinely novel is that we use QUIC multipath to keep the different paths (relay, various direct IP paths) separate. This has some technical benefits because the congestion controller does not get irritated when the underlying transport changes. Each transport has its own congestion controller.
I had been looking at zeromq, but I very much agree with using keys rather than IPs where possible (after years of using yggdrasil, wireguard, tailscale, tor), so I am tempted to try Iroh. OTOH, this seems overkill if I'm using a client-server approach where the server IP is known.
Earlier quoted context omitted.
Its amazing to me how people can make a great a product. And then completely bury the lead because they are so deep into the guts of the system You explained the value proposition so well. The website just didnt get to the "why?" At all
It's primarily an open source library, not a product. I don't understand why HN seems so concerned about nailing down its "value proposition".
Maybe the game has changed with LLMs, but its been a running joke that engineers will build a startup/product/library/thing only to then realize they can’t get any users and that marketing and sales are hard.
Attention and mind share are more valuable than ever. If you can’t answer “Why should I care about X?” then you are fighting an uphill battle.
Earlier quoted context omitted.
also to follow on the "why not use tailscale" should be because they're a business who seeks to make money and we are fools to keep concentrating distributed technology to a handful of centralized owners (!) especially when iroh makes it so easy and awesome to do it right.
So instead of paying a subscription fee to Tailscale to support your distributed application, you pay a subscription fee to Iroh to support your distributed application. ( https://www.iroh.computer/pricing says $19/month for what most people will want to use it for). Either one will allow you to stop "concentrating distributed technology to a handful of centralized owners", but the "why not use tailscale" part of wha…
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…
I've looked at the usecases page, obviously there is an AI stunt (which I don't buy at all), for POS applications, well, there are better and less risky (see above) ways to do this, so the only thing that seems to make sense is this real-time sync, if someone is in the restricted environment (but, the point is, that in the restricted environment iroh is going to be blocked anyway by firewalls, z-scaler, etc.).
Earlier quoted context omitted.
It's primarily an open source library, not a product. I don't understand why HN seems so concerned about nailing down its "value proposition".
I mean this kindly, but this is so “engineer brained” Maybe the game has changed with LLMs, but its been a running joke that engineers will build a startup/product/library/thing only to then realize they can’t get any users and that marketing and sales are hard. Attention and mind share are more valuable than ever. If you can’t answer “Why should I care about X?” then you are fighting an uphill battle.
I agree with your premise, but you're still viewing this technology through the lens of "a successful product" versus "a successful piece of technology".
Plenty of open source projects stay open source and are popular without ever making any sales whatsoever. I'm not trying to project my own motivations on the Iroh team; they may want to build a product out of it. For me, though, the project has a lot of appeal already, because it exactly and excellently fulfills a technological need, not because they brought me in with a "it's x but for y" narrative.
Should I consider using Iroh for intranet communucation ? Is it a viable use-cases? The use-cases I have in mind is an app being deployed on a HPC cluster, onto many nodes, cut off from the internet. I had been looking at zeromq, but I very much agree with using keys rather than IPs where possible (after years of using yggdrasil, wireguard, tailscale, tor), so I am tempted to try Iroh. OTOH, this seems overkill if I'…
You get the simplicity of being able to freely move nodes within the data center or even across data centers without having to reconfigure ip addresses. And once a connection is established the performance is comparable to a normal QUIC connection.
Regarding client server architectures: I frequently build systems where you use p2p connections but have clearly defined client and server roles at the application level. Absolutely nothing wrong with that, in fact I think a big problem with existing p2p projects is that they try to be p2p at application level and overcomplicate things.
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…
Its amazing to me how people can make a great a product. And then completely bury the lead because they are so deep into the guts of the system You explained the value proposition so well. The website just didnt get to the "why?" At all
Correct me if I'm wrong but assuming there is only Alice and Bob in the network, each with their key-as-address, and they are both behind a CGNAT, Iroh will still need a third party to host the relay?
If they are behind different CGNat, you need a party that is reachable by both to help with hole punching and/or relay traffic. This is fundamental, there is nothing you can do about this.
Some p2p protocols try to enlist other peers to be that third party. E.g. holepunch.to . Iroh uses dedicated relays for this.
The relays can either be the n0 public relays, a n0 paid relay network, or self-hosted relays. No matter which option you choose, every iroh endpoint is able to talk to every other iroh endpoint unless they are fully airgapped from the internet.