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

361–370 of 488 posts

Re: Iroh 1.0

#361

Post by flub »

opem wrote: post #188
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…

Can the relay servers, when used as fallback, read the data between two parties by providing its own public key to both of the peers?

Iroh uses QUIC connections and uses the EndpointId, the public ed25519 key, in the TLS handshake for authentication. This makes it impossible for a server to try and machine-in-the-middle the connection.

Re: Iroh 1.0

#362

Post by rklaehn »

CommanderData wrote: post #254
rklaehn wrote: post #237

Earlier quoted context omitted.

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…

Is content discovery on the official roadmap? If the original peer say peer A goes offline but B downloaded $X, can see find B and download, validate the content today? Sorry if this has been answered or covered on the web I'm currently travelling. Edit: I managed to read the linked page, thank you for working on such an amazing project!

We don't have the post 1.0 roadmap very fleshed out at this point. The team has been extremely focused on getting 1.0 out of the door for the last year. This took longer than expected, as expected :-)

But I can say that some form of global content discovery is in my personal definition of done for the project. I'm the BLAKE3 guy at n0, and I don't consider blobs done without global content discovery.

But it is a hard problem, and our standards for "it just works" are pretty high.

Re: Iroh 1.0

#363

Post by matheus23 »

jhancock wrote: post #315
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…

Nice. How easily is the protocol categorized by an external observer? I'm noticing protocols like wireguard more commonly hitting problems as websites rely on third party systems to protect them from non-human interactions.

Somewhat easy, unfortunately.

If you look at Wireguard traffic, you'll see a .iroh.invalid SNI in the QUIC Initial packet.

Encrypted ClientHello can fix that, but support hasn't shipped into rustls yet. So it's definitely fixable.

The interesting thing is that the ClientHello is undetectable when it's sent via the relay transport (sent inside a WSS connection). And in that case, any traffic that happens on IP is fully encrypted and can't be categorized.

Re: Iroh 1.0

#364

Post by terabytest »

Are there any good end-user apps that are supported on a broad set of platforms and use Iroh to support file transfers between e.g. Windows and iOS seamlessly?

Re: Iroh 1.0

#365

Post by rklaehn »

octoberfranklin wrote: post #337
rklaehn wrote: post #224

Earlier quoted context omitted.

I might be crazy, but I got a side project to write a DHT using iroh. The key is to use QUIC 0-rtt connections to keep the connection overhead minimal. But at this point it is just a toy project to push the limits of what is possible with iroh and 0-rtt. It is not used in prod and won't be any time soon :-) https://www.iroh.computer/blog/lets-write-a-dht-1

Even 0-RTT connections still allocate connection state. IPFS learned this the hard way. The mental model you need is the attacks that cause the Linux kernel to send SYN cookies. Learn how that attack works and you'll understand why you can't have connection state here (and neither does the Linux kernel during a SYN flood). https://en.wikipedia.org/wiki/SYN_flood https://en.wikipedia.org/wiki/SYN_cookies It's much wor…

I love mainline and also really appreciate how lightweight it is by just using UDP packets. But UDP packets have their limits. With the maximum MTU you can expect to work, the payload can't be more than about 1000 bytes, which is the limit of bep_0044.

But there are some use cases where you want to store a bit more than 1000 bytes. Not giant amounts, but maybe 4 KiB. Mainline won't ever be able to do this.

Iroh 0-rtt is very lightweight. On the network level you see one or two UDP packets flying in one direction, one or two UDP packets flying back, and that's the end of the interaction. You close the connection, and all state you have to retain is a session cookie on the client side.

It is still much heavier than bare UDP packets, but much lighter than a normal 1-rtt QUIC connection, which is already pretty lightweight.

Here are some details about 0-rtt. The API has changed slightly since then, but the basics remain the same of course: https://www.iroh.computer/blog/0rtt-api

Re: Iroh 1.0

#366

Post by matheus23 »

opem wrote: post #188
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…

Can the relay servers, when used as fallback, read the data between two parties by providing its own public key to both of the peers?

You need to know the public key you communicate with ahead of connecting to the correct relay. It needs to be shared securely out-of-band, relays don't help with that.

Re: Iroh 1.0

#367

Post by jasode »

colinmarc wrote: post #345
samrus wrote: post #329

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

>I don't understand why HN seems so concerned about nailing down its "value proposition".

You're getting sidetracked because of the particular phrase "value proposition" but a lot of people just use it as a stock meme to simply understand something even without any commercial product perspective.

You can read through this entire thread where people are having a hard time wrapping their head around what _it_ _is_ because the blog article doesn't explain it well.

The following various stock phrases use different words but are basically asking the same thing:

- "This is the solution to what problem?"

- "How's this different from Tailscale/Wireguard/QUIC/etc?"

- "What is the raison d'être ?"

- "ELI5?"

- "What's the value proposition?"

- "Why should I care about this?"

- "What's the use case for this?"

- "What's the motivation / rationale for this?"

- "What does this do?"

And then different commenters try different explanations and hopefully one will finally click for readers.

Re: Iroh 1.0

#368

Post by rklaehn »

terabytest wrote: post #364

Are there any good end-user apps that are supported on a broad set of platforms and use Iroh to support file transfers between e.g. Windows and iOS seamlessly?

We wrote a small demo app called sendme to show off iroh. It is cli only, works on all operating systems that we use internally, and we frequently use it to send around qlog files:

https://www.iroh.computer/sendme

There are several projects inspired by sendme that use the same protocol but add mobile device support and a GUI:

https://www.altsendme.com/en

https://github.com/ARK-Builders/Drop-Desktop

https://github.com/zignig/sendme-egui

Re: Iroh 1.0

#369

Post by [deleted] »

terabytest wrote: post #364

Are there any good end-user apps that are supported on a broad set of platforms and use Iroh to support file transfers between e.g. Windows and iOS seamlessly?

[deleted]

Re: Iroh 1.0

#370

Post by mkl »

waynesonfire wrote: post #323
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…

why isn't your mental model to use DNS?

How will that help your computer behind your NAT communicate with my computer behind my NAT? (I think you're still stuck on the blog post's very confusing opening, which does indeed make it sound like a terrible alternative to DNS, but it's actually something entirely different, for a very different purpose.)
Post reply on HN