- eli 5?
Iroh 1.0
451–460 of 488 posts
Re: Iroh 1.0
#452Iroh 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! https://youtube.com/@n0computer
Shame they use discord though.
Re: Iroh 1.0
#453Earlier quoted context omitted.
That explanation still seems overly complicated. Iroh isn't a VPN. Iroh just lets apps connect to each other, just like plain old TCP, but without the shackles of NAT, DNS and dynamic IP addresses that made that impossible. It's restoring simple P2P connectivity to the Internet.
Also, all connections in iroh are end-to-end encrypted.
That.. makes it sound to me a lot like a VPN though
Re: Iroh 1.0
#454Earlier quoted context omitted.
iroh is fully open source though, you can run your own relay server and not have any dependencies on number0
Headscale exists, not sure what the difference is in practice.
This might not be a giant difference in practice.
But headscale is a community project. The iroh relay code is by number0 just like iroh itself and lives in the same MIT and Apache2 licensed repository. You can even embed it into your webserver if you have a special use case - it is very modular.
Re: Iroh 1.0
#455If 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…
How do I add firewalls and proxies and logging to iroh connections? How do I revoke and re-issue iroh keys? Can I host iroh relays/gateways on my intranet? Until these questions are answered iroh will remain blocked.
You don't have to use it. But here are some answers:
Re-issuing keys is as simple as generating a new Ed25519 keypair.
let secret_key = SecretKey::generate(); // takes less than a millisecond
Iroh as of now has no fleet management. So the concept of revoking a key is something you would have to add yourself.
We have extensive logging for iroh. You can enable trace logging and even enable qlog for detailed connection logs. You can view the logs in any qlog viewer. We have written one, but there are others. It is an open standard for QUIC logs.
https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-s... https://github.com/n0-computer/qlog-viewer
The iroh relay library and binary are open source just like everything else in the core. You can of course run a relay in your intranet, but the exact details depend on the use case. Get in touch if you have a demanding use case and want us to help.
Re: Iroh 1.0
#456Are you able to do any form of highly available loadbalancing with this?
We have not implemented this yet, and there are some things to consider. But there is an open standard for load balancing QUIC connections, and we have hooks in our QUIC implementation noq to generate connection ids that should allow us to work with this open standard.
https://datatracker.ietf.org/doc/draft-ietf-quic-load-balanc...
Get in touch if you have a demanding use case and want us to help.
Re: Iroh 1.0
#457Netbird offers the same. Just based on wireguard and everything is open source.
There are some technical differences since we build on QUIC, not on wireguard. We think that QUIC offers some advantages for demanding use cases.
But everything we do is open source as well. Everything in the core is MIT and Apache2 licensed, including the relay binary/library.
Re: Iroh 1.0
#458Earlier quoted context omitted.
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…
Excellent I look forward to it, I like Iroh objective of keeping it's footprint small enough to run on low powered devices. IPFS in my experience is very heavy. If my understanding is right, content discovery can't happen on the existing mainline DHT which is a shame. Maybe once you have enough traction you can propose a standards change? DHT mainline today is amazing because of its network size.
There is this https://github.com/bittorrent/bittorrent.org/pull/174
We would love this to gain more traction so we can use mainline also for content discovery. But we have to be realistic: mainline moves slowly, and for good reasons.
Re: Iroh 1.0
#459This 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 motivatio…
What's the minimum viable number of relays if the entire internet was running on Iroh today?
Re: Iroh 1.0
#460This 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 motivatio…
And thanks for the reply, I like the philosophy of the bits I understand so far. Rare project in that sense, fwiw.