> Your best bet seems to be webtorrents indeed.
I wish it was that easy. A few more details then.
#p2p #cdn #blossom #devstr
More precisely, p2p-media-loader is actually used in PeerTube: it's a wrapper that combines the usage of traditional CDN + WebTorrent, and they definitely have this complex design not out of the blue; others didn't really work.
https://github.com/Novage/p2p-media-loader#how-it-works
In an ideal world, I wish it was just normal Torrent (which is at least impossible from browser engines).
And with just WebTorrent (Torrent on top of WebRTC)—there are some WebRTC-related traps:
- at least the warm-up is too slow, according to p2p-media-loader devs
- due to privacy settings or/and ISPs behind certain kind of NATs, one may not have a functioning WebRTC-based peering at all (only connections through TURN, which is not supported in p2p-media-loader; because that would be an unnecessary complication since they have to use the CDN anyway).
There are more. There's no way to escape the WebTorrent tracker and use DHT due to some browser limitations, and at the same time you can't have too many of the trackers (iOS/Safari in particular may aggressively close WebSocket connections out of the blue if it decides there are too many of them, and it can be challenging to handle this properly if at all).
These are just a few things I recalled from when I was setting up vidstack player + p2p-media-loader on my website.
In two words, thing that will work in practice is (an event kind 10063 server list) of Blossom-based CDNs (at least for warm up) + p2p-media-loader (only helpful in case of multiple concurrent connections) + stable 1Gbps+ network.
Other paths are known frustrating traps; it's hard to even test/debug this stuff because you can't easily simulate the identical weird NATs some ISPs have.