6 ms·
Iroh got started with IPFS-style content-addressed blob transfers as the primary way to use it, still has that functionality but its now a bit of a second tier
by devttyeu 23d ago
Iroh got started with IPFS-style content-addressed blob transfers as the primary way to use it, still has that functionality but its now a bit of a second tier citizen. See https://docs.iroh.computer/protocols/blobs https://docs.iroh.computer/protocols/blobs
Besides just p2p streams seem to be much more useful, those are plug-and-play into most software, e.g. I wrote https://github.com/magik6k/git-remote-iroh https://github.com/magik6k/git-remote-iroh that just plugs the git remote proto into iroh and lets you move repo commits between computers by just copying a string from one place to another on push. Doing that with blobs - not gonna happen, not that easily.
- rklaehn 23d agoMain 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.
- xbumblefudgex 23d agofinally some good news!
- tancop 22d agoAll the protocol needs at this point is a DHT and a standard representation for directories. Everything else like data storage layouts and node trust systems can be handled client side.