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.
Hey, just reading through the docs, this looks like a pretty cool project and I found your p2p chat example[0]
I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications?
For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =)
If you run a public unauthenticated relay you act as a home relay for whoever has your relay configured in their relay map and is close in terms of latency.
So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays.
The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings.
You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.
FWIW I think for “new user” audiences you’re better off describing why we’d use this instead of IP, than why you haven’t gotten it everywhere yet: there’s a certain sort of “complaint I see the most from current users” myopia that sets in, at least for me, over the years. :)
I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
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))
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.
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.
From reading that, it lets you establish connections within your tailscale vpn. Iroh let's you establish connections between devices regardless of their network.
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.
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!
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.
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.
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.
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, 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.
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.
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.
From what I can tell Iroh seems to be trying to create the missing Session layer from the OSI model. Another example of trying to do this is Cisco's Location-Identity Separation Protocol.
Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.
Exactly. We use DNS TXT records for our default address lookup system. But we also support fully p2p address lookup via the mainline DHT.
And if you have another suitable system, you can also plug it in. E.g. you might want to use another DHT that allows mapping from a key to some address data.
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!
As others have already mentioned, iroh the core library and protocol is fully open source. But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Congrats for the launch, seems to have matured a bunch and Iroh gotten a bunch of neat additions since I last looked! You even managed to get 1.0 out the door before go-ipfs / Kubo ;)
> But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Interesting (and somewhat proven) idea to finance it, smart :)
Did you guys started doing this already on a case-by-case basis and have some experience of it already, and if so what are the common things you typically help out with exactly? I'm just curious what sort of things a company who'd use a protocol like that might need help with, that they wouldn't have experience with in-house, since they're going down a P2P road already (assuming that, maybe maybe need help with greenfield projects)?
I don't mind paying for a subscription, as long as I'm not also paying for the privilege of being locked in to a specific vendor. If I pay for a subscription and then your prices quadruple or something, what are my options? Can I self-host a relay? Do I lose features if I do so?
I'm not affiliated. From what I understand, they provide an open-source implementation of the relay server: https://github.com/n0-computer/iroh/tree/main/iroh-relay (which may or may not be what they actually run as part of their hosted offering).
If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.
"we want to be infrastructure for people, and a business towards professionals."
stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."
it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.
Our code is as good as we can make it, and everything is modular and well documented. For example our QUIC implementation noq which underlies every iroh connection can also be used as a standalone QUIC impl that implements QUIC multipath.
fwiw, Tailscale happens to be mostly open source, not completely. Yes, I know Headscale exists, it does not implement all the Tailscale functions (not non-functional production type capabilities)
RustDesk has a similar business model and works fine for what it is, is there something particular about TailScale and Iroh that makes you think it will not work?
The equivalent for IP addresses to what they offer would be closer to running a BGP router or ISP, or generally contracting with network engineers for your data-center's networking.
If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.
I've been running my own AS for years. You can get an ASN and IPv6 from a RIPE LIR for $200/year or less. Then you need a couple of VPSes that are BGP capable. You can get those for $20 month. Then you can tunnel traffic back to your location with a Wireguard tunnel or whatever you prefer. It's relatively cheap! I also have a legacy IPv4 block I'm routing, which doesn't cost me anything.
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.
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.
Their use of addressing by keys instead of by IPs seems to be the main differentiator. Also the support for custom transports (BLE, LoRa, Tor) which appears to be in progress and not yet fully implemented.
I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.
Tailscale uses MagicDNS which allows one to auto-generate a semi-memorable private hostname as well. I'm in the networking industry so I'm not seeing anything truly groundbreaking or that isn't offered elsewhere.
The pitch here appears to be that this can allow communication between services without having to add them to a tailnet or such; e.g. if you wanted to let a friend or coworker access some service on your local network without making them join a tailnet, add a public external endpoint to forward traffic, set up a VPN, etc.
IIUC you just send someone 'here is the connection information' and it just works automatically.
Yeah and my understanding of Iroh wasn't quite right either, it sounds like it's positioned to be more of a library to use in code, rather than a VPN solution like Tailscale.
I love MagicDNS - A long time ago I wrote a stupid Python script to have it continually generate MagicDNS names until one of them contained a word I was looking for.
Tailscale is built to be global to your device, while iroh is built to be embedded into each application. This allows application developers and users a much more fine grained and bespoke setup, than having a single global bridge.
but if I am shipping a video conferencing application (where I control both the client and the server) I don't need nat traversal anymore. My clients will have outgoing connections to whichever co-ordination server I choose.
Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
What if you build a p2p video conferencing app with user controlled co-ordinator "server". Server in quotes, because maybe iroh works through the browser?
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?
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.
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.
We have plenty of very deep technical content on our blog, explaining features of QUIC such as 0-rtt, post-quantum key exchange, address validation tokens, embedded devices.
A great thing about iroh is that due to it being just QUIC, when you learn about iroh you also learn about details of QUIC that are useful and transferrable for traditional p2p QUIC connections.
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.
A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation.
If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa.
Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years.
We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.
Forgive me if this is an ignorant question, but does your use of the Mainline DHT mean that Bittorrent clients will be responding to P2P address lookups from Iroh?
First of all: the p2p address lookup is an optional feature. You have to explicitly enable it.
Mainline is incredibly frugal in terms of resource use, but we want it disabled by default so mobile apps don't look like bittorrent clients and get flagged by the OS.
When we do a p2p address lookup, every mainline server node could possibly be responding. Any bep_0044 record gets stored on 20 random mainline server nodes.
So a bittorrent client that participates in the DHT as a server and is long running enough to be included into the DHT routing tables will respond, yes.
Not an expert but this is how I understand it. Yggdrasil is a P2P mesh network. You configure peers to join the network and your computer becomes a relay node for everyone else to use. It doesn't work behind a NAT without port forwarding.
Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.
Zenoh seems interesting but can you please give me some use case where both Iroh + zenoh can be combined to achieve something more trivially (ie. without hassle) or the use-cases of this combination. I'd be curious to know more about their combined use-cases!
Holepunch, formerly hypercore, formerly dat, is a great project. Their main language is js, which makes it difficult to embed into anything but js/ts applications.
Also, they are very principled when it comes to peer to peer purity, whereas iroh is a bit more pragmatic. We use dedicated relays to faciliate hole punching, whereas holepunch tries to use other peers as a temporary relay for hole punching messages.
Another difference is that holepunch have their own DHT, where we have a less decentralised address lookup service by default and use the mainline DHT as a fully p2p alternative.
So TLDR if you are doing js in the browser, holepunch.to might be a good fit. If you work on native mobile apps or embedded devices, iroh will be better since it is pretty frugal. If you work with node.js, both will work. Just evaluate them both and use what works better for you.
Which I just finished updating to 1.0. But it is currently lacking in breadth of API, so if you start using it let us know what you are missing. In the meantime https://github.com/n0-computer/iroh-ffi has the other language bindings with a more comprehensive API
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)
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?
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.
Does this solve the problem of internet segmentation due to politcs?
For example: dns control, tls certification bans (just this month both let’s encrypt and globalsign started revoking Russian certificates), once google starts really complaining about https it gets ugly.
Russia aside, anyone else is closely watching (europe, brics, what have you)
I would say it is an excellent building block for application developers to route around the segmentation. There are several projects that work well in restricted enviroments that use iroh for some features. E.g. https://delta.chat/en/
E.g. you could write an excellent encrypted chat app using iroh, the Tor or Nym custom transport, and BLE or direct wifi for local connections.
You have to be careful though to make sure you configure the transports correctly in order not to expose data you don't want exposed. Iroh can be used in highly restricted environments, but the defaults favour performance over complete metadata privacy.
While it doesn't solve all the issues that come up through the current segmentation, it is very much possible today to assemble components that let you forget about segmentation while you use it.
And it is designed from the ground up, to use existing internet technologies, while avoiding the lock in and dependencies on browser vendors or other large players.
I've been working on a mesh network for private AI models running remotely, controlled by mobile devices (smartphones, tablets, etc.). The mesh is constructed like a piconet, a few devices controlled by a single individual, layered on top of the internet.
How does it support semi-connected devices, intermittent connection failures, etc?
Iroh is built for environments where connectivity is unreliable or intermittent, so it can be a good fit for use cases involving connection failures, offline periods, or semi-connected devices.
We provide a range of peer-to-peer protocols that don't require a central server, including key-value stores, blob transfer, collaborative documents, and streaming audio/video. These protocols are designed to synchronize devices back to a consistent state, even after long disconnections or network interruptions.
If you'd like to explore whether iroh could work for your use case, we're happy to chat. Feel free to email us at support@iroh.computer, and we can set up a call.
This looks very interesting. I’m not sure I understand this, but it seems to me like it competes (or is in the same space as) both Tailscale and zeromq/nanomsg via the protocols? I think it would be nice to have a comparison page to make it easier to position it (I didn’t find one).
A key distinguishing factor is that iroh is meant to be used as a library that you can embed into your desktop, mobile or embedded apps.
Up to now our users are mostly teams that have a rust or C/C++ core, such as https://delta.chat/ . But now that we have bindings teams who use other languages should be able to use iroh.
So you can write e.g. an android and ios app that uses iroh direct connections under the hood, and the app user does not have to know or care about this at all.
We keep thinking about ways to combine iroh + zeroMQ! I think these two could compose. (Not familiar with nanomsg myself)
About tailscale: It's similar, but iroh is not a VPN, so it doesn't add a TUN interface. Instead, you'd build iroh directly into your application. Using iroh you can build a VPN, and there are projects that do so (iroh-lan/iroh-vpn are some hobbyist projects). The upside of building it into your application is that it doesn't need special permissions and is easy to ship to the user.
No. IP isn't going anywhere. The intent is to provide additional capabilities on top of IP.
That being said, if IP ever gets replaced, your iroh based app will continue to work pretty much unchanged. Iroh will just get you the best possible connection (IP or whatever) under the hood.
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?
I would say it is not a replacement but an addition.
IP isn't going anywhere any time soon, but we add two capabilities on top. The ability to dial an endpoint by key, and the ability to get direct connections whenever possible.
That being said, if some other technology becomes popular that actually replaces the IP address paradigm, iroh is well positioned to make use of it. From the point of view of an iroh application developer nothing would change. You still dial by key, and iroh will just make sure under the hood to get you the best possible connection, IP or otherwise.
A little bit of both. Natively it relies on QUIC and leverages existing IP infrastructure, however it also works with custom transports just as fine so you can interact via bluetooth for example.
Thanks, we agree! We used to have bindings for while but the maintenance burden at that point was too high. Now that 1.0 guarantees everyone some stability and we feel confident in the library, we have enough room to properly support it.
Iroh is just a clever combination of existing standards such as QUIC with some draft RFCs and a tiny bit of clever custom logic added via TLS extensions.
So in theory a go implementation is possible using a go QUIC implementation that supports the multipath extension.
Our focus is the rust implementation, since it is very easy to use from compiled languages such as rust, C and C++ and to embed into languages such as js and python.
Edit: since iroh is just a library, it is also possible to link iroh into a go program. Linking a go program from other native languages is a bit of a pain, but linking a C or rust library into a go program is relatively straightforward and high performance.
> 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.
Iroh is a project that combines existing IETF standards in an interesting way. For example we use raw public keys in TLS for the key exchange https://datatracker.ietf.org/doc/html/rfc7250 instead of coming up with our own key exchange scheme.
Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.
We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.
const ALPN: &[u8] = b"iroh-example/echo/0";
let endpoint = Endpoint::bind().await?;
// Open a connection to the accepting endpoint
let conn = endpoint.connect(addr, ALPN).await?;
// Open a bidirectional QUIC stream
let (mut send, mut recv) = conn.open_bi().await?;
// Send some data to be echoed
send.write_all(b"Hello, world!").await?;
send.finish()?;
// Receive the echo
let response = recv.read_to_end(1000).await?;
assert_eq!(&response, b"Hello, world!");
// As the side receiving the last application data - say goodbye
conn.close(0u32.into(), b"bye!");
// Close the endpoint and all its connections
endpoint.close().await;
Such is life when you choose to be introduced to something by a version update blogpost, instead of clicking in the top-left corner and reading the landing page.
The whole experience is fully interactive and you get to chose your own adventure! If you get lost, top-left corner is a safe bet to go to the initial page. Welcome to the internet and enjoy :)
This is true. But you could click the name in the top left. Or Docs.
IP addresses break, dial keys instead
Modular networking stack for direct, peer-to-peer connections between devices
iroh establishes direct connections whenever possible, falling back to relay servers if necessary. Get fast, efficient, reliable connections that are authenticated and encrypted end-to-end using QUIC.
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?
We have an answer, but it isn't really clever. We do have both built in and pluggable address lookup services.
Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.
The secret is that iroh still uses IPs under the hood :)
But with QUIC, your connections aren't bound to your four-tuple, your connection can migrate from e.g. WiFi to Cellular with only a small blip/hiccup.
And with QUIC multipath, you can have multiple four-tuples "active" at the same time. iroh uses e.g. a "real" IP path mainly, with a websocket-based HTTPS path via relay servers as the backup (e.g. in case UDP is blocked).
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...
Hey, just reading through the docs, this looks like a pretty cool project and I found your p2p chat example[0]
I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications?
For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =)
-[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
You may want to consider using a feature flag API if you think it will be unmaintainable.
Strategy patterns and code-centralised feature management ftw :)
Hi! As someone who has historically built on libp2p, I'd love to see an updated comparison focused on app developers!
Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.
What are the risks if any of running public relays? Is this similar in concept to running Tor Guard Nodes / Relays?
If you run a public unauthenticated relay you act as a home relay for whoever has your relay configured in their relay map and is close in terms of latency.
So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays.
The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings.
You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.
All the data is e2e encrypted and nothing is stored. The usual self hosting public things rules apply.
FWIW I think for “new user” audiences you’re better off describing why we’d use this instead of IP, than why you haven’t gotten it everywhere yet: there’s a certain sort of “complaint I see the most from current users” myopia that sets in, at least for me, over the years. :)
If you don't mind, what are other low-effort but high signal forums other than HN, Perplexity and X for accurate news that skip the annoying part?
Lora is a must
There are already some crates providing a bridge between LoRa using iroh. See for example https://crates.io/crates/donglora-bridge
I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
Definitely interesting in having lots of things running lora AND meshes. Thanks.
This is big > We built & continually check that iroh can compile to WASM & run in the browser
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
https://github.com/eqtylab/agentbeam
https://github.com/eqtylab/real-a2a
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 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.
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
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.
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.
I made a demo showing it work: https://hw-e4592d7e.web.hallway.com/
Excuse my ignorance on the subject, but what does this solve that VPNs didn't already address?
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.
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!
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.
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.
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.
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.
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.
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.
I'm not affiliated with Iroh or even using it, but... "IP works just fine". What!? This is _not_ a solved problem
I think that was the question: What is the problem it is solving ?
You’ve asserted “THIS is not a solved problem,” which suggests everyone is clear on what THIS means. I think that is not a good assumption.
But what is the actual problem?
Establishing direct connections on the other hand is a much harder problem with the current internet infrastructure.
From what I can tell Iroh seems to be trying to create the missing Session layer from the OSI model. Another example of trying to do this is Cisco's Location-Identity Separation Protocol.
Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.
DNS isn't decentralised it's more federated. I believe Iroh has the option to use DHT here, last I looked at least.
Exactly. We use DNS TXT records for our default address lookup system. But we also support fully p2p address lookup via the mainline DHT.
And if you have another suitable system, you can also plug it in. E.g. you might want to use another DHT that allows mapping from a key to some address data.
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!
https://youtube.com/@n0computer
thank you!
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.
As others have already mentioned, iroh the core library and protocol is fully open source. But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Congrats for the launch, seems to have matured a bunch and Iroh gotten a bunch of neat additions since I last looked! You even managed to get 1.0 out the door before go-ipfs / Kubo ;)
> But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Interesting (and somewhat proven) idea to finance it, smart :)
Did you guys started doing this already on a case-by-case basis and have some experience of it already, and if so what are the common things you typically help out with exactly? I'm just curious what sort of things a company who'd use a protocol like that might need help with, that they wouldn't have experience with in-house, since they're going down a P2P road already (assuming that, maybe maybe need help with greenfield projects)?
we have been doing this for a while now, you can find some of our highlights listed here https://www.iroh.computer/solutions
I think it would be clearer if you put the "Pricing" navbar link under "Services."
I don't mind paying for a subscription, as long as I'm not also paying for the privilege of being locked in to a specific vendor. If I pay for a subscription and then your prices quadruple or something, what are my options? Can I self-host a relay? Do I lose features if I do so?
I'm not affiliated. From what I understand, they provide an open-source implementation of the relay server: https://github.com/n0-computer/iroh/tree/main/iroh-relay (which may or may not be what they actually run as part of their hosted offering).
If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.
Correct
Yes you can self-host your relays. Forever! Please check out the docs & hosting pages more information:
https://docs.iroh.computer/concepts/relays https://www.iroh.computer/services/hosting
tailscale syndrome.
"we want to be infrastructure for people, and a business towards professionals."
stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."
it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.
Take a look yourself.
Our code is as good as we can make it, and everything is modular and well documented. For example our QUIC implementation noq which underlies every iroh connection can also be used as a standalone QUIC impl that implements QUIC multipath.
https://docs.rs/noq/latest/noq/
If we wanted to have "total bespoke and unusable code" we would have inlined all of this into the iroh repo to make it unusable.
Not affiliated, but I am a very happy user of Tailscale and a very happy user of Iroh; we use the latter in production at work.
Tailscale is a great service that happens to be open source, but Iroh is clearly structured as a library that you can build into whatever you want.
fwiw, Tailscale happens to be mostly open source, not completely. Yes, I know Headscale exists, it does not implement all the Tailscale functions (not non-functional production type capabilities)
RustDesk has a similar business model and works fine for what it is, is there something particular about TailScale and Iroh that makes you think it will not work?
From the same pricing page, it's all additional services: observability, relay hosting, support engineers.
The equivalent for IP addresses to what they offer would be closer to running a BGP router or ISP, or generally contracting with network engineers for your data-center's networking.
If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.
I've been running my own AS for years. You can get an ASN and IPv6 from a RIPE LIR for $200/year or less. Then you need a couple of VPSes that are BGP capable. You can get those for $20 month. Then you can tunnel traffic back to your location with a Wireguard tunnel or whatever you prefer. It's relatively cheap! I also have a legacy IPv4 block I'm routing, which doesn't cost me anything.
Maybe. It's offering "Customized hosting and monitoring for Iroh apps".
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.
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.
thank you!
To me this sounds like tailscale - does anyone have any insight into how what this is doing is similar or different?
Their use of addressing by keys instead of by IPs seems to be the main differentiator. Also the support for custom transports (BLE, LoRa, Tor) which appears to be in progress and not yet fully implemented.
I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.
Tailscale uses MagicDNS which allows one to auto-generate a semi-memorable private hostname as well. I'm in the networking industry so I'm not seeing anything truly groundbreaking or that isn't offered elsewhere.
The pitch here appears to be that this can allow communication between services without having to add them to a tailnet or such; e.g. if you wanted to let a friend or coworker access some service on your local network without making them join a tailnet, add a public external endpoint to forward traffic, set up a VPN, etc.
IIUC you just send someone 'here is the connection information' and it just works automatically.
Yeah and my understanding of Iroh wasn't quite right either, it sounds like it's positioned to be more of a library to use in code, rather than a VPN solution like Tailscale.
I love MagicDNS - A long time ago I wrote a stupid Python script to have it continually generate MagicDNS names until one of them contained a word I was looking for.
My 5 second summary: Tailscale connects devices and Iroh connects applications.
Tailscale is built to be global to your device, while iroh is built to be embedded into each application. This allows application developers and users a much more fine grained and bespoke setup, than having a single global bridge.
you can embed tailscale on the application level https://tailscale.com/docs/features/tsnet
This isn't the same functionality - if I'm shipping a video conferencing application, tsnet would require all my customers be in my tailnet.
but if I am shipping a video conferencing application (where I control both the client and the server) I don't need nat traversal anymore. My clients will have outgoing connections to whichever co-ordination server I choose.
Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
What if you build a p2p video conferencing app with user controlled co-ordinator "server". Server in quotes, because maybe iroh works through the browser?
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?
The "address lookup" strategy is really interesting, especially how it uses actual DNS: https://docs.iroh.computer/concepts/address-lookup
https://github.com/Nuhvi/pkarr/
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.
thank you!
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.
Nice video production, but as you can see on this thread of nerds, the messaging is not clear.. Content first, presentation later.
We have plenty of very deep technical content on our blog, explaining features of QUIC such as 0-rtt, post-quantum key exchange, address validation tokens, embedded devices.
A great thing about iroh is that due to it being just QUIC, when you learn about iroh you also learn about details of QUIC that are useful and transferrable for traditional p2p QUIC connections.
Not to mention that the title of the post doesn't even say what it is.
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.
Tailscale is OSS AFAIK. Not their backend of course, but if you use Headscale then I believe every part is OSS.
tailscale also is written in go, making the integration on mobile especially, often times a lot harder and more expensive
Not sure what the difference is between this and any regular P2P network?
A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation.
If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa.
Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years.
We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.
Note that there are some "regular p2p networks" that use iroh under the hood, e.g. holochain https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-... as well as various p2p chat apps.
https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...
Forgive me if this is an ignorant question, but does your use of the Mainline DHT mean that Bittorrent clients will be responding to P2P address lookups from Iroh?
First of all: the p2p address lookup is an optional feature. You have to explicitly enable it.
Mainline is incredibly frugal in terms of resource use, but we want it disabled by default so mobile apps don't look like bittorrent clients and get flagged by the OS.
When we do a p2p address lookup, every mainline server node could possibly be responding. Any bep_0044 record gets stored on 20 random mainline server nodes.
So a bittorrent client that participates in the DHT as a server and is long running enough to be included into the DHT routing tables will respond, yes.
iroh is consistently one of the most delightful projects i've ever worked with. The people reflect that too.
Congrats iroh team!
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...
How is that different from https://yggdrasil-network.github.io ?
Not an expert but this is how I understand it. Yggdrasil is a P2P mesh network. You configure peers to join the network and your computer becomes a relay node for everyone else to use. It doesn't work behind a NAT without port forwarding.
Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.
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.
Zenoh seems interesting but can you please give me some use case where both Iroh + zenoh can be combined to achieve something more trivially (ie. without hassle) or the use-cases of this combination. I'd be curious to know more about their combined use-cases!
...that's what I'm asking :)
How is this different from https://holepunch.to/ ?
Holepunch, formerly hypercore, formerly dat, is a great project. Their main language is js, which makes it difficult to embed into anything but js/ts applications.
Also, they are very principled when it comes to peer to peer purity, whereas iroh is a bit more pragmatic. We use dedicated relays to faciliate hole punching, whereas holepunch tries to use other peers as a temporary relay for hole punching messages.
Another difference is that holepunch have their own DHT, where we have a less decentralised address lookup service by default and use the mainline DHT as a fully p2p alternative.
So TLDR if you are doing js in the browser, holepunch.to might be a good fit. If you work on native mobile apps or embedded devices, iroh will be better since it is pretty frugal. If you work with node.js, both will work. Just evaluate them both and use what works better for you.
E.g. we support tiny embedded devices such as esp32. https://www.iroh.computer/blog/iroh-on-esp32
Thank you so much for the great reply! Answered all my questions - will definitely look closer!
C binding: [0]
[0]: https://github.com/n0-computer/iroh-c-ffi
Which I just finished updating to 1.0. But it is currently lacking in breadth of API, so if you start using it let us know what you are missing. In the meantime https://github.com/n0-computer/iroh-ffi has the other language bindings with a more comprehensive API
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?
Yes there is an Android SDK: https://docs.iroh.computer/languages/kotlin
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?
[1] https://reticulum.network/
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.
hey, I helped make this :) will try to answer questions where I can
Does this solve the problem of internet segmentation due to politcs?
For example: dns control, tls certification bans (just this month both let’s encrypt and globalsign started revoking Russian certificates), once google starts really complaining about https it gets ugly.
Russia aside, anyone else is closely watching (europe, brics, what have you)
I would say it is an excellent building block for application developers to route around the segmentation. There are several projects that work well in restricted enviroments that use iroh for some features. E.g. https://delta.chat/en/
E.g. you could write an excellent encrypted chat app using iroh, the Tor or Nym custom transport, and BLE or direct wifi for local connections.
You have to be careful though to make sure you configure the transports correctly in order not to expose data you don't want exposed. Iroh can be used in highly restricted environments, but the defaults favour performance over complete metadata privacy.
While it doesn't solve all the issues that come up through the current segmentation, it is very much possible today to assemble components that let you forget about segmentation while you use it. And it is designed from the ground up, to use existing internet technologies, while avoiding the lock in and dependencies on browser vendors or other large players.
how can i make it give me zen-inspired life advice?
I'd also like for it to prepare tea
the zen life advice will come if you use it long enough :)
Jasmine tea and a game of Pai Sho.
I've been working on a mesh network for private AI models running remotely, controlled by mobile devices (smartphones, tablets, etc.). The mesh is constructed like a piconet, a few devices controlled by a single individual, layered on top of the internet.
How does it support semi-connected devices, intermittent connection failures, etc?
Hi, I also work on iroh.
Iroh is built for environments where connectivity is unreliable or intermittent, so it can be a good fit for use cases involving connection failures, offline periods, or semi-connected devices.
We provide a range of peer-to-peer protocols that don't require a central server, including key-value stores, blob transfer, collaborative documents, and streaming audio/video. These protocols are designed to synchronize devices back to a consistent state, even after long disconnections or network interruptions.
If you'd like to explore whether iroh could work for your use case, we're happy to chat. Feel free to email us at support@iroh.computer, and we can set up a call.
This looks very interesting. I’m not sure I understand this, but it seems to me like it competes (or is in the same space as) both Tailscale and zeromq/nanomsg via the protocols? I think it would be nice to have a comparison page to make it easier to position it (I didn’t find one).
A key distinguishing factor is that iroh is meant to be used as a library that you can embed into your desktop, mobile or embedded apps.
Up to now our users are mostly teams that have a rust or C/C++ core, such as https://delta.chat/ . But now that we have bindings teams who use other languages should be able to use iroh.
So you can write e.g. an android and ios app that uses iroh direct connections under the hood, and the app user does not have to know or care about this at all.
We keep thinking about ways to combine iroh + zeroMQ! I think these two could compose. (Not familiar with nanomsg myself)
About tailscale: It's similar, but iroh is not a VPN, so it doesn't add a TUN interface. Instead, you'd build iroh directly into your application. Using iroh you can build a VPN, and there are projects that do so (iroh-lan/iroh-vpn are some hobbyist projects). The upside of building it into your application is that it doesn't need special permissions and is easy to ship to the user.
Is what?
Is the intent to replace the IP protocol ever?
No. IP isn't going anywhere. The intent is to provide additional capabilities on top of IP.
That being said, if IP ever gets replaced, your iroh based app will continue to work pretty much unchanged. Iroh will just get you the best possible connection (IP or whatever) under the hood.
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?
I would say it is not a replacement but an addition.
IP isn't going anywhere any time soon, but we add two capabilities on top. The ability to dial an endpoint by key, and the ability to get direct connections whenever possible.
That being said, if some other technology becomes popular that actually replaces the IP address paradigm, iroh is well positioned to make use of it. From the point of view of an iroh application developer nothing would change. You still dial by key, and iroh will just make sure under the hood to get you the best possible connection, IP or otherwise.
A little bit of both. Natively it relies on QUIC and leverages existing IP infrastructure, however it also works with custom transports just as fine so you can interact via bluetooth for example.
Netbird offers the same. Just based on wireguard and everything is open source.
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.
Thanks, we agree! We used to have bindings for while but the maintenance burden at that point was too high. Now that 1.0 guarantees everyone some stability and we feel confident in the library, we have enough room to properly support it.
Missing a native go version
Iroh is just a clever combination of existing standards such as QUIC with some draft RFCs and a tiny bit of clever custom logic added via TLS extensions.
So in theory a go implementation is possible using a go QUIC implementation that supports the multipath extension.
Our focus is the rust implementation, since it is very easy to use from compiled languages such as rust, C and C++ and to embed into languages such as js and python.
But there are some other projects that attempt to provide a native go implementation: https://github.com/tmc/go-iroh
Edit: since iroh is just a library, it is also possible to link iroh into a go program. Linking a go program from other native languages is a bit of a pain, but linking a C or rust library into a go program is relatively straightforward and high performance.
Would you use it if there was a go version?
I love it. I think. But I find it hard to parse tech videos with music in the background.
> 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.
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.
Your phone and laptop don't have stable IPs, let alone DNS entries pointing to them.
They do if you use tailscale and friends
Everyone I'd like to connect to isn't on my tailscale, nor do I want them to be.
So what has the reception been like with IETF?
Iroh is a project that combines existing IETF standards in an interesting way. For example we use raw public keys in TLS for the key exchange https://datatracker.ietf.org/doc/html/rfc7250 instead of coming up with our own key exchange scheme.
Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.
We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.
Were interacting with IETF on a number of projects and so far it's been going well :)
So 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.
What are people building with Iroh?
By far not a complete list but a starting point https://github.com/n0-computer/awesome-iroh/
Also you can join our discord and there's #showcase https://iroh.computer/discord
See https://www.iroh.computer and "use cases" at the top of the page
This page is basically useless in explaining what Iroh is or does and why I should care.
As I see, it tries to explain.
But as someone who's not a network specialist, I fail to see how this is not a glorified P2P DNS.
Maybe this example helps:
https://github.com/n0-computer/iroh#rust-library
I would love to see that P2P DNS you are talking about
Such is life when you choose to be introduced to something by a version update blogpost, instead of clicking in the top-left corner and reading the landing page.
Did we choose, or was that the link we were given that introduced us to it.
The whole experience is fully interactive and you get to chose your own adventure! If you get lost, top-left corner is a safe bet to go to the initial page. Welcome to the internet and enjoy :)
This is true. But you could click the name in the top left. Or Docs.
IP addresses break, dial keys instead
Modular networking stack for direct, peer-to-peer connections between devices
iroh establishes direct connections whenever possible, falling back to relay servers if necessary. Get fast, efficient, reliable connections that are authenticated and encrypted end-to-end using QUIC.
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...
If you are a rust developer, you can just take a look at the examples in the iroh repo itself or in our iroh-examples repo.
None of them require an API key.
https://github.com/n0-computer/iroh/tree/main/iroh/examples
https://github.com/n0-computer/iroh-examples
reticullum is better, and faster
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?
We have an answer, but it isn't really clever. We do have both built in and pluggable address lookup services.
Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.
https://www.bittorrent.org/beps/bep_0044.html
https://pkarr.org
Some custom transports such as TOR hidden services have a discovery system built in. In these cases we can just use the existing discovery system.
See for example https://github.com/n0-computer/iroh-tor-transport
The secret is that iroh still uses IPs under the hood :) But with QUIC, your connections aren't bound to your four-tuple, your connection can migrate from e.g. WiFi to Cellular with only a small blip/hiccup. And with QUIC multipath, you can have multiple four-tuples "active" at the same time. iroh uses e.g. a "real" IP path mainly, with a websocket-based HTTPS path via relay servers as the backup (e.g. in case UDP is blocked).
Were all building the exact same shit.
are we?
Looking at the pricing page, how can this be the future, maybe the post was written in 1998