things like this give me host for decentralized video hosting:
- rented blossom services
- client-HLS-blossom encoding support for high performance video hosted in blossom chunks on your own node or rented node.
one day far in the future... disrupt youtube and rumble?
restore the internet to its former glory?
nostr:note1cxxp8dxzkv8ya45duuclncyveqprk86q08ymrvky73lmgrrc9xtqvqpgp2
hope*
nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 is working this out
Only web-friendly solution that can handle swarming and enforces checksums is webtorrent, like we do with lightning.video
thats a terrible protocol for video though, if you actually care about perf. cdn-based blossom nodes would be way more efficent
That's not correct, webtorrent is as fast as regular http chunking because it supports http seeds
Lightning.Video launches videos as fast as any CDN because it is a CDN with webtorrent layered onto it.
this is very misleading. the bittorrent protocol is not optimized for video streaming. try building a tik-tok style client that has a near 0 time to first frame latency for multiple videos. with bittorrent there is a lot of gossip overhead.
i literally talked to bram cohen about this in person. this is why he was developing bittorrent live which unfortunately became closed source.
Bram didn't make WebTorrent, Feross did.
its still the bittorrent protocol, over the web. I don't see how that changes anything I said
i think we just have different definitions of performance. if you think webtorrent beats youtube in terms of performance I don't know what to say.
Youtube is performant because its http to a geographically close datacenter.
WebTorrent layered over a traditional CDN is the same exact thing
I'm not sure what's so hard to understand, WebTorrent is regular CDN capable with regular HLS chunking... same exact performance, it's additive when it reduces bandwidth costs by shedding chunks over RTC to peers.
Yahoo literally used this for their content delivery at massive scale already, your assumptions are wrong.
It's not Bittorrent, it's still http and HLS... WebTorrent as additive not subtractive.
I'm afraid you're misinformed. We've been using it for years for precisely the performance reason
The web-seeding nature of WebTorrent is beyond than normal Bittorrent
The chunking and ordering is the exact same as HLS, WebTorrent then adds onto that the ability to chunk over RTC in the browser to handle swarm events.
I wonder if it would be a proper solution to fetch the first X chunks of a video from a blossom server, possibly at a lower quality, and then switch to something else if the user continues on that video instead of swapping again.
I mean, that should give you both low latency withoug giving up on lower distribution costs, just need to work out the complexity cost of such a solution that is.
That's exactly what WebTorrent does by using webseeds. It's providing a redundant source for chunks while maintaining the raw performance of a traditional source.
An array of webseeds in the magnet also allow it to download chunks from disparate CDN's without a load balancer to handle that in the back-end, if one gets rugged your links still *just work*
I think the “near zero latency” is still a valid UX concern.
Do you know if it’s possible to setup a webtorrent library in a way that it is forced to try fetching from HTTP the first couple of chunks and only after a short delay fire up the lookup for seeders?
It's already doing that, there's no round-trip to a tracker required before hitting the webseed directly to get the mov atom and first chunks.
It's just a client that makes use of additional data.
And this is a cool PoC
5a3290295d4d8b28b696d4d13fe3fa9294b67f672b730dc676953697b96f6ac4 by nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9
Correct:
nevent1qvzqqqqqqypzqun2rcnpe3j8ge6ws2z789gm8wcnn056wu734n6fmjrgmwrp58q3qyv8wumn8ghj7enfd36x2u3wdehhxar
Already doing it
The client encoding ?
wtf is phoenix. no p tag :(
