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 and the lowest possible latency.
This was not a solved problem until now.
isn't this exactly what tailscale (and also zerotier, netmaker) do?
https://tailscale.com/blog/how-nat-traversal-works
Those are intended to solve the problem at the OS layer, while Iroh (being a library) does it at the application layer.
Like https://tailscale.com/docs/features/tsnet ?
From reading that, it lets you establish connections within your tailscale vpn. Iroh let's you establish connections between devices regardless of their network.
I think everyone in this thread agrees on that part already.
The similarities are in an application lib to connect, and that tail net IPs correspond to device keys like in Iroh. The service using the Go library has its own Tailscale identity.
There might be a misunderstanding of what Tailscale offers here. There is no "VPN" in the classic "virtual network" way. With Tailscale, you can - as with Iroh, IIUC - connect arbitrary nodes to each other, where a node can be a device or an application (via tsnet). All nodes get CGNAT IPs and an addressable hostname, so there is one giant "network" of all your nodes with automatic DNS resolution baked in.
Doesn't tailscale require those all be administered and approved by one account?
> there is one giant "network" of all your nodes
From what I understand they're saying, the point is that you get easy connections to things that aren't "your" nodes, sort of like allowing me to connect one of my tailscale nodes ad-hoc to one of your tailscale nodes, when our accounts are not related in any way prior to us doing that, and without me having to allow your node onto my network or you allow one of mine onto your network and have to deal with the specialized ACLs for that, since it's just a direct connection between two nodes.
Yeah, I figured that in the mean time. It just didn’t occur to me because my use case is literally the opposite—having a secure company network where strict ACLs are the core value, not a nuisance. But if easy ad-hoc connections are your goal, Iroh sure looks like the better choice then.
Similar on the technical level (though QUIC vs WireGuard), but that would make your app dependent on Tailscale, and require your users to have Tailscale accounts. You'd also be limited to Golang currently.
In theory you could run Headscale, but you're really working against Tailscale's intended design at that point, and Iroh was built for this from the ground up, so what is Tailscale buying you?
You don't need tailscale accounts to access tsnet (via funnel).
That only works for the infrastructure of one entity. It doesn't establish direct connection to my friend's device by a key pair if he is outside of the particular organisation tailscale VPN.
p2p apps need direct connections.
Excuse my ignorance on the subject, but what does this solve that VPNs didn't already address?
vpns typically add at least one hop. this has the possibility of connecting directly via hole punching
Modern VPNs based on wireguard can do direct connections with hole punching. It's just a lot more work to setup on your own, or you have to sign-up to a SaaS like tailscale and use their relays, and they'll do the hole punching for you.
Here this is a decentralized network with a lot of existing public relays. But in principle a VPN can solve a lot of the same problems. It's just that commercial VPNs are not decentralized, and doing your own wireguard setup is a pain.
Already possible with taiscale, netmaker, zerotier etc.
https://tailscale.com/blog/how-nat-traversal-works
But only for devices already on that tailnet.
This allows you to provide information to an arbitrary person (a friend/coworker/etc) to let them access the thing without them having to jump through all the extra hoops of joining your tailnet/them joining yours/adding a VPN/etc.
but what exactly is the use case? I was responding to the nat traversal topic..
If I wanted to share something internal with a friend I would use ngrok or any of the million alternatives.
Anyway, this is exactly why my top-level comment says that this project needs a "versus" page in the docs.
With Tailscale at least, you can pretty easily share a node with someone else. If your target audience are solo developers or hobbyists, making it even easier to share access is surely nice; from the perspective of someone in charge of making sure our company IT is balancing security and ease of networking, the literal last thing I want is making it easier to grant someone access.
There are policies defining who can talk to what; they are deployed from a GitHub repository with defined rules on who can modify them and who has to review them; there are zero scenarios where I want an alternative way of granting access to any device or service under our control.
Cisco Dynamic Multipoint VPN will start by connecting to a central VPN server and then learn the public IPs of endpoints and automatically create VPN tunnels to them. It can scale to thousands of endpoints.
Presumably this has significant literal costs (because Cisco) and maybe a hardware or virtual-appliance requirement?
Enterprise networking is neither simple or cheap but it should be reliable.
VPNs do not allow you to connect two devices directly, they have to go through the VPN. They also do not allow you to connect devices that are not on the VPN. Iroh does P2P connections and punches holes through NATs when needed, so you can connect directly to devices on different networks that are behind firewalls.
> VPNs do not allow you to connect two devices directly, they have to go through the VPN
Not true. Depends on the VPN protocol.
It sounds like the key difference people are missing is that VPN's operate at the network layer, so they require separate integrations for every device os/arch and network stack, where Iroh is embedded at the application layer, so any app can be a P2P VPN client without worrying about device network integrations.
Sounds great to me, and would be a boon for self-hosting and decentralization in general, which is sorely needed considering how captured, authoritarian, and anti civil liberties every democracy is becoming. If I'm not mistaken, I believe I read a tailscale blog about them envisioning application layer embedding at some point as well.
From my VERY brief understanding: this is like if you want the hole-punching of a VPN, but your stuff is public, so not only do you not want all the security of a VPN, but it works against you. But I'm happy to be corrected!
You don't have to have it public. You can have your app gate against any auth method you like to implement on top. And you can have private relays to segregate your traffic and discovery depending on setup.
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?
It works outside the browser too, I've been using it that way.
Yes it does! I was trying to draw an analogy there, I think it would be better to state as - iroh is similar to WebRTC + PeerJS[1] which only works on browsers, generally[2].
[1]: PeerJS(https://peerjs.com/) is a library to use WebRTC w/o any boilerplate code. [2]: WebRTC functionality can be enabled in non-browser envs like Node.js by using third-party native addons (like node-webrtc) that provide bindings to the underlying C++ WebRTC library.
It's backwards! Unlike webrtc, iroh doesn't work inside a browser. It's for the case where you have two native apps that need to talk to each other p2p.
For browser / webapps you want webrtc.
> We built & continually check that iroh can compile to WASM & run in the browser
We do have browser support, but as of now it is relay only.
Apologies I should have been more precise. What I meant was it doesn't work on the browser support in the way webrtc works on the browser. The point of webrtc on the browser is to establish a peer to peer connection.
Is that not what libp2p already offers? Not sure if it has QUIC out of the box, but hole-punching to UDP connectivity and then running QUIC over it isn't that hard.
The folks who made iroh worked on libp2p first, but found many limitations in libp2p's design. iroh is a better more flexible and powerful version of libp2p
Libp2p does have quic, at least the rust implementation.
Yes, but libp2p was mainly designed around the limitations of tcp, as quic simply wasn't there yet when the design started. Iroh gets the benefit of having been designed and built from the ground up, based on quic.
libp2p does have QUIC, but it is one of many possible transports.
So libp2p builds many things on top of the underlying transport where we use QUIC directly and use existing mechanisms such as TLS ALPNs for protocol negotiation.
We also use the stream multiplexing that is built into QUIC instead of putting a stream multiplexer on top of QUIC.
You can think about it like this: libp2p abstracts transports as streams, and then puts many required features on top (protocol negotiation, stream multiplexing)
Iroh uses QUIC and abstracts transports below QUIC. We can work with any unreliable datagram transport that has (or can be hacked to have) a minimum MTU of 1200 bytes (needed to be QUIC compliant).
Minor clarifications, but libp2p also uses TLS ALPN for protocol negotiation, and also uses native quic streams - there is no additional muxer layer when using quic.
Iroh is still awesome.
would it possible to have iroh as a libp2p pluggable transport? So you could dial a iroh node with /iroh/proxy/ed25519key?
It might be an option to provide a good migration path for projects that build on libp2p.
But in the long term you probably don't want two fully featured p2p networking stacks in your dependencies.
Will this be a boom for the web3 world as polygon and many others now uses libp2p now.
I made a demo showing it work: https://hw-e4592d7e.web.hallway.com/
It doesn't seem to do anything when you click Run Live, besides updating the status to "Connecting to DERP relay, exchanging endpoint info..."
You can get it to run by hitting "Edit" at the top - needs a real dev container to run, not a web worker.
So iroh.network is something that they maintain like tor or vpn ?
Classic... want to cast to the chromecast but I'm on the wifi
This might be the ~next~ best example, and the one that Iroh should lead with in all of their marketing materials and videos!
They really need to dumb this down to make it accessible if it's going to spread.
The chromecast should be running iroh, no?
Is bypassing the router a good idea?
Yes if you want to. Routers are a necessary abstraction from the IPv4 days and seems it will stick around for a long time, and we need solutions sometimes around those topologies.
Are you conflating a router with SNAT? Routers as in L3 routing are not an "IPv4 only abstraction."
Yes I used it in place of NAT for most casual users at home, which is presumably what the user above originally meant.
"This was not a solved problem until now."
Skype was doing this back in 2003.
Napster "solved" it in 1999
Peers _always_ connected directly to transfer files
A third party server kept an index and provided search, it did not forward traffic between peers
https://docs.iroh.computer/concepts/nat-traversal.md
"If NAT traversal fails, iroh automtically falls back to routing traffic through the relay server"
It has not "solved" the hole punching problem any better than anyone in the past
Alas, it does worse than predecessors by adding a non-P2P default (cf. option)