But if you are technically proficient enough to run your own infra we are happy too. Our relay is open source just like the rest of iroh, and we even try to make it very easy to run them, no weird hoops to jump through.

I won't like - webrtc will probably never graduate to a built-in transport. But we would be very happy about a bare metal webrtc transport and link it from our official docs for people that need it.

Also what kind of attitude is this? Government is too powerful, we might as well give up. Where's the fun in that. It is hard but also very rewarding.

Sendme is a demo for iroh and a very useful standalone tool, but it is more about quick ad-hoc transfers.

I think flipflop is using iroh-blobs for data transfer, so you can think about it as like sendme but with permanent connections.

https://github.com/n0-computer/iroh-esp32-examples

Most examples that I did so far were about simple sensors, but audio streaming should work as well. If you need high bandwidth you might want to look into using the esp32 built in crypto hardware acceleration though.

Although audio is probably fine, but if you want to do video via an esp32 you will need the hardware crypto.

But iroh is designed bare metal first, we currently support the browser via WASM, but only with relay mode.

We will solve browser eventually, but I think it is a mistake to build peer to peer tech browser first. We think it is better to make it extremely efficient on bare metal first, and then grow into the restricted browser ecosystem where possible.

Browsers are very restricted environments.

So if you are in an extremely weird NAT you will fall back to a relay, either our public relays, your own relays rented from us via iroh services, or a self-hosted relay.

But I would argue that a p2p social application that occasionally uses a relay is very much preferable to a centralised app.

The relay is generic internet infrastructure. It just forwards end to end encrypted connections. It can not learn anything about the content.

A relay that is hosted on a non KYC server rented via ZCash would be interesting though if you are super paranoid.

If you want full ipfs functionality, we have a number of protocols you can combine: blobs https://github.com/n0-computer/iroh-blobs and gossip https://github.com/n0-computer/iroh-gossip .

There is one thing we do not have yet - global content discovery. The reason for this is that so far we have not found a way to do it in a way that just works.

It is a very hard problem, but I hope we can come up with a solution so we can cover the use cases that initially got me excited about IPFS many years ago.

We realised that there are many more use cases for p2p streams than for blobs, so in the last year we have focused on getting iroh to 1.0, which involved implementing our own multipath QUIC implementation based on quinn. This was a lot of work and took the full focus of the team.

That being said, we plan to continue to work on blobs and get it to 1.0, which will involve some API changes and some internal changes, primarily to the blob store.

The blobs network protocol itself is just BLAKE3 verified streaming with a few tiny modifications (chunk groups) for efficiency, and hasn't changed since 2 years. Not because we don't have time for it but because it is done.

My personal goal is to have blobs working so well that you can forget about it, and also provide a solution for global content discovery.

We would love this to gain more traction so we can use mainline also for content discovery. But we have to be realistic: mainline moves slowly, and for good reasons.

But everything we do is open source as well. Everything in the core is MIT and Apache2 licensed, including the relay binary/library.

https://datatracker.ietf.org/doc/draft-ietf-quic-load-balanc...

Get in touch if you have a demanding use case and want us to help.

Re-issuing keys is as simple as generating a new Ed25519 keypair.

let secret_key = SecretKey::generate(); // takes less than a millisecond

Iroh as of now has no fleet management. So the concept of revoking a key is something you would have to add yourself.

We have extensive logging for iroh. You can enable trace logging and even enable qlog for detailed connection logs. You can view the logs in any qlog viewer. We have written one, but there are others. It is an open standard for QUIC logs.

https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-s... https://github.com/n0-computer/qlog-viewer

The iroh relay library and binary are open source just like everything else in the core. You can of course run a relay in your intranet, but the exact details depend on the use case. Get in touch if you have a demanding use case and want us to help.

But headscale is a community project. The iroh relay code is by number0 just like iroh itself and lives in the same MIT and Apache2 licensed repository. You can even embed it into your webserver if you have a special use case - it is very modular.

It will work even on very restrictive firewalls. Even if they outright ban UDP packets, we will fall back to the relay connection which is https/websocket.

Note that here is not a single keypair per machine, but per endpoint. You can have multiple endpoints on one machine.

The iroh endpoint will determine its location in the world by probing the configured relays using QAD (similar to STUN). It will then choose a home relay and establish a https connection to it.

When another iroh endpoint wants to talk they first briefly talk via that relay, then hole punch and establish a direct connection.

All of this happens in the background without the user even noticing. It’s also very lightweight - runs on an embedded computer with 2 megabytes of RAM.

We might do an io_uring based linux only implementation at some point. For now we do care about performance very much, but also want to have a single code base for all supported architectures and platforms.

We do support a lot out of the box, which is hard enough as is with a small team. And while io_uring is a bit better than the current sendmsg with GSO / recvmmsg with GRO setup, it isn't orders of magnitude.

> Can iroh run on a proxy server which forwards requests to backends that don't integrate with iroh directly?

We have a tool called dumbpipe that has options to forward local tcp services over an iroh pipe. Something like global netcat.

And there are plenty of tools that do something similar for specific services, e.g. there is iroh-ssh.

> What is the CPU overhead at link saturating speeds?

We don't have exact measurements, but CPU is not the bottleneck usually.