iroh.computer

The road to iroh 1.0

iroh.computer via Frando — Fri, 16 Oct 2026 12:02:05 +0000

It is done. After four years of work and various pivots we have released iroh 1.0.

We have an expanding web site describing how iroh works under the hood, but we think it is important to also understand why we made the decisions that led to the current iroh. So here is a trip down memory lane / our commit history which highlights major turning points and design decisions.

Perhaps more importantly, this post also covers some things we considered but ended up not doing.

Iroh started as a rust implementation of ipfs. We got pretty far implementing various ipfs protocols and had interop with existing ipfs implementations working. Our goal with iroh was to target lightweight and resource constrained devices such as mobile phones.

One area where we were unhappy with existing protocols was blob transfer. We started a working group within the ipfs community to come up with a new protocol, called the move the bytes working group.

For that working group, we worked on a proposal for new blob transfer protocol. We wrote a small library called krakensync. Krakensync used BLAKE3 exclusively for content addressing because BLAKE3 supports verified incremental streaming of large blobs.

After a few days we had a bare algorithm, and wanted to add networking to it to make the demo feel more real. We had only two days before the next meeting, and adding networking via rust-libp2p seemed impossible (Remember that this was before LLM coding assistants!).

I had a tiny bit of previous experience with QUIC, and remembered from a project of a friend of mine, quinn-noise that quinn is both hackable and has a simple idiomatic rust API. So I tried to add networking via quinn and found it an absolute joy to work with.

— Rüdiger

In parallel to working on the ipfs compatible iroh, we worked on a side project to implement a single narrow real world use case: transfer of deltachat chat history when provisioning a new device. The technical task was to transfer a single large blob of backup data to a new device. There were hard constraints regarding disk and network usage. And the transfer had to be resumable.

We found that we could not implement this very narrow use case with our ipfs based iroh implementation. Doing so would have had less than optimal network performance, and would have pulled in a very large dependency tree.

So we started writing a lightweight sync library from scratch, using QUIC as the networking layer and BLAKE3 verified streaming for large blob transfer.

Despite our best efforts, our main project was still far away from the theoretical limits. Meanwhile our sync side project showed what is possible. So we made the decision to no longer pursue the goal of staying compatible with existing ipfs implementations.

Instead of multiaddrs, endpoints were identified by an Ed25519 public key.
Instead of multihashes, we had BLAKE3.
And instead of multiple transport protocols we had just QUIC.

The new iroh was just QUIC based networking using quinn and blob transfer using BLAKE3 verified streaming. Compared to the previous version, the functionality was anemic. But the single thing it did, it did with close to optimal performance. It was a lightweight enough dependency that deltachat could justify including it into their rust code base. And suddenly we had both networking and sync deployed in a real app used by thousands of people across various platforms (windows, linux, iOS, android). The old code lives on in beetle.

We decided to use just QUIC. But QUIC as specified in RFC 9000 has clear client and server roles, where the server is identified by a certificate chain. At the time we had to add a somewhat Rube Goldberg construction on top to make QUIC work for peer-to-peer connections, a self-signed certificate carrying the real public key in a custom X.509 extension, with a signature binding the two.

Also, rustls is a heavy dependency, and its default crypto provider is a C dependency. So there was a temptation to replace the entire TLS encryption scheme with a protocol based on noise that is made for peer-to-peer connections from the start.

We ended up sticking with TLS as the industry standard. Without using TLS iroh would not really be QUIC, just reuse some of its parts. But we were still unhappy about the self-signed cert.

Thankfully right around the time when we were discussing this raw public keys in TLS support was merged into rustls. So we didn't waste any time and switched to raw public keys in TLS soon after.

One thing we were not yet happy with: for the deltachat chat history transfer to work, both devices had to be in the same network. Ideally this should work in all cases where the two devices are somehow connected to the internet. We also wanted these transfers to be fast. So what we needed was hole punching. We looked at various systems that implement hole punching. Our goal was to get holepunching to work reliably, even at the expense of compromising p2p purity. If we would need a small server to help, so be it.

Of all the existing open source implementations of holepunching, we found the tailscale approach best suited to our requirements. So we implemented something that was initially very similar, with good results. This was a huge effort, but once we merged it we had hole punch rates to be proud of. In most normal circumstances we punched holes almost immediately, and in the few corporate networks where hole punching was impossible, at least we could still transfer data via relays. It just worked.

We achieved our goal of having a simple p2p library that just worked. But the API was still anemic. It was something that experienced rust teams such as deltachat could include, but not yet attractive to p2p application developers. So we decided to gradually add more functionality. One of the first things we did was extending the blob related API to expose more functionality for BLAKE3 verified streaming. In parallel we also optimized the verified streaming by implementing some advanced features such as BLAKE3 chunk groups.

But even with blobs included, it was not enough. We had very useful functionality for experienced rust teams, but at the time that wasn't exactly a large group. So we decided to add a document abstraction that would make iroh viable as a batteries included p2p application development framework, where ideally you would only need to add application specific code.

As part of the push to make iroh approachable to more developers, we started to publish language bindings to almost all major languages. This worked well and was frequently used, but turned out to be a lot of work for us because of the frequent API changes on the road to 1.0.

As we were adding protocols we also had to solve protocol negotiation.

One common pattern is to add a little handshake protocol on each stream where one side can propose a protocol and the other side can either accept or reject. But that would add overhead for every single stream and take us further away from just peer-to-peer QUIC.

We found that complex schemes for protocol evolution are often a mirage. Truly evolving a protocol in a backwards compatible way leads to a combinatorial explosion of variants that have to be tested. It is really hard to get this right.

So we decided to keep things simple and use the ALPN TLS extension. The connecting side proposes a list of ALPNs, and the server side either chooses one of the ALPNs or refuses the handshake. This happens directly during the QUIC handshake, so it has no overhead other than the raw bytes of the ALPN string.

All in all we are very happy with this decision. Projects like Media over QUIC use QUIC streams extensively in a very creative way, and since we provide just raw QUIC streams we can support these approaches out of the box.

It is not entirely without downsides. The ClientHello containing the ALPN is unencrypted, so on-path observers can see which protocol is used by decoding ClientHellos. One way to work around this is to use a common ALPN such as h3 and then just negotiate the actual protocol later. In a future version of iroh we might support encrypted client hello.

Another consequence of the decision to use ALPNs is that two iroh endpoints talking multiple protocols will have not one but multiple connections open (A QUIC connection is always for exactly one ALPN). We share some internal state for these connections so that e.g. hole punching doesn't have to start from zero.

Sendme and dumbpipe

To show off iroh, we published two small tools: sendme and dumbpipe. These were meant to just show off different iroh capabilities, but also be useful on their own.

To this day we use sendme every day to send logs around. And there are a large number of popular sendme clones: Lightning P2P, alt-sendme, ARK Drop Desktop, DataBeam, sendme-egui, and iroh-send.

Dumbpipe also inspired a number of projects: pai-sho, iroh-ssh, do-ssh, and iroh-ssh-android. But more importantly it showed how useful just direct connections by endpoint id are a building block.

For a long time we did not have the ability to dial an iroh endpoint by endpoint id only. You needed the id of course, but you also needed an additional piece of info: either an ip address or a relay url. Sendme works like this to this day.

But the additional information is not stable. An iroh endpoint can frequently change its public IP address, e.g. when the ISP assigns a new public IP address. It can also change its home relay when it moves to another geographic region. In addition, dealing with tickets is cumbersome for large scale systems where you work with a large number of peers.

In many peer-to-peer projects the mechanism to implement such discovery is a distributed hash table. But our previous experience with DHTs was somewhat traumatic. We deciced very quickly that we did not have the resources to implement a DHT and get adoption for it. So just like with the relays, we compromised a bit on peer-to-peer purity. We explored various centralized options such as cloudflare workers.

But right at this time we discovered an emerging project that would allow us to have our cake and eat it too. Pkarr is the incredibly simple idea of storing signed DNS records on the bittorrent mainline DHT. We ended up using the pkarr format for our centralized address lookup service, but also giving iroh users the option to use the mainline dht directly to get a fully decentralized address lookup system.

Mainline has some unfortunate limitations that are unlikely to go away any time soon. So I started writing a DHT, using on iroh 0-rtt connections. But as of now this is strictly an experiment that pushes the limits for iroh connections, not a production tool.

— Rüdiger

After working on iroh as a batteries included toolkit for some time, the API surface was increasing substantially. And we could not guarantee the same level of quality for all parts of the API. In addition, we noticed that each of our users was using a different subset of the API. The one thing everybody had in common was that they needed dial by endpoint id and connections that reliably hole punch. So we made the decision to narrow the scope of what iroh is significantly. From now on iroh would be just direct connections dialed by endpoint id. The other functionality, that several teams depend on, was moved into separate crates.

We were now at the enviable position that several important projects depended on iroh. But we needed freedom to evolve iroh, and did not want to do so on a feature branch due to previous bad experiences with this approach. So we made our first long term stable release, 0.35 and started the canary series for people that wanted to stay on the bleeding edge on the way to 1.0.

In retrospect it would have been fine to call this iroh 1.0. It is a rock solid version of iroh that many projects depend on even today. But we are happy with the decision to develop on main and let people follow along.

In addition to various functionality changes we also spent quite some time thinking about naming. For example, the identity of an iroh endpoint used to be called NodeId. Back when iroh came as a large binary with several different built in protocols, this made a lot of sense. Also what is now known as address lookup used to be called just Discovery. But we found that discovery isn't really a good name for the process of finding relay or ip addresses for an existing endpoint id. After all you don't discover the endpoint id, you just look up additional data for it.

There are some address lookup providers such as mDNS that actually discover new endpoints. But this is not covered by the AddressLookup trait.

Iroh was working just fine in most cases. But there were some dark clouds on the horizon. To get one of the main features of iroh, seamless migration of the underlying transport, to work reliably, we had to do some not so nice hacks. In the short term this wasn't really a big problem. But we knew that the current approach would limit us substantially in the future.

So we made the decision to fundamentally rework how iroh works under the hood. We were already using multiple paths of course, but QUIC was unaware of all of this. Which was the root cause for various problems.

So far we had used quinn and contributed a few improvements. But now we were doing something fundamentally new: extending quinn to support multipath. For a long time we worked with the assumption that we would upstream our changes, but as the diff grew this became increasingly unlikely. So we decided to fork quinn and maintain our own QUIC implementation, noq.

Configurable key algorithms

A frequent request for iroh was to use key algorithms other than Ed25519. We ended up deciding against it. Many of our current systems such as pkarr address lookup are only ever going to work with Ed25519 keys. So while an iroh version with support for e.g. secp256k1 or P-256 would technically be straightforward, it would make iroh more complex. Our key encoding for the TLS handshake is already key agnostic, so we can likely add support for additional key algorithms without breaking the wire format.

Post quantum signatures

Currently standardized post quantum signature algorithms have very large public key sizes. So supporting them would require us to change from the endpoint id being the public key to the endpoint id being something derived from the public key to keep the size manageable.

Encrypted ClientHello

Encrypted ClientHello has recently been standardized. We might want to use it or a very similar mechanism to hide handshake metadata such as the ALPN.

In the four years we have been working on iroh we have written a lot of code, without any LLM assistance. We have thrown away almost as much code. What remains is a minimal library that heavily relies on existing standards and gives you authenticated, encrypted, direct connections to any endpoint, addressed by nothing but its public key.

The road to 1.0 was anything but straight, but certainly extremely exciting and interesting. And we are not at the end. Iroh 1.0 just means that the wire format and API are stable. But there are various extension points both in the wire format and in the API, and we continue to improve things under the hood.

Meanwhile we can't wait to see what you build on iroh.

Iroh is a dial-any-device networking library that just works. Compose from an ecosystem of ready-made protocols to get the features you need, or go fully custom on a clean abstraction over dumb pipes. Iroh is open source, and already running in production on hundreds of thousands of devices.
To get started, take a look at our docs, dive directly into the code, or chat with us in our discord channel.

Iroh global content discovery

iroh.computer via sanqui — Sun, 4 Oct 2026 19:19:42 +0000

What got me excited about IPFS many years ago, briefly after it was announced, was being able to publish a personal website, blog post, or political pamphlet and have it remain available globally as long as enough people are interested in the content. As governments have been more sophisticated in their firewalling methods, this use case for circumvention tools and permissionless global content discovery is still incredibly relevant.

Recent events have added some urgency to this. IPFS shipyard is shutting down. This does not mean that IPFS will stop working, but it does not bode well for the future of the project.

When we had to solve hole punching, we started looking at existing systems and chose the best open source system as an initial starting point for our own implementation. So let's do the same for global content discovery.

There are a number of projects trying to solve this problem. But one project stands above all others: BitTorrent. It just works and has done so for over two decades.

So let's take a look at what makes BitTorrent the current leader in permissionless global content discovery. BitTorrent has a relatively simple protocol for blob transfer and a DHT called Mainline for global content discovery.

The transfer protocol and content discovery are separate systems. In fact, the DHT was developed later than the transfer protocol. BitTorrent was released in 2001 using centralized trackers for content discovery; the Mainline DHT was added in 2005.

BitTorrent works by creating a .torrent file that contains information about the data to be downloaded. The file is encoded using bencode, which is conceptually similar to JSON.

pieces contains the concatenated SHA-1 hashes of all piece length-sized pieces. The transfer protocol downloads blocks of these pieces from different peers.¹

The transfer protocol allows requests for ranges within pieces, but you can only validate a piece after you have downloaded it completely and computed its SHA-1 hash.

I don't want to dwell on this too long, but I think that BLAKE3 verified streaming is a superior replacement for the transfer protocol. We implemented a protocol called iroh-blobs that uses BLAKE3 verified streaming for sharing blobs of data over iroh connections. With BLAKE3, we only need a single root hash, and neither a piece length parameter nor hashes of the individual pieces. This is what allows iroh-blobs to validate any piece of a large blob without needing intermediate hashes.

For a visual explanation of how it works, see my BLAKE3 and Bao deep dive, which covers verified streaming, outboard encoding, and range requests.

We still have some work to do to make multiprovider downloads of single blobs efficient, but the streaming protocol itself with its fine grained validation is superior to the BitTorrent transfer protocol.

Initially BitTorrent used trackers to get providers for a torrent. What the DHT adds is a way to get providers without having to rely on trackers.

This works by computing the SHA-1 hash of the info section, which includes the hashes of all pieces. Then you announce on the DHT that you have content for this hash. The mainline functions for this are announce_peer and get_peers. Each DHT node will store a large set of providers.

Many more modern protocols also use DHTs for content discovery. But Mainline works extremely well compared to many modern alternatives. It is also an extremely large and stable public DHT deployment, so it is unlikely to go away any time soon. You can look at current mainline statistics.

So let's take a look at why.

The mainline protocol takes into account that a DHT operates across an extremely large number of nodes. You can't afford large per-node connection state. Therefore both queries and responses are constrained to fit into single non-fragmented UDP packets.

There are a number of other limitations compared to modern DHT implementations that all serve an important purpose:

the data stored for a provider is just the public host:port pair of the provider as seen from the DHT node. There is no user defined information in a provider record.²
For newer extensions like BEP 44 the data is fully self-contained and verifiable, either a tiny piece of data or a signed record, both limited to fit into a typical MTU.
you can only store data after first querying the DHT node and returning the short-lived token from its response, proving that at publishing time you can receive packets at your claimed IP address.³

The result of this minimalism is that mainline lookups typically complete in less than a second.

Here is a real BEP 44 lookup of a pkarr record using the get_mutable example from n0-mainline.

If you are traumatized by DHT lookups taking forever or timing out: it doesn't have to be this way. The mainline DHT shows that millisecond lookups are possible at a global scale.

Mainline for finding blobs providers

Now that we have established why mainline works so well, let's see if there is a way to use it for iroh blobs content discovery.

Mainline provider records are just an IPv4 host:port pair. But iroh connections are dialed by cryptographic identity, currently the Ed25519 public key aka EndpointId. So to use mainline provider records for iroh blobs endpoint discovery, we would need a way to know which EndpointId is currently listening on this host:port.

In most cases this host:port will be behind a NAT, so it is not reachable.

I tried a number of ways to use current mainline mechanisms such as BEP 44 to store this mapping, but currently this is not possible. So we need a tiny extra UDP address index service (udp-addr-index) to provide this mapping.

This can be an incredibly simple service. It just stores some tiny arbitrary metadata for each verified UDP host:port pair and is reachable exclusively via a simple single-packet UDP protocol. Since mainline requires UDP, and this is an extension for mainline, we don't need to handle the case where sending UDP packets is not possible.

Writes need a mechanism similar to the mainline or QUIC token mechanism to verify that the remote is actually reachable on the host:port pair. Reads don't need this, we just require a padded query packet to prevent amplification.

The service stores up to 1 KiB of arbitrary metadata. It's a last writer wins map from a live UDP host:port pair to a tiny blob. Mappings expire after some time, so a content provider has to update the mapping at regular intervals as well as when its public UDP host:port pair changes.

The current implementation keeps the map purely in memory. Records have to be updated at regular intervals anyway, and not requiring persistence makes the service much simpler and cheaper to operate. You can run an address index service for millions of iroh endpoints on a single small box with a publicly reachable UDP socket.

The address index service does not depend in any way on iroh. It is infrastructure that could also be useful for non iroh applications using mainline.

In the long term I would love the address index service function to be handled by a BitTorrent Mainline extension. It is simple, generically useful, and not specific to iroh.

For our endpoint discovery purposes we store a record containing the endpoint id, current UDP socket addr, and a timestamp, signed with the endpoint private key. So only the owner of the endpoint key can write a valid signed record, so you can't impersonate other endpoints.

The address index service however does not check anything about the endpoint. What get_peers in conjunction with this service gives us is just a list of candidate iroh endpoints which might serve the content.

Endpoint discovery doesn't have to be for content discovery. We also have an example that shows how to discover peers for a gossip topic.

So now let's take a look at the overall workflow when announcing and discovering content. For both announce and discovery we will need a mainline DHT node. We use the n0_mainline crate just like in the existing iroh-mainline-address-lookup crate.

Announce

We want to associate the UDP socket of n0_mainline with our EndpointId. As outlined above, we use an UDP addr index server for this: we publish a signed record containing our EndpointId via the same UDP socket to the addr index server. n0_mainline has a mechanism to publish arbitrary UDP packets on its socket and to intercept incoming UDP packets. This needs to happen at regular intervals as well as immediately when the public host:port pair changes.

For the announce itself: the mainline keyspace is 20 bytes, usually used to announce SHA-1 hashes of the info section of a .torrent file. We want to announce BLAKE3 hashes, so we first compute the SHA-1 hash of the BLAKE3 hash. Then we use announce_peer to announce that we are providing data for that hash. These announces also need to happen at regular intervals.

You might wonder if SHA-1 is still safe for this purpose. Its collision resistance is broken, but there is no known practical preimage attack. More importantly, the DHT is just a best-effort mechanism for finding candidate providers. We verify downloaded data against the original BLAKE3 hash, so a misleading DHT result can waste time, but cannot make us accept the wrong content.

Discovery

For discovery we first need to find at least one working service that can translate host:port pairs into EndpointIds. We have two mechanisms built in for this: a rendezvous hash that allows address index services to announce themselves, and a BEP 44 record that is a curated list of good address index services. Announce and discovery need to agree on the rendezvous hash or BEP 44 record name to find address index services.

Once we have at least one working address index service, we compute the SHA-1 hash of the BLAKE3 hash we are looking for and call get_peers. The output of get_peers is a list of host:port pairs which we translate to EndpointIds using the address index service.

At this point we get a stream of unverified EndpointIds. We currently do a quick BLAKE3 size query for the content we are looking for to make sure they are live and serve the right content, then hand them over to the iroh-blobs downloader to download the actual content.

Note that the actual connection now uses the EndpointId and iroh's built in address lookup and hole punching to establish a connection. The QUIC connection does not work via the announced UDP host:port pair. That is just a key for the address index service.

All of the above is implemented in the experimental iroh-content-discovery repository. Its workspace contains the address index service, its protocol and client as well as a few extra crates that make use of it.

To see the entire workflow in action, we can run the blobs example. It runs both publish and resolve in one process, but discovery nevertheless goes via mainline and the address index service.

So now we have a mechanism to do content discovery for blobs. This will be useful for tools like sendme and in general for sending around large amounts of data.

But what about permissionless publishing of websites such as a blog? To make this work we need some extra components.

We need a syntax for content-addressed links. We don't go into a giant rabbit hole about how to encode these links. Our content addressed links are always BLAKE3. We need to reserve some global namespace for them, so we reserved a domain blake3.net. A content-addressed link is just https://<hash>.blake3.net, with the hash encoded using zbase32.

We don't want to run an actual gateway at blake3.net. That would be a very bad idea for various reasons.

Instead we want the browser to interpret these links as something that can be resolved in a different way. So we wrote a simple browser plugin that just rewrites these links to http://<hash>.blake3.localhost:<port> where the port is configurable in the plugin.

That's all the plugin does.

It currently works for Brave, Chrome, and Firefox.

For Chrome and Brave, install iroh link from the Chrome Web Store.

The Firefox extension is awaiting review. For now, save the unsigned Firefox XPI to your computer using Save Link As. In Firefox 140 or later, open about:debugging#/runtime/this-firefox, click Load Temporary Add-on, and select the downloaded file. Open the extension popup, click Save, and allow access to the requested sites. You must load it again after restarting Firefox; the unsigned package cannot be installed through Install Add-on From File in regular Firefox.

The last component is a local gateway that serves content-addressed data on localhost. It interacts with mainline to find content and orchestrates the actual blobs downloads. It supports iroh-blobs collections and shows a directory index for them. It also does file type detection. It is derived from iroh blobs gateway in iroh-examples.

You can compile the gateway from source, or download the latest release.

We could build a service worker to verify the data inside the browser process.

Instead we verify the data inside the gateway.

It is software that you have to trust, whether it lives in the browser process or elsewhere doesn't matter much.

With these two components in place we can browse content-addressed data.

Now we have a mechanism to publish and consume content-addressed data. But we don't have a way to refer to mutable data. You could use blake3.net links from an existing website, but for that you need a registrar and a hoster, so it is not the permissionless publishing we are after.

Fortunately a permissionless DNS system already exists, pkarr. We have been using it for years for endpoint address lookup. Pkarr is a standard to publish a DNS record for a keypair, so only the owner of the secret key can publish new versions. The records are published on mainline DHT, which fits our setup neatly.

To make this compatible with our browser plus local gateway usage scenario, we reserved another domain pkarr.net and added a rewrite rule to the plugin and pkarr support to the gateway.

A pkarr link has the format <name>.pkarr.net, where name is the zbase32 encoding of an Ed25519 public key. The plugin rewrites it to <name>.pkarr.localhost:<port>. The gateway will then resolve the pkarr record and either perform a redirect or directly serve content-addressed data if the pkarr record links to hash.blake3.net.

If you are familiar with IPFS, this is very similar to IPNS. I even did a little toy experiment called Iroh Pkarr Naming System

The pkarr-publish-resolve example in iroh-content-discovery demonstrates the whole workflow: generate a keypair, publish a blob and its name, then resolve the name, discover a provider, and download the verified content from a separate client.

Pkarr gives us permissionless names, but not human-readable ones: anyone can generate a keypair and publish under its public key, without asking a naming authority. This is the tradeoff illustrated by Zooko’s triangle: pkarr names are decentralized and cryptographically verifiable, but a 52-character encoded public key is not a memorable name.

You can combine human readable naming systems with pkarr to get a memorable name that you can retarget in a permissionless way. We have some ideas about how to do this, stay tuned.

The first step is to run the local gateway. Most readers of this blog will probably just compile it from source, but there are also installers for windows and MacOS on github.

The next step is to install the browser plugin. For Chrome and Brave, install iroh link from the Chrome Web Store.

Make sure the port configured on the gateway and the browser plugin match. The default is 45475 or B1A3.

And then you are ready to browse the content-addressed web.

Try https://y7rmokt6h5mryuauw83em4u1br6tqrukaw3ngtde7zp8p3bg6hto.blake3.net/ for some static content, or https://5ti57aszf7kaicsncb4wgigkf9bju39kofiz8dthwdujkmz85u8y.pkarr.net/ for a pkarr record currently pointing to the above.

Traditional website publishing just means copying your files to a directory on a server. But for content-addressed data and permissionless pkarr DNS records, you are the publisher.

So we wrote a tool iroh-share that simplifies publishing. You can think of it as sendme, but running as a daemon with a separate user interface.

Both content-addressed data and pkarr records need continuous announcements, so you might want to run this daemon on a small box in your attic that is on 24/7, or a vm in the cloud. I run it on an old Synology NAS in my attic. It's behind a NAT of course, but you do get direct connections anyway.

You can find releases at https://github.com/n0-computer/iroh-share/releases.

We now have a system for global content discovery of BLAKE3 hashed content addressed data. It is far from perfect, but it's a start.

The user interface of sharing content addressed data is extremely simple. You just state what content you want, and the gateway gets it for you.

The system behind it has a lot of room for improvement.

Mainline is quite scalable, but it probably won't scale for the vision of making all content on the internet content-addressable.
Mainline traffic is also unencrypted and therefore easily blocked by middleboxes.
The existing pkarr naming mechanism is using Ed25519 and therefore is not post quantum secure.
And perhaps most importantly, mainline does not provide any privacy. If you share content, anybody can look up your ip address.

But we are currently in the food and shelter phase of global content discovery. We will continue to improve the underlying content discovery system, possibly by extending mainline, possibly by writing our own DHT using iroh connections.

But the current system is certainly better than nothing, and we can do all these improvements while keeping the user interface stable.

We are currently working on getting our most frequently used iroh protocols irpc, iroh-gossip and iroh-blobs to 1.0. The endpoint discovery mechanism is experimental, but all relevant crates are published on crates.io for you to play with.

In endgame mode, it may request the same remaining blocks from multiple peers and use whichever responses arrive first. ↩
Technically, you can choose the port in an announce_peer request. But that gives you only 16 bits, which is not enough to store, for example, a 32-byte iroh EndpointId. ↩
This mechanism is similar to the address validation token in QUIC. ↩