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...

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.

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.

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 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.