[-] jajalayer@lemmy.dbzer0.com 3 points 1 week ago* (last edited 1 week ago)

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

[-] jajalayer@lemmy.dbzer0.com 1 points 1 week ago

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.

[-] jajalayer@lemmy.dbzer0.com 3 points 1 week ago* (last edited 1 week ago)

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.

[-] jajalayer@lemmy.dbzer0.com 11 points 1 week ago* (last edited 1 week ago)

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.

53
submitted 1 week ago* (last edited 1 week ago) by jajalayer@lemmy.dbzer0.com to c/piracy@lemmy.dbzer0.com

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.

[-] jajalayer@lemmy.dbzer0.com 1 points 6 months ago

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

[-] jajalayer@lemmy.dbzer0.com 1 points 6 months ago* (last edited 6 months ago)

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

[-] jajalayer@lemmy.dbzer0.com 1 points 6 months ago

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

5

publication croisée depuis : https://lemmy.dbzer0.com/post/67080379

Hello, since it's complicated to index DHTs, I figured it'd be more efficient to build an index of fingerprints from real data once.

So I've been collecting releases hashes for this index. It can be used for various purposes:

  • check the integrity of your own files (bit rot is a real thing)
  • identify BTv2 torrent files that contain specific files (a database of torrent files is required)
  • locate alive IPFS swarms to join more easily (no need to read all your data multiple times to recompute various CIDs yourself)

The collection contains around 1K releases and weights 40MB. I've prioritized scene Bluray rips of movies (1080p / 2160p). No infohash will be included, as these are not reproducible enough.

I'm using a basic script to add a new release (filename must match the official release name). I'm using others to discover scene releases in a filesystem; retrieve official release names from files using the srrdb api (crc32 search); collect torrents from Prowlarr and H&R them (although I'd prefer crowd-source directly from the community!).

The index is stored on git to allow collaboration. It is hosted using Radicale to avoid centralization and reduce hosting pressures.

If you are interested, join and add your own hashes to the collection in Radicle patches! (see instructions in the README)

Let me know what you think, suggest improvements or discuss similar projects you know about!

[-] jajalayer@lemmy.dbzer0.com 3 points 6 months ago

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

32
submitted 6 months ago* (last edited 6 months ago) by jajalayer@lemmy.dbzer0.com to c/piracy@lemmy.dbzer0.com

Hello, since it's complicated to index DHTs, I figured it'd be more efficient to build an index of fingerprints from real data once.

So I've been collecting releases hashes for this index. It can be used for various purposes:

  • check the integrity of your own files (bit rot is a real thing)
  • identify BTv2 torrent files that contain specific files (a database of torrent files is required)
  • locate alive IPFS swarms to join more easily (no need to read all your data multiple times to recompute various CIDs yourself)

The collection contains around 1K releases and weights 40MB. I've prioritized scene Bluray rips of movies (1080p / 2160p). No infohash will be included, as these are not reproducible enough.

I'm using a basic script to add a new release (filename must match the official release name). I'm using others to discover scene releases in a filesystem; retrieve official release names from files using the srrdb api (crc32 search); collect torrents from Prowlarr and H&R them (although I'd prefer crowd-source directly from the community!).

The index is stored on git to allow collaboration. It is hosted using Radicale to avoid centralization and reduce hosting pressures.

If you are interested, join and add your own hashes to the collection in Radicle patches! (see instructions in the README)

Let me know what you think, suggest improvements or discuss similar projects you know about!

jajalayer

0 post score
0 comment score
joined 7 months ago