Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Wednesday, 13-Aug-2025 07:04:35 JST silverpill

   • bengo
   • feld

   @feld @bengo One of the things I like about IPFS is global swarm. I.e. you can look up any file by its hash.

   Does something like that exist in the torrent world?

   • Embed this notice
     bengo (bengo@mastodon.social)'s status on Wednesday, 13-Aug-2025 09:21:42 JST bengo

     in reply to

     • feld

     @silverpill @feld like a magnet link ? https://en.m.wikipedia.org/wiki/Magnet_URI_scheme

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 13-Aug-2025 09:21:42 JST silverpill

     in reply to

     • bengo
     • feld

     @bengo @feld I am not sure, perhaps I misunderstood how they work. Because when I download a torrent, the magnet link always includes a list of trackers, and I thought it is necessary for discovery, but maybe it is not?

     I just tried to remove the tr= parameter, at the client was still able to find content.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 13-Aug-2025 09:27:53 JST silverpill

     in reply to

     • bengo
     • feld

     @bengo @feld If discovery by hash/CID alone is already possible, then "per-file hash trees" would make torrents equivalent to IPFS feature-wise 🤔

   • Embed this notice
     pwm (pwm@darkdork.dev)'s status on Wednesday, 13-Aug-2025 09:40:02 JST pwm

     in reply to

     • bengo
     • feld
     @silverpill @feld @bengo My understanding is that the dht is pretty much just a kademlia implementation. A side effect is that you get better results the longer your node has been up, because you know of more peers. The routing works how the whitepaper describes, walking peers' k-buckets.
     Trackerless torrents are possible in theory but I don't think enough people run seedboxes exposed to the Internet for the network to be robust, or for their client to find torrents reliably, but that's just an armchair opinion
   • Embed this notice
     bengo (bengo@mastodon.social)'s status on Wednesday, 13-Aug-2025 09:41:46 JST bengo

     in reply to

     • feld

     @silverpill @feld hey @silverpill can you figure out how to support resolving did:dht in your impls? 😅 https://github.com/decentralized-identity/did-dht

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 13-Aug-2025 09:41:46 JST silverpill

     in reply to

     • bengo
     • feld

     @bengo @feld My implementation of FEP-ef61 only supports did:key. It doesn't perform DID resolution, which will be implemented later.

     The first supported DID method after did:key will probably be did:web, and after that we can add others with less effort. did:dht looks interesting, but the repository is not very active, the last commit was 10 months ago. Also the link to Rust implementation is dead.

   • Embed this notice
     bengo (bengo@mastodon.social)'s status on Wednesday, 13-Aug-2025 09:41:47 JST bengo

     in reply to

     • feld

     @silverpill @feld the problem with all of these, IMHO, is IPFS does not in practice really work if all you have is the hash of a file. It has to be the hash of an IPFS-specific encoding of a file. (iiuc: torrent too). But yes it sure would be nice if all it took was the hash of the file, which was a common refrain in some of the “next gen IPFS” discussions last year etc. that’s why I linked to BLAKE3 before 😊