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 discussion.
While the frontpage doesn't go in depth, the docs quickly do:
First with https://docs.iroh.computer/what-is-iroh and then following up with the how it works section. The docs are actually good from what I can see so far. From what questions you brought up so for it seems to answer them pretty quickly.
I'd quibble with "quickly", but sure, this seems like the starting point for figuring out how it works: https://docs.iroh.computer/concepts/endpoints From a marketing standpoint, for a technical audience, I think it should be quicker.
I saw the video and still have no idea what they are. Also, “never locked in” but then “pricing” and why is one paying for “apps” but self hosting relays?
As I understand it- you can use free community provided relays, self-host your own, or pay for their managed services with an SLA and monitoring built in
> Dial keys. Not IPs.
> It's a simple idea really, and it's the right abstraction for the future of the internet. IP addresses can break, without warning, and it's outside of your device's control. Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not. IP addresses can be private and inaccessible behind firewalls, but with iroh your device can be securely addressable no matter where it is.
To me that just sounds like a reimplementation of DNS. Maybe decentralised and maybe free and maybe not monomeric, but broadly the same.
The biggest difference that I can see is that keys are not making any claims about ownership, there's no global registry and it's p2p, which is a big upside
DNS doesn't work with constantly changing IPs, like you have on mobile networks. DNS also doesn't help when the IP is behind a NAT. So I really don't see how the two are similar at all.
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
For the singular purpose of "I need to transfer a message to this person and I don't care what the latency is", then sure. That's how my bank treats them.
Having spent a while trying to understand it, I believe the keys are serving a dual purpose as an encryption key and as a stable identifier along the lines of a session cookie that might be used for a WebRTC video call.
Here's my summary from Lobste.rs, keeping in mind I'm not an expert and only found this project today:
> [..] this is closer to an opinionated WebRTC setup that handles assigning a persistent ID to clients. All the work of making a signaling server is taken care of and the solution is generic enough and cheap enough to run that you can get away with using a community hosted one. Kinda similar to what you get with Steam’s proprietary p2p gamenetworkingsocket infrastructure
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...
At the lowest level it is a creative way to leverage all the work the major cloud vendors have poured into QUIC for p2p connections.
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.
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.
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 discussion.