I should read the specs, but since it's such a foundational issue maybe someone who knows could respond briefly? the problem with a flat addressing space is that it requires every intermediate node to have state about every address, or perform a costly discovery mechanism for those it doesn't know about. is there a clever answer to this?
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 to implement custom transports. That way your transport implementation can live in a completely separate crate.
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).
Iroh has been amazing to work with and the engineers are so nice in the discord channel. The pragmatic approach to making p2p just work has been easy to understand. Their YouTube channel has great content too. Congrats on v1!
I’ve recently been building some hobby projects that focus on local first, decentralized architecture and that’s how I discovered Iroh. In my apps, I want the user data to be stored local only, no server, and have p2p sync ability. So for something like that, Iroh appears to be the state of the art.
I'm out of my technical depth here, but out of curiosity: is this meant to be a full replacement for the current IP address paradigm, or is this meant to be a specific tool on top of/alongside IP addresses that solves particular problems/frictions?
LM studio recently released a mobile app powered by Tailscale -- https://lmstudio.ai/link . Iroh seems like a perfect OSS alternative for implementing similar p2p features.
Sounds good, but the first step in your quickstart is getting an API key, and I'm oh, so I guess your sales pitch was a lie and this is really just another Cloudflare-like play to build another intermediary in the internet. If that's not the case, then I shouldn't need an API key for hello world...
That to me looks like Reticulums [1] adressing ("Destinations") with transport done via QUIC. Does it add anything what Reticulum didn't already solve, other than using slightly different protocols - do they have an advantage?
132 comments
[ 2.6 ms ] story [ 53.9 ms ] threadThe fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.
I think that with Kotlin support, the creation of some android/multi-platform gui apps can be made easier if they want to use Iroh.
[0]: https://github.com/n0-computer/iroh-c-ffi
https://github.com/Nuhvi/pkarr/
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 to implement custom transports. That way your transport implementation can live in a completely separate crate.
Existing experimental custom transports include Tor, Nym and BLE. https://github.com/mcginty/iroh-ble-transport
Here is how custom transports work under the hood: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...
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
https://youtube.com/@n0computer
There is already IPv6 and quic, you need vendor and major software to have any traction in that field.
[1] https://reticulum.network/