I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS. There is already IPv6 and quic, you need vendor and major software to have any traction in that field.
DNS is highly centralized. Iroh isn't.
Iroh 1.0
201–210 of 488 posts
Re: Iroh 1.0
#202This sounds useful, but isn't this the problem that ipv6 is supposed to solve with 128bit addresses? (I'm not really familiar with why IPv6 never really seemed to take off -- does NAT block incoming IPv6 traffic? (I guess that's the other thing -- even though my devices all seem to have IPv6 addresses I can't recall ever using them))
[dead]
Re: Iroh 1.0
#203hey, I helped make this :) will try to answer questions where I can
Why a library and not a service/daemon? Or are you planning to write a server based on the library and just haven't got to that yet?
We think a library is more useful for widespread adoption. I can't get my mother to install a daemon, but I can get her to download an app that uses iroh under the hood.
Besides, as a lot of people have mentioned already, if you want a dedicated server there are a lot of existing options.
We did write a few small dedicated applications to show off iroh, sendme https://www.iroh.computer/sendme and dumbpipe https://www.dumbpipe.dev/ .
Re: Iroh 1.0
#204Earlier quoted context omitted.
Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way. Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work. In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth a…
So iroh is basically WebRTC, except it works in and outside of a browser. Relays seems quite similar to TURN/STUN servers except they also handle fallback traffic much like TOR guard/relay nodes
Does WebRTC not work inside/outside of the browser anywhere?
Re: Iroh 1.0
#205So is this like an unfree CJDNS? What are the main differences?
There is nothing unfree about iroh. All core crates are published with the standard MIT and Apache2 licenses.
Oh gotcha - the 'pricing' page initially gave me the impression that routing was closed/paid. But I guess it's just hosted deployment?
Re: Iroh 1.0
#206That 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? [1] https://reticulum.network/
This is the comment I was about to make. Reticulum is already a very complete network stack.
Re: Iroh 1.0
#207Hmm, this really looks more of a relay network for sale, kinda like steam p2p. The only real use-case I see for this is for exactly that, connecting two or more players where one of the players is the host. Seems like it'll be a hard sell since steam is already so dominant and enterprise is dominated by tailscale... I see the proposal for being able to work with many different networks from different companies at the…
Steam sockets and CloudFlare's UDP forwarding really are different though. They provide ddos protection as well as route optimization due to lots of points of presence. Here there seems to be no mention of ddos mitigation or shorter routes due to infrastructure. Yes you need a key to connect but your iroh relay server can still be attacked. I suppose you could roll your own distributed anycast system for this.
I assume that the 'enterprise' relays have ddos protection. DDoS protection also comes standard these days, but we've seen attacks go from 20gbps to 20tbps so if uptime is required then tough luck.
Re: Iroh 1.0
#208The future of networking is decentralization. I'm a huge fan of Yggdrasil and I2P. We should just be able to buy a mini PC to run 24/7 and host whatever it is that we need on it and seamlessly connect to others. A lot of techies already have older spare machines laying around collecting dust that can become servers. It is far cheaper in the long run and easier to maintain than having to deal with domains and server hosting. I truly appreciate the work that the Iroh team puts out.
Re: Iroh 1.0
#209Hoping to use this to reboot an ancient abandoned project. At the time there wasn't a mature P2P connection layer that took care of all the realities of the modern Internet out of the box. Now there is, and it's great to see.
This isn't Tailscale because it does secure P2P connections between any pair of devices, whether or not they have Tailscale. This enables real end-user P2P for, e.g., local-first apps with no server infrastructure except relays for resilience. And even if you lose the relay servers, things keep on working the same for any hosts that don't need them.
Re: Iroh 1.0
#210I like the idea. A couple of questions:
1. How does Iroh handle key rotation / leakage? Could you build some kind of hot/cold system on top of it, where you'd have a cold "identity key" in airgapped, secure storage, used only to issue certificates for your hot "traffic acceptance" key?
2. Is there any kind of peer discovery / DHT, either built-in directly or through some semi-official higher-level protocol, like DNS for IP?
3. What about human-friendly peer names? Those are almost required for end-user friendly applications. Most solutions of that problem either assume that every single user is willing to dedicate their life to configuring DNS, rely on a trusted third party, or delegate the responsibility to a blockchain.
4. What are the channel reliability properties, and are they configurable? Can you decide how to handle out-of-order or lost packets, or does the protocol enforce a decision? If you're willing to tolerate loss, duplication and reordering, can you avoid head-of-line blocking?
5. Is peer anonymity a goal?
6. What about two mostly-offline peers who wish to communicate (think smartphone apps that can't be connected 24/7 due to battery concerns)?
Overall, cool project.