I find it interesting and frustrating that the spec for mutable torrents has existed for years, but no one seems to use it because no major clients support it
@makeworld it's also slow as hell in practice. 😅 And cannot work with WebTorrent due to the reliance on the DHT. FWIW Agregore suppprts it out of the box including publishing. I've been meaning to do some optimization but I doubt it'll be as fast as Hypercore for example
@mauve yeah the other thing I was worried about was that it wouldn't be useful even if it was implemented. How slow is slow though? Bc I feel like even if it took a day to find updates or whatever it would still be super useful.
@makeworld On the order of minutes for lookup in my nodejs impl. Insure about libtorrent but it's on there if you have time to mess with c/c++
@makeworld Yeah 100% agreed. I think libtorrent abstracts out the spec stuff decently IIRC. It's pretty much just mutable put with a bit of structure.
@mauve I wonder if the best way to implement this kind of feature would be an add-on program that just uses the qBittorrent or Transmission API. It would watch RSS/DHT for updates and instruct the actual torrent program to replace what it was seeding.
@makeworld That's a cool idea. One aside, the spec permits for efficiently ovefwriting the existing data but I'm not sure whether implementations actually stay true to that. You'll probs want to poll every 30 mins or something along those lines too since we didn't get the pubsub spec adopted either 😅
@mauve lol minutes is so doable though! I'll need to read the spec but the use cases seem so useful considering how robust and widespread torrenting is. Websites, datasets, Wikipedia, all could benefit from being mutable torrents.