Thanks for sharing! It looks like it is based upon Iroh too (lower layers).

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

For Iroh-blobs, Dropwire would be the easy-to use all-in-one app (not appropriate for mass sharing just yet). Then there is the iroh-http library, allowing to use Iroh-blobs on a web browser (without installing anything; a website similar to instant.io / webtorrent.io).
Also note that most of the big Bittorrent peers have a pretty sophisticated setup anyway (allways-on machine with raid array; bittorrent daemons; remote client; VPN; download automation indexers; media library etc).

I noticed the example they provide contain a list of file (CID points to a folder): https://y7rmokt6h5mryuauw83em4u1br6tqrukaw3ngtde7zp8p3bg6hto.blake3.net/ or https://5ti57aszf7kaicsncb4wgigkf9bju39kofiz8dthwdujkmz85u8y.pkarr.net/; the latter identifies the same content by a public key. I guess the public key identifier allows mutable linking.

First time I hear of it. They say this is for private networking only. Also it’s only a network stack for now (the “BlockStore” storage component is not yet defined). So apparently it’s not for public filesharing. They compare it to Tor but it looks more like an overlay mesh network at first sight.

Sorry for that! Basic is: it’s fully decentralized, and when anyone starts sharing a file, it joins a unique swarm of seeders. Whereas on Bittorrent, there is one swarm for each torrent, each private tracker for the same file, and also for folders (TV episode; TV season; TV series); this is called “swarm fragmentation” and leads to low speed and dead torrents.

For now it’s only scene releases, so there’s no duplicate (not sure if this is what you mean).

Hi, not sure I get your point. A release has a fixed name and resolution. Regarding genre classification, I estimated if was too complex to determine reliably. And I wanted to avoid storing metadata.

Dates folders are there to reduce directory sizes, similarly to a merkle tree with only one level. This is due to performance limitations with large directories in most filesystems and also in Git. Also it still allows for easy manual search (only the date is required).

Note: there can still be several releases for a single movie (several resolutions and sources, LIMITED/REPACK etc).

I don’t think it would scale for many millions of files.

Hi, yes it definitely sounds similar for the media files database side. Using a DHT crawler, you can identify new torrents matching specific file tree roots (so only works for bittorrent v2, which is not used so much for now), and update swarms statistics (S/L).