3 ms·

In 2007 I uploaded a rather obscure TV show to Demonoid, ripped from DVDs that were quite difficult to obtain and that I have long since lost. A few months ago

• tnel77 3y ago
  That is so awesome! Thanks for sharing (both the story and the original upload).
• indigochill 3y ago
  > "Distributed cloud backup" Relatedly, when Docker started charging open source projects for Dockerhub storage, a friend and I started brainstorming a torrent registry driver (although we didn't find a way around the project still needing to provide a signature for verification at least, even if it didn't need to maintain hosting for the image itself) Nothing to show for it just yet, but point being I think this "distributed cloud backup" idea has a lot of interesting applications still.
  • londons_explore 3y ago
    What's the signature problem? For a read-only registry, signatures can all be included in the torrent. For a versioned registry, all the info can be stored in any cloud key-value store - eg. The bittorrent DHT
    • indigochill 3y ago
      It could just be a lack of understanding on our part, but here's the scenario we're thinking about: Say the Redis team seeds a redis:1.0 image. So far, so good. But what if a nefarious hacker seeds a redis:2.0 image? In a traditional registry, the auth system for the registry ensures that only those who are authorized can write to a particular registry. But in (at least our understanding of) a swarm, there is no auth and therefore no way to know if a particular tag of the redis image in the swarm is legitimate or not. if I understand you, this is where you're saying the info can be stored in the DHT, which I don't really understand at the moment but if so that sounds like something we should look into.
      • rakoo 3y ago
        It has always been possible to store immutable data in the DHT, that's partly what it was built for. "This is a sha1 of a content, I want to know what content is behind" There is a BEP (Bittorrent Extension Protocol) for storing mutable data: like all good things in computing, it's just an indirection. Create a pair of asymetrical cryptographic keys for a specific (mutable) content and store the hash of the public key. People will search for that hash, get to some content that is any bytes you want but signed with the private key. What you want is not exactly that, but more of a naming system. The easiest would be to let each image owner be their own source of truth: the redis team puts up an HTTPS server with a well known path, say "/.well-known/docker?identity=redis:2.0" and the reply includes the magnet link. My node would cache the association under the assumption that it never changes (it shouldn't; a change in the image implies a change in the name). As you yourselves discovered, the swarm doesn't solve the naming issue (ie Zooko's triangle), there needs to be a third-party here
        • anacrolix 3y ago
          https://github.com/anacrolix/btlink https://github.com/anacrolix/btlink
  • didntcheck 3y ago
    It sounds like IPFS (or other content-addressed distributed data stores) may be more what you're after there than Bittorrent
    • indigochill 3y ago
      IPFS would be another potential solution. What drew us to Bittorrent for this use case is the (at least original) ethos of clients both downloading and uploading cooperatively such that as long as there's any community that values the image, it will continue to be available (which would basically be true for an IPFS implementation as well). But the registry implementation in the "distribution" project takes storage drivers, so an IPFS storage driver is certainly a possibility. In part for me going with Bittorrent was also just an excuse to get more familiar with the technical details of Bittorrent.
• didntcheck 3y ago
  Out of interest, do you know if it was the exact same torrent (modulo trackers), i.e. the same infohash/magnet? You could have a look at the created date in the metadata to get an idea. One unfortunate thing with torrenting is how you'd often get the same content but in slightly different torrents, sometimes differing only by "torrent downloaded from xtremetrackrr69.txt", which would split the users into different swarms. Bittorrent 2 does actually fix this, by having per-file hash trees rather than non-aligned blocks, but you do still need to add each torrent before your client can notice the duplicate files. Though perhaps there exist reverse indexes which can find other torrents for a given file hash now
  • arp242 3y ago
    I don't know; it says "uploaded on 2007-10-19" with my (old) username, so I assume it's the same torrent. It doesn't have the "Downloaded from Demonoid.txt" file though, so maybe I'm misremembering that I uploaded it to Demonoid, or it's a different torrent (but with "my" files). To be honest I can't be bothered to look at it further, but here's the torrent if you want to look at it yourself: https://thepiratebay.org/description.php?id=3848177 https://thepiratebay.org/description.php?id=3848177 (with the disclaimer that some comments in the README do NOT represent my current attitude or views, and haven't for well over 10 years)
    • TheHappyOddish 3y ago
      > with the disclaimer that some comments in the README do NOT represent my current attitude or views, and haven't for well over 10 years Oh come on, it can't be that bad... > and no, stupid "Sci-Fi" like Stargate or Enterprise is not good science fiction Wow. Thank you for atoning for your sins.
      • arp242 3y ago
        To be honest I still don't really like either; Stargate is fun at times but superficial and has some serious weirdness (in a bad way) at times, and Enterprise suffers from even more time-travel nonsense than Voyager did (plus some other things). It's okay to like things or not like things, it's the "bruh huh I'm so much smarter than all you mainstream nincompoops" kind of attitude I dislike. I suppose it's a classic youthful "rebel against the mainstream" kind of attitude shrug