In general people aren't tolerant of lag and spinning circles and other such things when they're trying to watch streaming content. If you're fine with just watching it a little bit later might as well queue it up and left the whole thing down load so it's ready when you're ready.

The former don't want to use it as it degrades their control over the content, and the later don't want to make a new system cause systems that are built on torrents are good enough.

I remember it as it was one of rare apps built in XUL, the same framework as Mozilla apps (Firefox).

https://en.m.wikipedia.org/wiki/Joost

one issue I can imagine would be that each part would discover peers independently where assumption that most peers of previous parts should be expected to also have those files.

second idea would be to use ipfs in that way instead of torrent. that would probably have much easier time for reusing peer discovery between parts and also would solve issue when to stop seeding as this is already build in into protocol.

I guess that creating distributed twitch basing on ipfs would be feasible but not sure how many people would like to install ipfs node before that could use that. that's kind of chicken and egg problem, you need a lot of people before this system starts work really well, but to get interest it need to really perform well so people would migrate from twitch like services.

ofc you can use public gateways. afaik cloudflare have public ipfs endpoint that could serve as fallback

They use bao hashing which is something that I discovered through them (IIRC) and its really nice.

Could create such a protocol though bittorrent/ipfs is fine

I once wanted to create a website which was just a static website.

and I used some ipfs gateway to push it with my browser and got a link of that static website, all anonymous.

Kind of great tbh.

I work on low latency and live broadcast. The appropriate latency of any video stream is the entire duration of it. Nobody else seems to share this opinion though.

It is a thing.

For livestreams there's AceStream built on BitTorrent, but I think it's closed-source. They do have some SDK but I never looked into it. It's mostly used by IPTV pirates. I've used it a few times and it's hit-or-miss but when it works well I have been able to watch livestreams in HD/FullHD without cuts. Latency is always very bad though.

Then for video-on-demand there are some web-based ones like PeerTube (FOSS) and I think BitChute? Sadly webtorrent is very limited.

One possibility as you allude to is licensing. In a P2P streaming model “rights” holders want to collect royalties on content distribution. I’m not sure of a way you could make this feel legal short of abolishing copyright, but if you could build a way to fairly collect royalties, I wonder if you’d make inroads with enforcers. But overall that problem seems to have been solved with ads and subscription fees.

Another data point is that the behemoths decided to serve content digitally. Netflix and Spotify showed up. The reason the general population torrented music is because other than a CD changer, having a digital library was a requirement in order to listen to big playlists of songs on your… Zune. Or iPod. That problem doesn't exist anymore and so the demand dried up. There was also an audiophile scene but afaik with Apple Lossless the demand there has diminished too.

And finally, since people were solving the problem for real, we also entertained big deal solutions to reduce the strain on the network. If you stream P2P your packets take the slow lane. Netflix and other content providers build out hardware colocated with last mile ISPs so that content distribution can happen even more efficiently than in a P2P model.

In short: steaming turned into a real “industry”. Innovators and capitalists threw lots of time and money at the problem. Streaming platforms emerged, for better and for worse. And here we are today, on the cusp of repeating the past because short sighted business mongers have balkanized access with exclusive content libraries for the user numbers.

In my opinion, NAT and the extensive tracking that has led users to distrust sharing their IP addresses are the reasons why it hasn't caught on.

Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.

If you want live high quality streaming, a lot of reasons bit torrent works so well goes away.

Latency matters. In bit torrent if the peer goes away, no big deal, just try again in 5 minutes with another peer, you are downloading in random order, who cares if one piecs is delayed 5 minutes. In a live stream your app is broken if it cuts out for 5 minutes.

In bit torrent, everyone can divide the work - clients try to download the part of the file the least number of people have, quickly rare parts of the file spread everywhere. In streaming everyone needs the same piece at the same time.

Bit torrent punishes people who dont contribute by deprioritizing sending stuff to peers that freeride. It can do this on the individual level. In a p2p streaming setup, you probably have some peers getting the feed, and then sending it to other peers. The relationship isnt reciperocal so its harder to punish freeriders as you can't at the local level know if the peer you are sending data to is pushing data to the other nodes it is supposed to or not.

I'm sure some of these have work arounds, but they are hard problems that aren't really satisfactorily solved

You might want to look into the tradeoffs Discord decided to go with, https://discord.com/blog/how-discord-handles-two-and-half-mi....

Here's some boilerplate for rolling your own, https://blog.swmansion.com/building-a-globally-distributed-w....

In theory you could gain resilience from a P2P architecture but you're going to have to sacrifice some degree of live-ness, i.e. have rendering clients hold relatively large buffers, to handle jitters, network problems, hostile nodes and so on.

0. https://ja.wikipedia.org/wiki/PeerCast

https://github.com/johang/vlc-bittorrent/

Modern streaming protocols sometimes go to absurd lengths to avoid too many hops so you get the data as soon as possible... torrent has so many jumps and negotiations to get to the actual file. It's good for decentralization but decentralization and efficiency go against each other.

Our library is general purpose and can be used whenever you need direct connections, but on top of Iroh we also provide iroh-blobs, which provides BLAKE3 verified streaming over our QUIC connections.

Blobs currently is a library that provides low level primitives and point to point streaming (see e.g. https://www.iroh.computer/sendme as an example/demo )

We are currently working on extending blobs to also allow easy concurrent downloading from multiple providers. We will also provide pluggable content discovery mechanisms as well as a lightweight content tracker implementation.

There is an experimental tracker here: https://github.com/n0-computer/iroh-experiments/tree/main/co...

Due to the properties of the BLAKE3 tree hash you can start sharing content even before you have completely downloaded it, so blobs is very well suited to the use case described above.

We already did a few explorations regarding media streaming over iroh connections, see for example https://www.youtube.com/watch?v=K3qqyu1mmGQ .

The big advantage of iroh over bittorrent is that content can be shared efficiently from even behind routers that don't allow manual or automatic port mapping, such as many carrier grade NAT setups.

Another advantage that BLAKE3 has over the bittorrent protocol is that content is verified incrementally. If somebody sends you wrong data you will notice after at most ~16 KiB. Bittorrent has something similar in the form of piece hashes, but those are more coarse grained. Also, BLAKE3 is extremely fast due to a very SIMD friendly design.

We are big fans of bittorrent and actually use parts of bittorrent, the mainline DHT, for our node discovery.

Here is a talk from last year explaining how iroh works in detail: https://www.youtube.com/watch?v=uj-7Y_7p4Dg , also briefly covering the blobs protocol.

IPv6 multicast is probably the way forward for livestreams but I haven't really been keeping up on recent developments. In theory there could be dynamic registrations of multicast addresses that ISPs could opt-in to subscribe to and route for their customers.

torrent PROTOCOL does not require to download random pieces, in random order.

ONLY bittorrent, inc. COMPANY which releases "Utorrent" and "Bittorent" NAMED APPLICATIONS/PROGRAMS does not want legal trouble from media/music companies. Because STREAMING is other legal category then downloading. There is no other reason for torrent PROTOCOL to not deliver file pieces in sequential order.

if you need instant nanosecond delayed stream, those does not exist anywhere, even radio, tv stations over the air are delayed so they all transmit synchronized. so 0 latency and synchronized can be mistaken for each other.

This P2P stack was meant to allow for mass scaling of lowish latency video streaming, even in parts of the World with limited peer bandwidth to original content source servers. The VC-1 format got into a legal quagmire, as most video streaming protocols do, and it speaks volumes that by the time I turned up in ~2012-ish, the entire stack was RTMP, RTSP, HDS and HLS with zero evidence of that P2P tech stack in production.

My main role was to get the ingest stack out of a DC and into cloud, while also dealing with a myriad of poor design decisions that led to issues (yes, that 2013 outage in the first paragraph of the wiki article was on my watch).

At no point did anybody suggest to me that what we really needed to fix our attention back to was P2P streaming, beyond the fact the company built a version of Periscope (Twitter's first live streaming product), and launched it weeks/months before they did, and were pivoting towards a social media platform, at which point I decided to go do other things.

The technical and legal problems are real, and covered elsewhere here. People want reliable delivery. Even Spotify, YouTube and others who have licensed content and could save a pile by moving to DRM-ified P2P don't go near it, and that should tell you something about the challenges.

I'd love more widespread adoption of P2P tech, but not convinced we'll ever see it in AV any time soon, unfortunately.

[0] https://en.wikipedia.org/wiki/LiveStation

Such a shame that it failed, nothing after it ever came close.

0: https://github.com/pldubouilh/live-torrent

For 'hobbyists' there is a lot of complexity with setting up your own streaming infrastructure compared to just using YouTube or Twitch.

Then for media companies who want to own it, they can just buy their own infra and networking which is outrageously cheap. HE.net advertises 40gbit/sec of transit for $2200/month. I'm oversimplifying this somewhat, you do have issues with cheap transit and probably need backups especially for certain regions. But there isn't much of a middleground between hobbyists and big media cos.

For piracy (live sports streams), I've read about https://en.wikipedia.org/wiki/Ace_Stream being used for this exact purposes FWIW. This was a while back but I know it had a lot of traction at one point.

Plus instead of a million people all wanting to watch Spider-Man 2, those million people have infinite options of short videos or whatever to watch. The desire to watch A Specific Video isn’t what it used to be.

Times have changed and P2P as a common way of sharing stuff is dead to the average person.

Even “modern” cities like NYC are limited to a MAXIMUM of 30Mbps upstream due to ISP monopolies and red tape.

It’s getting better, but Spectrum is still literally the only ISP available for many city residents, and their offerings are so lopsided that their highest-end package is a whopping 980/30.

That’s right. If you use the majority of that 980Mbps your IP overhead will gladly take that 30Mbps, leaving you with just about Zero headroom for anything else.

https://www.bittorrent.com/blog/2016/05/17/bittorrent-live-m...

And if you pay for the streaming, why would you donate your bandwidth to them? Would you get a discount?

Key part of that tech was that it synchronized the playback between all peers. That was nice for stock market announcements and sport events for example.

https://web.archive.org/web/20131208173255/http://splitcast....

https://www.youtube.com/watch?v=R5UYu9jeQbY

https://www.crunchbase.com/organization/splitcast-technology

Besides bandwidth problems (as you can't 100% rely on remote connections), any P2P solution would mean the same fragment will be shared many times between clients; something CDN networks have solved already (just serving content, instead of juggling with signalling)

If the goal is to cut costs — like vendors trying to avoid AWS/CDN bills — that’s a very different problem than building for censorship resistance or resilience.

Without a clear “why,” the tradeoffs (latency, peer churn, unpredictable bandwidth) are hard to justify. Centralized infra is boring but reliable — and maybe that's good enough for 99% of use cases.

The interesting question is: what’s the niche where the pain is big enough to make P2P worth it?

   1 2 1 2
   3 4 3 4
   1 2 1 2
   3 4 3 4

If you have [say] a 640 MB recording at 120 fps you would only need to successfully receive 2.5 MB at 30 fps to be able to watch the entire thing. With a slight delay in playback you could even hop from one sub set of channels to another.

It should work offline too. One could have the cutting edge crispy resolution on a large display or watch the same on a crappy old laptop. (and everything in between)

For fun I one time convert a 3.5 hour lecture to 75 MB and was stunned by how watchable it still was.

1. Hybrid architecture (CDN+P2P): - Use CDN to process backbone traffic, and edge nodes distribute through P2P to reduce the pressure on the central server (such as LivePeer trying to combine blockchain and P2P). - Platforms such as Youku have experimented with such solutions, but they need to weigh the cost and effect.

2. Protocol optimization: - Sliced transmission: Divide the streaming media into small pieces and improve efficiency through multi-path transmission. - Dynamic priority: Dynamically adjust the data allocation strategy according to node bandwidth and latency. - Buffering and preloading: Allow users to tolerate higher latency in exchange for more stable transmission (such as HLS/DASH protocol ideas).

3. Decentralized network exploration: - Projects such as IPFS and BitTorrent Live have tried real-time streaming, but are limited by technical maturity and ecological support. - Web3 projects (such as Theta Network) combine token incentives to encourage nodes to contribute bandwidth, which may promote development.

Churn & reliability: Peers come and go, making stable streaming tricky. Latency: BitTorrent-style protocols aren’t built for real-time delivery. Incentives: Without rewards, too many users just leech. WebRTC: It hits limits fast and often relies on centralized relays. Legal risks: Media companies don’t play nice with decentralized distribution.

Bram Cohen tried with BitTorrent Live, but it fizzled out. Would love to see someone revive this with modern tech — still feels like untapped potential.

We had torrent client/streaming video players maybe 20 years ago already.

> Does anyone have knowledge on why it isn't a thing still though?

It is a thing, it seems you didn't do your research.

There's articles all over the interweb if you went and looked, such as

https://www.makeuseof.com/best-torrent-streaming-apps/

But the reality is for 99% of people Youtube and Twitch work just fine.

Plus most residential ISPs have really poor upload speed, and very restrictive data caps.

I think your other constraints (tree topology & connection prioritization) already describe how BitTorrent works.

I think there's one thing you'd need to change for /live/ streaming, where the file is actually being created /during/ broadcast-- I think the file verification hash systems require the seeder to have the entire file when initially seeding. I think magnet links and .torrent files are based on a hash of the entire file. Do maybe you need some kind of modification to DHT , .torrent , .magnet , to support verification by sequential chunks.