Ask HN: Why is there no P2P streaming protocol like BitTorrent?
218 comments
·April 14, 2025bawolff
Part of the reason bit torrent works really well is that the file is downloaded in random order. It lets everyone cooperate, while still being robust to bad peers, bad network connections, churn etc.
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
arghwhat
This comments on why bittorrent as is isn't used for live streaming, not why P2P shouldn't be used for live streaming
> 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.
First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want.
Second, standard HLS sets a nominal segment size of 6 seconds (some implementations will go as high as 10 seconds), and a client will usually cache multiple segments before playing (e.g., 3). This mean that you have 18 seconds before a segment becomes critical.
This is not a difficult thing for a P2P network to handle. You'd adapt things to introduce timing information and manage number of hops, but each client can maintain a connection to a number of other clients and have sufficient capacity to fill a segment if a connection fails. Various strategies could be used to distribute load while avoiding latency penalties.
Low-latency HLS uses much smaller segments and would be more demanding, but isn't impossible to manage.
> BitTorrent punishes people who dont contribute
Private communities punish this behavior, BitTorrent clients do not. Most new downloads will appear as freeriders for a long time, and only over long periods far exceeding the download time will enough compatible seeding opportunities arise for them to contribute in any substantial way.
The network does not need everyone to seed, it only needs enough people to seed.
bavell
> First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want.
The problem here is that BT works so well because the clients default to "good behavior" (prioritize rare pieces first) and discourages "bad behavior" (leeching/no upload).
This tilts the balance on the whole enough to maintain the health of the network. If you change these, you'd need to introduce other mechanisms to preserve the network incentives.
amy_petrik
>This tilts the balance on the whole enough to maintain the health of the network. If you change these, you'd need to introduce other mechanisms to preserve the network incentives.
This is the real key point here. In the P2P wars, only bittorrent was the winner (though the old networks still live on and you can find interesting stuff in them...) - the timeless lesson is leeches need to be getting the short end of the stick, people who give back, the prize bonus. It's a fundamental characteristic of human nature here, tragedy of the common leech or something like that
arghwhat
With streaming, the service provider is generally also controlling the clients, so they should be much better off when it comes to client behavior.
In case of bring-your-own-client, the incentives are exactly the same: Clients would likely default to good behavior as network health equals user experience, and exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey.
PaulHoule
I have a relatively slow ADSL connection, it's not unusual for me to be able to download 100% of the file at say 95% the theoretical rate without uploading anything. If the network has enough upload capacity to do this, does it really need my upload? (Note my client is still there if somebody needs a rare block)
I remember some Bittorrent networks circa 2005 or so which tried to monitor you and punish you for not contributing and this was a disaster for me since my upload is necessarily a small fraction of my download. What I found is that kind of network seemed to perform poorly even when I had a good bidirectional connection. As I saw it, people who have the ability to upload more than they download are a resource that that kind of network can't exploit if everybody is forced to upload as much as they download.
arghwhat
You are not required to seed immediately, nor even the same asset. Unless the rules have changed, you would usually just be required to maintain a particular minimum seed lifetime ratio that is easily achieved by idle seeding a library.
The point is to ensure network health with a metric that is simple to understand and verify: that you have been a productive. If you aren't seeding, someone else has to pick up the slack and the network didn't benefit from you obtaining the blocks.
The community itself benefits by giving members a guarantee that stuff there is available with abundant bandwidth, instead of relying purely on the unpaid goodwill of others.
null
mannyv
Nobody who does live streaming should set their gop to 6 seconds. That's way too big. I set ours to 2 seconds, which lets mobile adjust more quickly to their bandwidth limits.
And as a note, video segments for live are usually set to no cache, as are vod segments. The CDN does the caching. The client should keep segments around if you're doing rewind, but that's a client thing.
Protostome
If I remember correctly, PopcornTime was able to stream via BT. Your claims are mostly correct, but I think some compromises can be made to make BT clients streaming proof. For example:
1. locally-randomizing segments download order
2. Create a larger buffer
3. Prioritize parts coming from slower connections
lordnacho
This is still just streaming a static file though. Adjusting which segment to get will work, buffering will work, and people don't mind their movie starting a few seconds after they press play.
If I'm streaming live, I need the frame immediately, and it doesn't help much to get later frames after the frame I'm missing.
Protostome
Live streaming is, by nature, a "one-to-many" distribution model, where content flows from a single source to many viewers in real time.
BT, on the other hand, is fundamentally designed for "many-to-many" distribution, where peers share pieces of content with each other over time. This isn't just a question of tweaking the protocol—it's a fundamentally different problem. Unless you're willing to compromise on the immediacy of the stream, using BT for true live streaming isn't really a good fit.
jack_pp
what if everyone agrees on a 10s delay?
earnesti
I remember testing popcorn time and other bittorrent streaming tools back in the days. They worked "OK". Yes, you don't get the netflix experience. But on popular titles you get "good enough" streaming experience. You have to wait like 30 secs to get started.
fermentation
Part of this was the fact you needed a pretty decent connection speed and that the files themselves were extremely compressed
eklavya
The main difference is liveness of the stream. Live streams are much much more difficult and much less forgiving.
karel-3d
I am not convinced about the random order stuff. If most people will stream from the start then the start will be more seeded? So it's all good.
And the order is requested by the client, and there are clients that go in the sequential order, like Deluge
mihaic
The benefit of a random order is that it forces you to actually keep all the packets, which makes upload more likely. Streaming lets you get away with not storing the whole file, which makes bad actors more likely.
And, sure, some BT clients can stream the data, but what the default is makes a huge difference.
hinkley
People will shut off the moment they get the full file. The randomness means that the last packet is as likely to exist as the first.
Would you want to watch the beginning of something that didn’t have an ending? How frustrating would that be?
bawolff
If we are talking about a live stream (and not a stream of a static file), having the start be more seeded is useless.
Calwestjobs
mpeg stream / TS filetype / DVB-T/C/S broadcast IS static file, all 3 is same format, this format deals with every point you made... download specs and educate yourself.
same with streaming audio, chunk IS static file, so every phone call you made last 30 years is static file.
delusional
If everybody starts at the start then it will be very poorly seeded when everybody wants it, before the being well seeded right when nobody needs it.
zveyaeyv3sfye
That's only true if everyone starts at the very same moment in time. Of course that is not reality, and it works out well in practice.
Calwestjobs
"well seeded" means what exactly?
if i can send 2 copies of piece to 2 people immediately as i got it, then if my download takes 20 ms and sending it another 20 ms is it "well seeded" for those 3 people after 50 ms? or after how much time it is "well seeded" ?
Calwestjobs
yes you are correct, BitTorrent - sequential download also works exactly like that.
people seem to have need for 0ms nano ultra low latency streams for watching movies,... they are insane. they want to be extraordinary high speed traders but with movies not stocks. insane
delusional
I don't think people are appreciating the nuance of what you're saying. Most of what you are saying isn't accurate for netflix style streaming, which would actually be more aptly called "video on demand", but is very applicable to "live streaming" in the sense of live sporting events or news broadcasts.
Video-on-demand is perfectly implementable on top of BitTorrent. As you say, there are some latency pitfalls you'll have to avoid, but that's nothing you can't hack yourself out of.
Livestreaming is a different beast. As you say, the problem with livestreaming is that everyone needs the same content at the same time. If I spend 200ms downloading the next 500ms worth of content, then there's nobody to share it with, they all spent the 200ms doing the same. BitTorrent relies on the time shift that is allowed between me downloading the content and you requesting it. If you request it before I've got it, well I can't fulfil that request, only the guy I intend to get it from can.
If you wanted to implement something like that, you would probably pick a tree of seeders where the protocol would pick a subset of trusted nodes that it would upload the content to before then allowing them to seed it, and the have them doing the same recursively.
That would obviously introduce a bunch of complexity and latency, and would very much not be BitTorrent anymore.
ralferoo
I don't think he's saying it needs to be BitTorrent, just applying some principles from it.
For example, say you have a cluster of people on the call in the US and another cluster in the UK. Ping times are 100ms or more across the ocean, there will be some random packets lost, but ping times within the UK are around 15ms max. By working co-operatively and sharing among themselves the clients in one cluster can fill in missing packets from a different cluster far quicker than the requesting them from the originating host.
In general, the ability to request missing packets from a more local source should be able to improve overall video call quality. It still might be "too late", because for minimal latency, you might choose to use packets as soon as they arrive and maybe even treat out-of-order packets as missing, and just display a blockier video instead, but if the clients can tolerate a little more latency (maybe a tunable setting, like 50ms more than the best case) then it should in theory work better than current systems.
I've been mulling over some of these ideas myself in the past, but it's never been high enough on my TODO list to try anything out.
delusional
> By working co-operatively and sharing among themselves the clients in one cluster can fill in missing packets from a different cluster far quicker than the requesting them from the originating host.
That's only true if you assume the nodes operate sequentially, which is not given. If the nodes operate independently from one another (which they would, being non-cooperating) they'd all get a response in ~100ms (computation and signaling time is negligible here), which is faster than they could get it cooperatively, even if we assume perfect cooperation (100ms for the first local node + 15ms from there). It's parallelism. Doing less work might seem theoretically nice, but if you have the capacity to do the same work twice simultaneously you avoid the synchronization.
Basically, it falls somewhere in my loose "tree based system" sketch. In this case the "trusted" nodes would be picked based on ping time clustering, but the basic sketch that you pick a subset of nodes to be your local nodes and then let that structure recursively play out is the same.
The problem you run into is latency. There's no good way to pick a global latency figure for the whole network, since it varies by how deep into the tree you are. As the tree grows deeper, you end up having to retune the delay. The only other option is to grow in width at which point you've just created a another linear growth problem, albeit with a lower slope.
bawolff
I generally agree, but once you do that you lose most of the properties that make bit torrent so effective.
E.g. if you arrange the network into a tree like that, you need to make sure all nodes are matched appropriately in terms of bandwidth, latency, geography, number of connected nodes. Now you have to somehow the network topology stays good in face of churn and bad peers. Suddenly everything is complicated and not looking very p2p.
Maybe dufferent protocols are possible to manage that, but i think there is a reason why p2p protocols kind of didn't develop much beyond bit torrent.
HumblyTossed
Just for shits and giggles, I wonder if a protocol similar to HLS, where each peer is assigned a segment to transcode / cache, would work for best cases. If a peer drops, that segment is assigned to another peer. Or if there are, say, 5 peers, double up on the next segment to increase odds it will be done.
Just a mental curiosity is all.
calvinmorrison
> Part of the reason bit torrent works really well is that the file is downloaded in random order.
That's basically true for one client (transmission) - who specifically refuses to allow linear ordering. Most clients implement this.
To enable it, its about a 3 sloc change.
I hate clients that dont work for the user.
wing-_-nuts
>That's basically true for one client (transmission) - who specifically refuses to allow linear ordering. Most clients implement this.
Transmission does allow you to set a particular file (let's say the first file in a series) as 'high priority' though so it's not like they don't allow any change to the behavior
calvinmorrison
good for them. they specifically refuse to implement this feature even though its a tiny change for the 'good of the ecosystem' or something stupid.
PaulRobinson
For a while, I was CTO of a company called Livestation [0], which as the Wikipedia article states, was "originally based on peer-to-peer technology acquired from Microsoft Research".
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.
garganzol
I used LiveStation from time to time, and just for fun I was playing around with finding out when and how it employed P2P protocols. Needless to say, I never found any evidence of P2P in LiveStation. And now I know why :)
Thank you for bringing up the warm memories I thought I no longer had.
PaulRobinson
Thanks for supporting a business that was pretty cool, once. I bailed as it got into the consumer livestream space, but sometimes think about resurrecting it as a higher-quality OTT app that isn't rammed with absolute junk and ads. The work that platform did during the Arab spring was significant, and I can't honestly point to a good modern alternative today.
apitman
You bring up a good point. It's interesting that YouTube at least doesn't do p2p for their non-DRM content.
googlryas
Sounds like a recipe for dissatisfied users
"Why's my internet slow? Oh, YouTube is uploading a bunch of stuff to other people"
"How did I hit my bandwidth cap for the month already? Oh, youtube is..."
hamiecod
But bandwidth is extremely cheap in 2025 to the point that I do not even check my bandwidth usage and I have never reached my 2TB/month bandwidth cap in the last 3 years.
Secondly, the p2p system will be advantageous for the videos that most people watch, i.e., popular videos. This implies that the "popular" video will have a large number of concurrent users who are transmitting a small part of video to just 3 other peers who are then transmitting the same part to 3 other peers.
This way, the bandwidth usage for uploading is reduced.
apitman
Those problems are implementation specific
andruby
Splitcast Technology built this in 2012. The company folded (couldn't find revenue, and had founder struggles ) but as far as I remember the tech worked. It still needed a lot of seeding nodes, but a significant chunk of the bandwidth was provided by the "viewer peers".
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
miyuru
There is peertube and webtorrent, but they does not seem to catch the mainstream users.
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.
bawolff
Peertube and web torrent aren't doing live streams as far as i know, just stream of pre-recorded video, which is still a lot harder for p2p than random order download, but not in the same ballpark as a livestream.
> Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.
I think its money well spent.
boudin
Peertube supports live streams https://framablog.org/2021/01/07/peertube-v3-its-a-live-a-li...
There is a lag between the source and the audience, maybe it's been improved in the last 4 years though, not sure.
bawolff
Hmm interesting i didn't know that.
I couldn't find much docs on how it works, just https://docs.joinpeertube.org/contribute/architecture#live
Sounds like they break the stream into very small segments and publish each of those with bit torrent (?), they seem to claim about 30 second delay and scale in the hundreds but not thousands. Certainly impressive if true, i wouldnt of thought such an approach would scale so well. Of course its still a far cry from twitch, but nonetheless impressive.
martinald
The real reason is that bandwidth is dirt cheap, if you know what are you are doing at scale.
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.
throwaway920102
This sounds like fodder for a really interesting blog post tbh. I would read it.
imtringued
This is basically the answer.
Minimum latency broadcast forms a B tree. A tree is by definition not peer to peer. The number of branches per node is upload speed divided by bandwidth of the stream. This branching factor is extremely low for residential internet with asymmetric high download and low upload speeds.
Once you add malicious adversaries in the P2P network or poor network connectivity, each client will need to read multiple streams via erasure encoding at once and switch over, when a node loses its connection.
miohtama
There was Joost in 2008, from Skype founders. Skype was originally P2P until Microsoft acquisition and killing this legally questionable feature - need to feed the big brother (: Joost raised ~$50M.
I remember it as it was one of rare apps built in XUL, the same framework as Mozilla apps (Firefox).
pests
PriitK of Joost/Sykpe was also involved in the original Kazza. I've told previous stories of his involvement in a 1990s MMO spaceship game, where he recreated the original buggy/cheat-filled client (Subspace) and released the now standard replacement (Continuum).
lathiat
Came to share this too. I used Joost at this time. Got me into watching the world poker tour on the platform and into playing poker and watching other live poker.
whalesalad
I distinctly remember living alone in my first apartment and trying to use Joost like a TV. It was a dismal experience.
elmerfud
People have tried to build BitTorrent clients to do this. As far as I know they never took off. The primary problem is you oftentimes don't get people who want to share back or who have firewalls or other connections that don't allow them to share back. So you end up with a few people who end up seeding everything out. The second problem is in order to watch a streaming protocol things need to arrive in order. It is totally possible to do with BitTorrent and request the blocks in the order that you want but you may not always be able to get them in the order you want.
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.
jeroenhd
Popcorn Time did this and it worked great. Starting a torrent wasn't instant, but once a buffer was built up, it streamed just fine.
Popcorn Time got taken down pretty hard because they became too popular too fast.
A commercial solution could have a seed server optimized for streaming the initial segments of video files to kickstart the stream, and let basic torrents deal with the rest of the stream.
SXX
Popcorn Time still works and used by everyone who cares. It's just not as hyped anymore.
bayesianbot
The biggest issue I've seen with these is the networking limitations in a browser - there might be hundreds of seeders for a video and using a normal streaming torrent video player works well, but as torrent clients in the browser need to use WebRTC / WebTorrent, there might be just 0-5 seeders supporting it. I don't see much adoption for WebTorrents before the widely used standard Bittorrent clients support the protocol.
memet_rush
what about having something reasonable for lag, like 30-60 seconds would that make a big difference or you think it would just eventually degrade too? Also do you think there's any way you can prioritize seeders in such a protocol? like some kind of algorithm that the more you share the more you're prioritized in getting the most up to date packets.
The main reason I would think it would be useful is 1. since streaming sites seem to lose a lot of money and 2. sports streams are really bad, even paid ones. I have dazn and two other sports streaming services and they still lag and are only 720p
bawolff
> what about having something reasonable for lag, like 30-60 seconds would that make a big difference or you think it would just eventually degrade too?
I think you would probably need something more in the neighbourhood of 10 minutes to really make a difference. If you could make a stable p2p live streaming app with the number of peers all watching the same stream in the hundreds and only 30 seconds latency, i'd consider that pretty amazing.
> Also do you think there's any way you can prioritize seeders in such a protocol? like some kind of algorithm that the more you share the more you're prioritized in getting the most up to date packets.
If we are talking about a livestream (and not "netflix" type streaming) then i don't think seeders are a thing. You can't seed a file that isn't finished being created yet.
If you mean more generally punishing free-riders, i think that is difficult in a live stream as generally data would be coming in from a different set of peers than the peers you are sending data out to, so its difficult (maybe not impossible) to know who is misbehaving.
pests
Apparently PeerTube can do 10s delay to hundreds (not thousands) of viewers.
dave4420
With sports streams you specifically want low lag, don’t you? It’s no fun being spoilered by people cheering (or not) next door.
memet_rush
i wouldn't mind a minute of lag tbh if the quality and reliability was better. I'm pay $20 a month for dazn and it still lags and buffers lol
BiteCode_dev
stremio works fine and is quite popular.
It's similar to popcorn time that was killed by legal ways so I'd say they did take off.
Stremio smartly avoids being killed by making pirating an optional plugin you have to install from another site so they get deniability.
It works well and save my ass from needing 1000s' of subscriptions.
SchwKatze
I was going to cite stremio too, it's far from perfect but it works fine most of the time.
reliablereason
The only entities that could use such a thing are major streaming platforms, and projects trying to stream copyrighted content without consent.
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.
littlestymaar
I worked for a company called Streamroot which sold exactly this, and I can tell your first paragraph is indeed correct but the second isn't: we had major streaming platforms as customers when I was there (not global giants like Netflix or YouTube, but big european players like Canal+ or Eurosport) and we also had plenty of warez websites (streaming sport, animes, porn, etc.).
I then left and the company later got acquired by Level 3 so I don't know exactly how it evolved but it's likely that they abandoned the illegal streaming market for reputational reasons and stuck with big players.
LeonM
> I then left and the company later got acquired by Level 3 so I don't know exactly how it evolved
It just struck me that there are probably plenty of large media companies that use all sorts of proprietary video streaming products for distribution that we've never heard of, simply because the tech isn't available to consumers.
Media companies are generally pretty secretive about their tech (Netflix being the exception to this rule), so there isn't much to be found about this. The piracy community (because, let's be real here) also won't be interested in a non-free (speech and beer) streaming solutions like these. So that's probably why there is just very little public information available.
But if you use paid digital TV products (Eurosport being a perfect example here) then you are probably already using all sorts of P2P streaming protocols you've never heard of.
aaron695
> degrades their control over the content
Encryption (can work with sharing), signatures, fall back to CDN. Control is not an issue.
> torrents are good enough.
Torrents can't do the massive market of livestream, like sports or season finales or reality TV / news. This is the entire point of the question.
> The only entities
And everyone kicked off of YouTube or doesn't want to use big corporations on principal, like Hacker Cons or the open source community.
notpushkin
> Encryption (can work with sharing), signatures, fall back to CDN. Control is not an issue.
And of course if an encryption key gets leaked, you can just rotate it. Since it’s a stream, past content is not as important.
(That said, I don’t think it will help — any DRM can be cracked, and there’s plenty of online TV streaming sites even with the current centralized systems.)
Calwestjobs
you can stream blockbuster movie which got released yesterday. DRM is important.
Calwestjobs
"Torrents can't do the massive market of livestream" CAN do, why are we not using them is not technical reason, it is that most people just pay apple tv / netflix and not have to install anything on their computer, and UI / interface is 10000 times better.
or very similar point - i had conversation with some big youtuber and person was confused why he is not more popular with certain demographic. reason was that said demographic was watching on big TV and content he was filming was big head directly in front of camera. so they do not like having 3 feet big head right in front of them... most young people watch things on mobile..
notepad0x90
There are streaming sites on the high-seas that use webtorrent. Interestingly (at least for me), this bypasses firewall based IPS/inspection that looks for bittorrent because it's all https. People use it to stream movies at work lol. Good for them I guess.
rklaehn
I am a contributor to Iroh ( https://github.com/n0-computer/iroh ), an open source library for direct QUIC connections between devices that can be behind a NAT.
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.
anacrolix
BitTorrent v2 has the incremental hashes via merkle trees. They're surprisingly good. I implemented them here https://github.com/anacrolix/torrent/issues/175#issuecomment...
wmf
This tech has been developed several times but ultimately CDNs are now so cheap that P2P is pointless. You can't ignore development cost since it dominates all other costs in this case.
globular-toast
If CDNs are so cheap, why is YouTube insistent that they should get paid for their bandwidth? I already pay for my bandwidth and am quite happy to use it for something like YouTube.
The real reason is centralised architecture gives them control and ability to extract rent.
crazygringo
> why is YouTube insistent that they should get paid for their bandwidth?
What are you talking about?
YouTube has a lot more costs than bandwidth. And a lot of ads and Premium revenue goes to creators.
netsharc
AceStream is P2P, its primary use is to stream pirated live sports though. But looking it up, it seems to have been infected by "blockchain!" geniuses.
nisa
It still works without any blockchain and there are dockerfiles and images for using it with CLI only on github. It's closed source through and the UI was a forked version of VLC - it's also been suspected to spread malware - CLI tools look fine through but who knows.
Surprisingly the channels that are available work really well if you just use the mpegts stream.
In a past life I've added a few channels to a tvheadend instance on a VPS. It reliable crashed Kodi watching some channels and I've wondered if it's just broken streams or something more interesting is going on.
If you open the ports and watch popular channels it's easily saturating bandwidth - there is no limit.
I've since stopped using it it's the kind of thing that breaks not often enough to be not useless but often enough to be annoying.
It's IPv4 only and seems to use it's own tracker or at least calls to some URLs for initial peer discovery.
Building something similar as true open source would be great but I guess the usecase is mostly illegal streaming.
Be careful - it's attempting to use upnp to open ports on the router and even if just looking through the lists makes you upload fragments.
Still fascinating tool. It's getting to close to what op is looking for but I think it has scalability issues and everything about it is kind of shady and opaque.
extraduder_ire
One of the main things that hindered acestream is probably it remaining mostly proprietary. There was an explosion of different bittorrent implementations past the first one, which forced everyone to properly standardise.
I was hopeful about bittorrent-live when that was announced, but they didn't open source that for some reason either.
I've been wondering if anyone knows why there is no P2P protocol for mass live stream content in decent quality? specifically what are the technical limitations or is it mostly that people don't want to get destroyed by media company lawyers? I've searched around for a while and i cant find anything like that that can handle thousands of people streaming. The closest is probably Webrtc and that looks like it can only handle 500~ peers.
I was thinking most people nowaday have at least 30mbps upload and a 1080p stream only needs ~10mbps and 720p needs ~5ish. Also i think it wouldnt have to be live, people would definitely not mind some amount of lag. I was thinking the big O for packets propagating out in the network should be Log(N) since if a master is sharing the content then is connected to 10 slaves, then those connected to 10 other slaves and so on.
The other limitation I could think of is prioritizing who gets the packets first since there's a lot of people with 1gbs connections or >10mbps connections. Also deprioritizing leechers to keep it from degrading the stream.
Does anyone have knowledge on why it isn't a thing still though? it's super easy to find streams on websites but they're all 360p or barely load. I saw the original creator of bittorrent was creating something like this over 10 years ago and seems to be a dead project. Also this is ignoring the huge time commitment it would take to program something like this. I want to know if this is technically possible to have streams of lets say 100,000 people and why or why not.
Just some thoughts, thanks in advance!