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

371–380 of 488 posts

Re: Iroh 1.0

#371

Post by teohhanhui »

rklaehn wrote: post #237
akavel wrote: post #228

Huge congrats on the release! I'm slowly trying to build an app on Iroh; it's progressing tiny bit by tiny bit, but I must admit I'm struggling a lot all the time, both with various low-level details, as well as with understanding many high-level aspects, concepts, and approaches. Oftentimes I have to resort to some LLM-generated "wiki" websites to help me progress. I really hope you'll manage one day to allocate som…

We started as an IPFS implementation, but since then the scope of iroh has been reduced. Iroh is not IPFS, but more like libp2p. If you want something like a globally distributed internet archive you would have to use protocols on top of iroh. For example iroh-blobs provides verified streaming of content-addressed data using the BLAKE3 tree hash function. It is very close to itself being 1.0 (probably Q3), but for no…

> I wish you could also delegate this problem to the mainline DHT, but alas that is not possible because of some mainline limitiations.

Have you seen https://github.com/bittorrent/bittorrent.org/pull/174 - does that address the main issue?

Re: Iroh 1.0

#372

Post by rklaehn »

virtualbluesky wrote: post #235

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?

Previous similar attempts were often not pragmatic or frugal enough. They cared about peer to peer purity more than about it working under all circumstances. They also frequently overabstracted things.

So we got into the sad situation that people associate peer to peer connectivity systems with having to frequently debug the entire stack and having recurrent performance or connectivity issues.

A part of the motivation for the iroh team is to change this notion by being very pragmatic and minimalistic. E.g. the use of relays vs. enlisting other peers to help with hole punching.

Re: Iroh 1.0

#373

Post by mkl »

rklaehn wrote: post #16

I am one of the iroh developers. A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ... Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags. But we have added the ability t…

Please consider putting the first paragraph of [1], "iroh is a modular networking stack written in Rust. It provides the building blocks to create applications that can communicate using fast, cheap, and reliable connections.", at the top of the blog post and the main website. The middle two lines of [2] are good as a follow-up.

The current stuff about dialling is pretty incomprehensible, as shown by the many confused comments here. No one "dials" IP addresses (or keys), and no one wants to, so the word "dial" shouldn't be part of the title or description. The word "key" would be better not mentioned until you start talking about implementation, and the brief high level "what it is" and "what it is for" stuff should come before implementation.

Iroh seems quite relevant to some projects of mine, but after reading the blog post and the main page, I still had no idea of that relevance until I had read over a hundred comments here (many of them confused about what Iroh was).

[1] https://docs.iroh.computer/what-is-iroh

[2] https://news.ycombinator.com/item?id=48543554

Re: Iroh 1.0

#374

Post by rklaehn »

comboy wrote: post #304

I'm so disappointed in this comment thread https://en.wikipedia.org/wiki/OSI_model I've just learned about it, but my understanding is that Iroh is L7, compared to e.g. tailscale which is L3

That is correct. Iroh connections are at L6, individual protocols such as blobs or gossip are at L7.

From the OSI point of view, QUIC itself is a bit of a layering violation. It covers transport (L4, Reliable ordered delivery, stream multiplexing, congestion control, ...), session (L5, connection establishment and lifecycle, path migration, ...) and presentation (L6, encryption).

And of course below that we have the ability to provide custom transports.

This was done intentionally in QUIC to provide more control. The application layer doesn't have to care about what goes on below, but for some advanced use cases it can know what's going on and even influence which path is being used.

QUIC/TLS being such a comprehensive and well tested package allows us to delegate a lot of the work and just add a tiny bit of logic to make it peer to peer.

Although delegate is not exactly right, since we ended up having to write our own QUIC implementation, noq, to support QUIC multipath...

Re: Iroh 1.0

#375

Post by rklaehn »

infogulch wrote: post #227

How does Iroh's performance compare to wireguard?

I think we do very well with devices devices with limited bandwidth and changing connections. We are able to saturate a 1 GiB link from a normal desktop PC or good phone, but have some work to do to saturate a 10 GiB link with a single process.

We don't have a comparison benchmark, but we are fast enough that we are not the limiting factor for many use cases.

In many cases the performance bottleneck is the interface to the kernel to send and receive UDP packets. Our QUIC implementation is using all available tricks to make this as fast as possible. For example on OSX we use the sendmsg_x syscall to send multiple UDP packets in one syscall. On Linux we use GRO/GSO and recvmmsg to send/receive as many packets as possible.

But to be completely honest, in some cases TCP is still faster for raw throughput on server class hardware. Decades of optimisation have gone into TCP. But QUIC/UDP is quickly catching up. All the major cloud vendors bet heavily on QUIC/UDP and are optimizing it.

Since we just do p2p QUIC we benefit directly from all improvements in this area.

Re: Iroh 1.0

#376

Post by logged4upvoting »

So if i understand correctly is like

Application 1 has a Ed25519 keypair

Secret key private 3085c7405a88a968133e813e9f638a7d9b2e8088fe717ca535cc24d90b59815d

EndpointID or public key, for connecting to you: 274d4c656f064d4c59fffe7db38d6bf90d63cb087d0b2afd2cfa534334f7071c

and for connecting to App 2 you need to know the other endpoint id, no friendly "dnsish" name involved.

Re: Iroh 1.0

#378

Post by rklaehn »

logged4upvoting wrote: post #376

So if i understand correctly is like Application 1 has a Ed25519 keypair Secret key private 3085c7405a88a968133e813e9f638a7d9b2e8088fe717ca535cc24d90b59815d EndpointID or public key, for connecting to you: 274d4c656f064d4c59fffe7db38d6bf90d63cb087d0b2afd2cfa534334f7071c and for connecting to App 2 you need to know the other endpoint id, no friendly "dnsish" name involved.

Yes, exactly. Basically we chose the bottom edge of zooko's triangle.

https://en.wikipedia.org/wiki/Zooko%27s_triangle

A mapping from a scarce but human readable name to a non-scarce but not human readable name would't be that hard, but we haven't done this yet.

If we do it it will probably be an additional crate reusing some of our infrastructure, not built in to iroh itself. There are a lot of use cases where the non human readable names work perfectly fine.

We would implement two versions, one using DNS and one using an appropriate decentralized system like ENS.

Re: Iroh 1.0

#379

Post by pacha3000 »

shark1 wrote: post #377

A relevant free and open source competitor: https://github.com/EasyTier/Easytier

This is actualy interesting, thanks for sharing, but not really relevant as Easytier seems to be a tailscale alternative. Not a iroh alternative.

Again, the difference is: tailscale/easytier/wireguard creates a VPN network on your computer/phone/whatever. So all apps can benefit of it

iroh is a library . This is for developers who want to integrate this P2P routing logic inside their app. It is closer to bittorrent than it is to tailscale.

Both approaches are great but fulfill completely different needs.

Re: Iroh 1.0

#380

Post by gorszon »

protocolture wrote: post #283

> IP addresses can break, without warning, and it's outside of your device's control. Keys, however, are created & controlled by you. This doesn't really make a lot of sense. Assuming this is true, its equally likely to be my gateway, or BGP peer IP that breaks. How Iroh offers anything in this scenario is beyond me. >The power of that key can't be overstated. We use it to secure the connection. And because all data…

Yeah, I agree, I had a hard time understanding what it is, because they wanted to define it in relation to IP, but this is not an IP replacement, this is just a different thing. Like a secure by design quic, or something, if I understand it correctly.
Post reply on HN