Oh shit, I entered that headspace again that I call "BitTorrentMode" where I can't shake that the current state of #p2p is honestly behind what BitTorrent was in usability like a decade ago.
I love all the new protocols for their advantages, but the UX just isn't anywhere near "install some random client and paste a link".
They got it right and I wish it kept going instead of losing relevancy.
BEP46 would have solved the UX of needing to search for updated torrents as something is released.
@mauve True, the poor UX is often baked into the singular mindset of the architecture/protocol, rather than multiple mindsets as involved in creating Web1.0.
What you say about torrent is also true, I can embed a webtorrent video on my site, cos its fallback to HTTP means the UX is the video loading at least as fast as a HTTP call, or faster via peers.
Most P2P systems cant imagine collaborating with HTTP for fallback, or erroring on failing to find the video, so you can fallback in client.
@mitra Yeah, the fallback case is a great example of a solved UX pain. FWIW I think IPFS is the closest (non BitTorrent thing) to having a nice story for that, but I think that ends up materializing in the form of gateway URLs and clients defaulting to using those instead of even attempting the p2p in the first place.
@mauve I don't know if IPFS has fixed it by now, but when I was using it a few years ago, there was certainly no way to incorporate a fallback URL (such as there is with a torrent), and a call to open a stream from a file NEVER returned with an error (and you couldn't time it out because you didn't know how big the file was or how long it should take to start streaming). That was a big reason that we couldn't use IPFS for any of the files in the UX, had to use HTTP and fallback to IPFS.