What about censorship circumvention? Are there specialized DERP to DERP communication, that bridge over internet edge nodes doing DPI on QUIC?
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.
Hmm, 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 same time, but it's a pretty rare usecase and nothing some iptables can't solve.
I can see the argument for chat in heavily censored regions of the world, but not sure if there's any advantages that iroh can offer over other solutions.
Market fit will be hard to find, but best of luck.
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!
Doesn't it seem odd to have "Pricing" for a protocol that's meant to serve a similar function to IP addresses? Maybe I'm misunderstanding something.
We use Iroh in production at work, and I'm absolutely in love with it. I'd describe it primarily as "Tailscale-style hole punching as a rust crate", but of course you can sprinkle a lot of cool p2p stuff on top of the basic QUIC connections.
To me this sounds like tailscale - does anyone have any insight into how what this is doing is similar or different?
My company was using Iroh for a production distributed ML training system & we LOVED it. The team was incredibly responsive even before we hooked up with an enterprise support contract, they're incredibly knowledgeable and the library itself worked amazingly. ++ to this lib. would use again over libp2p anytime.
Ive been prototyping with Iroh for awhile.
I think this tech (modern p2p) represents what agent-to-agent (a2a) should be built on.
Every agent should be reachable to each other without hosting itself as an http server.
related prototypes
Congrats on shipping
You need urgently a "versus" page that talks about tailscale/netbird/netmaker/zerotier/twingate/openziti
Looking at the use cases, right now I don't see anything that cannot be done with Tailscale...
The "address lookup" strategy is really interesting, especially how it uses actual DNS: https://docs.iroh.computer/concepts/address-lookup
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.
This looks really interesting... I think I grok the basic value prop.
However, I'm confused on the open source vs. commercial offerings. How do they differ? How do they work together?
This 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))
I think I see the value prop here. Beyond its intended use, what about creating a full VPN out of it? This takes care of the hard part for a lot of home users, opening your vpn up in a safe way. I know this is solved by many other tools so this isn't a new thing but it may increase adoption. Is there already something like that? I imagine you have considered this and if it doesn't already exist have a good reason for not including it. If so, what is that reason?
I definitely see the value! But I'm not confident I can tell whether there are e.g., security implications, and I couldn't find anything on point in the docs or on github (other than one discussion on authentication that mentions the information disclosed). Would love a whitepaper on that and any other issues adopters should consider.
Not sure what the difference is between this and any regular P2P network?
I wish it had support for a system similar to webrtc's offer and answer SDP messages.
From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.
This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure. For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.
For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.
This is big > We built & continually check that iroh can compile to WASM & run in the browser
How is that different from https://yggdrasil-network.github.io ?
I wonder if Iroh and Zenoh could/should be used together.
The fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.
iroh is consistently one of the most delightful projects i've ever worked with. The people reflect that too.
Congrats iroh team!
Nice video production, but as you can see on this thread of nerds, the messaging is not clear.. Content first, presentation later.
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?
So this could be used as a streamlined way for client devices (mobile phones for example) to phone home to servers (google.com for example) with user data and bypass some local network controls? (DNS block lists, for example)
Is there an android SDK available?
hey, I helped make this :) will try to answer questions where I can
Honestly I am happy that more remote access products are using QUIC, not WireGuard, for tunneling and realizing its technical benefits (e.g. AES hardware acceleration, dynamic endpoints, custom auth with JWT or mTLS, FIPS compliance, traffic masquerading as HTTP/3, etc.). I am a big fan of QUIC myself and I implemented it long ago in Octelium, which is a similar remote access product that's more centered around access control and zero trust rather than P2P connectivity. I believe QUIC should be the future of tunneling, especially when it comes to business and enterprise remote access use cases. Congrats on launching an I wish you the best of luck.
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?
Good for Iroh to have libraries within different languages.
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.
Netbird offers the same. Just based on wireguard and everything is open source.
I love it. I think. But I find it hard to parse tech videos with music in the background.
Is what?
> And because all data that comes from the connection is secured by that key, we can build up from that same key into identity, permissions, and attribution.
So basically they want to find out who is who. In other words: sniffing.
It's interesting how the discussion is currently shifting to meta-explain why sniffing is necessary. I noticed this at universities in the last years; people now either have a tablet or a smartphone or a yubico key. This will be extended in the future, there is no doubt about that. And they are selling it with fancy words, just as Iroh showed.
So is this like an unfree CJDNS? What are the main differences?
I am confused why this is needed.
> IP addresses can break, without warning, and it's outside of your device's control.
We have DNS?
> Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not.
So are domain names? This page does not do a good job of helping me find what it is that I'm missing.
This page is basically useless in explaining what Iroh is or does and why I should care.
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...
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?
reticullum is better, and faster
[dead]
[dead]
[dead]
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 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...