The new iroh-blobs design restores the initial “one unique identifier for each file” ethos of IPFS (abandonned by IPFS), to reduce swarm fragmentation. It takes the standard Blake3 hashing algorithm to generate file CIDs (equivalent to Bittorrent magnet infohash).
The protocol uses the Mainline Bittorrent DHT (not a custom DHT). There is no notion of block CIDs (no potential deduplication, but also less scalability issues for announcing each block CID on the DHT).
So that’s a lot of design simplifications that will improve implementation time.
If you are interested, have a try at Iroh-share, a CLI and TUI Rust implementation.
iroh-share is not decentralized filesharing.~~iroh seems like a stack. like https://libp2p.io/docs/~~
eventually they may have a tool that does decentralized filesharing.and if i was going to dev my own solution from scratch, iroh would be my pick.
but i’m lazy so i use ipfs(kubo) . it works
update: i now see that iroh has https://github.com/n0-computer/iroh-share
however it does not share partial pieces like bittorent and ipfs .
in many cases, that might actually be more efficient (like an ordinary download).
and from my understanding: it supports multiple providers as the source. ( so it is decentralized ).
i think there are advantages and drawbacks.
From my understanding, peers stream merkle-tree leaves to the requester, allowing to verify data while downloading: https://docs.rs/iroh-blobs/latest/iroh_blobs/protocol/index.html#responses
So it does have piece chunking for large files, which correspond to the native Blake3 chunks.
The same goes for shared directories (sharing each file root blake3), I think this is called a “Collection”.
i think https://github.com/mrsarthi/Chorrent is a better bittorrent/ipfs replacement.
from my understanding, iroh-share is like ipfs-style global uploads, and then can be fetched from any peer with continuation ( like wget -c ) .
Thanks for sharing! It looks like it is based upon Iroh too (lower layers).