rklaehn

I think this is way overthinking it. It's PHP. Even 2, 3 years ago before usable LLMs, if somebody had told me there is a remote execution vulnerability in php I would have found it completely plausible.

They might be fine if they are still on php4...

Yes, we are happy to take over the burden to provide relays and handle the 3am phone call. See https://www.iroh.computer/pricing

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.

There are several pure browser iroh custom transport implementations that use webrtc. The challenge would be to have this also work with native clients, preferably without blowing up the binary so much that we can no longer ship it to resource constrained devices.

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.

I think this is overly bleak. Bittorrent exists and works since 20 years. And this is something that is more of a threat to commercial interests than e.g. a decentralized social network.

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 and iroh-blobs author here.

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.

Iroh works on most esp32. Here is a mixed bag of examples for various esp32 variants.

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.

There are some projects that implement an iroh webrtc custom transport that works in the browser. E.g. https://iroh-webrtc-demo.datei.jetzt/#?addpeer=fd4341f14b4eb...

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.

We (iroh) don't do birthday paradox hole punching yet. There is some internal debate whether it is worth it.

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.

They built something amazing and now have a nice exit. The code remains open under a non profit foundation. I don't think it is that bad. If working conditions are too bad people will just quit and work for the foundation.

If you want to compare iroh with something out of the IPFS world, iroh is basically "what if you build libp2p on multipath QUIC".

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.

Main author of iroh-blobs here.

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.

There is this https://github.com/bittorrent/bittorrent.org/pull/174

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.

There are some technical differences since we build on QUIC, not on wireguard. We think that QUIC offers some advantages for demanding use cases.

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

We have not implemented this yet, and there are some things to consider. But there is an open standard for load balancing QUIC connections, and we have hooks in our QUIC implementation noq to generate connection ids that should allow us to work with this open standard.

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.

You don't have to use it. But here are some answers:

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.

This might not be a giant difference in practice.

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.

We do have browser support, but as of now it is relay only.

We have made some progress reducing the set of patches that is needed to get iroh to run on an esp32 with SPIRAM. We just need a little dependency reduction for it to fit, but other than that iroh 1.0 works out of the box now.

You only need to know the public key of the target endpoint.

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.

That’s the beauty of it. The app end user doesn’t have to do anything.

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.

> I might have assumed io_uring would be the high throughput kernel interface for Linux.

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.

Yeah, that’s from a friend of mine. If something like this would gain traction that would be cool.

It might be an option to provide a good migration path for projects that build on libp2p.

But in the long term you probably don't want two fully featured p2p networking stacks in your dependencies.

Yes, exactly. Basically we chose the bottom edge of zooko's triangle.

https://en.wikipedia.org/wiki/Zooko%27s_triangle

A mapping from a scarce but human readable name to a non-scarce but not human readable name would't be that hard, but we haven't done this yet.

If we do it it will probably be an additional crate reusing some of our infrastructure, not built in to iroh itself. There are a lot of use cases where the non human readable names work perfectly fine.

We would implement two versions, one using DNS and one using an appropriate decentralized system like ENS.

I think we do very well with devices devices with limited bandwidth and changing connections. We are able to saturate a 1 GiB link from a normal desktop PC or good phone, but have some work to do to saturate a 10 GiB link with a single process.

We don't have a comparison benchmark, but we are fast enough that we are not the limiting factor for many use cases.

In many cases the performance bottleneck is the interface to the kernel to send and receive UDP packets. Our QUIC implementation is using all available tricks to make this as fast as possible. For example on OSX we use the sendmsg_x syscall to send multiple UDP packets in one syscall. On Linux we use GRO/GSO and recvmmsg to send/receive as many packets as possible.

But to be completely honest, in some cases TCP is still faster for raw throughput on server class hardware. Decades of optimisation have gone into TCP. But QUIC/UDP is quickly catching up. All the major cloud vendors bet heavily on QUIC/UDP and are optimizing it.

Since we just do p2p QUIC we benefit directly from all improvements in this area.

That is correct. Iroh connections are at L6, individual protocols such as blobs or gossip are at L7.

From the OSI point of view, QUIC itself is a bit of a layering violation. It covers transport (L4, Reliable ordered delivery, stream multiplexing, congestion control, ...), session (L5, connection establishment and lifecycle, path migration, ...) and presentation (L6, encryption).

And of course below that we have the ability to provide custom transports.

This was done intentionally in QUIC to provide more control. The application layer doesn't have to care about what goes on below, but for some advanced use cases it can know what's going on and even influence which path is being used.

QUIC/TLS being such a comprehensive and well tested package allows us to delegate a lot of the work and just add a tiny bit of logic to make it peer to peer.

Although delegate is not exactly right, since we ended up having to write our own QUIC implementation, noq, to support QUIC multipath...

Previous similar attempts were often not pragmatic or frugal enough. They cared about peer to peer purity more than about it working under all circumstances. They also frequently overabstracted things.

So we got into the sad situation that people associate peer to peer connectivity systems with having to frequently debug the entire stack and having recurrent performance or connectivity issues.

A part of the motivation for the iroh team is to change this notion by being very pragmatic and minimalistic. E.g. the use of relays vs. enlisting other peers to help with hole punching.

We wrote a small demo app called sendme to show off iroh. It is cli only, works on all operating systems that we use internally, and we frequently use it to send around qlog files:

https://www.iroh.computer/sendme

There are several projects inspired by sendme that use the same protocol but add mobile device support and a GUI:

https://www.altsendme.com/en

https://github.com/ARK-Builders/Drop-Desktop

https://github.com/zignig/sendme-egui

I love mainline and also really appreciate how lightweight it is by just using UDP packets. But UDP packets have their limits. With the maximum MTU you can expect to work, the payload can't be more than about 1000 bytes, which is the limit of bep_0044.

But there are some use cases where you want to store a bit more than 1000 bytes. Not giant amounts, but maybe 4 KiB. Mainline won't ever be able to do this.

Iroh 0-rtt is very lightweight. On the network level you see one or two UDP packets flying in one direction, one or two UDP packets flying back, and that's the end of the interaction. You close the connection, and all state you have to retain is a session cookie on the client side.

It is still much heavier than bare UDP packets, but much lighter than a normal 1-rtt QUIC connection, which is already pretty lightweight.

Here are some details about 0-rtt. The API has changed slightly since then, but the basics remain the same of course: https://www.iroh.computer/blog/0rtt-api