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 6 minutes ago [-]
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 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.
Protostome 2 hours ago [-]
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 2 hours ago [-]
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.
jack_pp 1 hours ago [-]
what if everyone agrees on a 10s delay?
lordnacho 41 minutes ago [-]
For pseudo-live streams such as sports events, that would be totally fine. People can have slightly out of sync streams, delayed by various amounts.
But you can't live stream a conversation with someone if you have a 10s delay.
bawolff 55 minutes ago [-]
The issue is everyone is watching the same part of the file at the same time. Offsetting by 10 seconds does not change that.
delusional 26 minutes ago [-]
Define "live".
eklavya 2 hours ago [-]
The main difference is liveness of the stream. Live streams are much much more difficult and much less forgiving.
karel-3d 1 hours ago [-]
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 1 hours ago [-]
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.
bawolff 53 minutes ago [-]
If we are talking about a live stream (and not a stream of a static file), having the start be more seeded is useless.
delusional 24 minutes ago [-]
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.
delusional 26 minutes ago [-]
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.
miyuru 2 hours ago [-]
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 2 hours ago [-]
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.
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.
elmerfud 15 hours ago [-]
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.
bayesianbot 2 hours ago [-]
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.
jeroenhd 57 minutes ago [-]
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.
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 2 hours ago [-]
> 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.
dave4420 15 hours ago [-]
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 15 hours ago [-]
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 3 hours ago [-]
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 4 minutes ago [-]
I was going to cite stremio too, it's far from perfect but it works fine most of the time.
notepad0x90 4 hours ago [-]
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.
miohtama 14 hours ago [-]
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).
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 3 hours ago [-]
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 18 minutes ago [-]
> 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 6 hours ago [-]
> 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 3 hours ago [-]
> 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.)
karel-3d 1 hours ago [-]
You need good latency for streaming, torrents can get to a decent speed but the latency will always be bad.
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.
wmf 14 hours ago [-]
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.
rklaehn 56 minutes ago [-]
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.
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.
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.
There's iroh.computer which can use a relay/ do direct nat punching.
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.
Imustaskforhelp 14 hours ago [-]
Shame it's being abused by crypto bros who want to treat it as money.
There are other genuinely useful crypto projects (like Monero for privacy and I don't like the idea of smart contracts)
I really want to tell you the fact that most crypto is scam. These guys first went into crypto and now I am seeing so much crypto + AI.
As someone who genuinely is interested in crypto from a technology (decentralization perspective)
I see transactions as a byproduct not the end result & I see people wanting to earn a quick buck feel really weird.
Also crypto isn't safe. I just think like now its better to correlate as a tech stock though 99% of the time, its run by scams, so absolutely worse.
The technology is still fascinating. But just because the technology is fascinating doesn't mean its valuable. Many people are overselling their stuff.
That being said, I have actually managed to use crypto to create a permanent storage (something like ipfs but its forced to store it forever) , so I think this can be used where anonymity/decentralized is required. But still, this thing could be done without including money in the process as well & crypto is still not as decentralized as one might imagine.
rklaehn 1 hours ago [-]
> Shame it's being abused by crypto bros who want to treat it as money.
Iroh contributor here. I don't know what you are referring to. Iroh is just a library to provide direct QUIC connections between devices, even if they are behind a NAT. We don't have any plans doing a blockchain or an ICO or anything like that.
I am not aware of any project called Iroh that is a scam, but if there is, please provide a link here. It's not us.
I know there have been some scammers trying to make a BLAKE3 coin or something, a year ago.
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 8 hours ago [-]
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.
dcow 4 hours ago [-]
A lot of comments mention it has been a thing in various forms through the internet’s brief history. The interesting question is why didn’t it take off—especially when the technology was there.
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.
alganet 11 hours ago [-]
BitTorrent is already a streamable P2P protocol. You just need a client that can prioritize downloading the file parts in order.
It doesn't work for live streaming without modifications though.
alganet 11 hours ago [-]
Fair enough.
For live streaming there is WebRTC. It is also a thing.
bawolff 30 minutes ago [-]
But its not really p2p in the sense the original poster meant (as in its not an overlay network). Its p2p in the sense that tcp/ip is p2p, not in the sense that bit torrent is.
syndeo 10 hours ago [-]
I believe Popcorn Time worked this way, but I may be wrong. Never dug too deeply into it.
alganet 10 hours ago [-]
It did.
All of it started with the webtorrent project though. One of the first demos was booting Ubuntu while streaming the incomplete live ISO image, quite impressive for the time.
This is great tech for media files. Currently better than any other. But making it would make those media files very easy to redistribute, and it is hard to change that without loosing the P2Pness goodies.
If Popcorn Time had a synchronized multi-resolution catalog, bandwidth-sensitive auto switch and some paid seed servers, it would be better than any other streaming service (technically speaking).
There are streaming platforms built on top of BitTorrent like Streamio with the torrents plugins
gunalx 2 hours ago [-]
You could utilize webtorrents, with a master seed, to in theory get really high scaling of content download, as one would scale peers at the same time of leetchers. Add a cordination server on top to sync timings and you should be there.
johanvts 13 hours ago [-]
Octoshape developed this tech, I believe it was sold to some american tv networks.
Dibby053 9 hours ago [-]
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.
Szpadel 14 hours ago [-]
I would see that easiest way to bring something like that would be some adaptation of m4u format, just instead of URLs to video it could have URL to torrent/magnet.
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
immibis 13 hours ago [-]
I would think that the easiest way would be to not use torrents, because torrents have fixed top-level hashes. Instead, create a new protocol like bittorrent but streaming.
xbmcuser 3 hours ago [-]
I think there is acestream though I don't think it could do 1000s of users. It was my go to for watching live sports back in the day I dont watch sports so no longer kept up with it.
greenavocado 11 hours ago [-]
The only way this will be possible is if there is widespread adoption of an Internet overlay network similar to Tailscale in its design. Fortunately or unfortunately depending on how you look at it Tailscale is limited to Layer 3 so Multicast doesn't work (it depends on IGMP to function correctly).
globular-toast 3 hours ago [-]
Why Tailscale? Are you aware of IPv6?
jeroenhd 40 minutes ago [-]
AFAIK IPv6 multicast across the internet is pretty much dead. ISPs seem to block it because of its DDoS potential. They use it themselves of course (very useful for streaming live TV across their private VLANs) but as an outsider you'll have to convince every ISP and backbone provider to trust your multicast stream, which they probably won't.
Tailscale (or any other P2P overlay network) could solve this problem by re-enabling the multicast support that most ISPs block. It's not a terrible idea.
looks interesting! surprised something like that never caught on. I looking for something like Twitch basically. It has really good quality and is live. But obviously Twitch is just losing money and using all Amazons resources so I wanted to see if there's a more sustainable p2p approach
toast0 13 hours ago [-]
For massive video distribution, getting acquired by a company with "infinite bandwidth" is the sustainable approach.
Orchestrating p2p realtime video distribution is going to have a lot of problems, and spend VC money until someone acquires you is just a lot easier.
Here's a small list of challenges you'd face:
You'll need to have a pretty good distribution network to handle users who just can't manage to p2p connect.
Figuring out the right amount of user's bandwidth you can use without people getting upset; there's a lot of internet accounts with bandwidth quotas, especially for mobile
Trying to arrange so that users connect to users with the least transmission delays would be needed to reduce overall latency. Between cross oceanic connections having unavoidable latency, the potential of buffer bloat, and having a reasonable jitter buffer, pretty soon you have wild delays and potential rebuffering.
Bandwidth constraints / layer switching is going to be a big challenge; it's one thing when your server can just push the best stream the client can manage, but if you're streaming from a peer and the stream is too big, the peer probably doesn't have a smaller stream to switch to and there's no good way to know if where the bandwidth constraint is ... maybe you should switch to the same stream from someone else or maybe you should switch to a smaller stream. Can you get even packets from one peer and odd packets from another ... should you?
I just meant like never caught on as in like it's not super popular, but looks like it's on the come up. would be nice to have a real youtube competitor lol
LargoLasskhyfv 14 hours ago [-]
Yes. It's the typical 'hen & egg' problem. I'm watching there from time to time, and even found some things (independent trance/ambient/goa music) which didn't exist on YT at all! Though the selection is limited, compared to YT or whatever, it's less algorithmic, and because of this you're not forced to use most exaggerated grimacing or clickbaity titles, IF you have no commercial interests and give a shit about ads.
If that's your thing. And you have some sort of presence online elsewhere, then you can link to peertube, no matter which, or selfhosted, without problem.
That's why I pointed you to it. If you need/want the most massive audience, because of platform familarity/network effect, then probably not. At least not now. But someone has to start somehow :)
greenavocado 11 hours ago [-]
I would not be surprised if the rise of CG-NAT put another nail in the proverbial coffin of P2P video streaming and related sharing.
I had a teacher in uni who was fairly convinced that some kind of intelligent multicast was the solution here.
But after working in ISP for a while I realised that the issue is getting ISP's to use cool protocols is just impossible and everything must be built at higher levels.
wmf 14 hours ago [-]
Multicast doesn't work on the Internet.
rapnie 3 hours ago [-]
You might have a look at Librecast [0] which is a R&D project funded by Horizons Europe NGI0 programme via NLnet, aiming to the bring multicast to the current unicast internet and smoothen the transition of projects that adopt it. A great intro to multicast and Librecast is given in Brett Sheffield's 2020 LinuxConfAU talk "Privacy and Decentralization with Multicast" that is available on Peertube [1].
> To enable multicast on the unicast Internet we start by building an encrypted overlay network using point-to-point links between participating nodes. Once established, our overlay network can run whatever protocols we require, unimpeded by routers and middleboxes and which is resistant to interception, interference and netblocks.
The protocol seems like an excellent idea, but #3365a3 on black for the website text is one of the worst designs for open-source project websites I've seen yet.
Off-topic but I'm impressed with how many potentially revolutionary projects get funding from NLNet.
Mbone was fake multicast (today you'd be better off using a CDN) and I don't know if it's still operating.
memet_rush 15 hours ago [-]
i guess but im thinking like multicast with the people sharing like bittorrent, just live. so you'd need to factor in people leaving and people leeching
dp-hackernews 11 hours ago [-]
So a multicast like derivative that is peer aware and can redistribute locally any available parts - which would require some sort of caching, which would probably break copyright etc... So perhaps that's the reason why nothing exists. \o/
oldgregg 13 hours ago [-]
Build it. Use Go. Maybe nknorg/nnet for P2P. Signed HLS segments. Have Go also serve the web front-end with a WASM web worker. Public nodes can run on a very lightweight VPS/server with an autocert domain. Viewers browser join the swarm with WASM-- this way people can just type in a web address so it's very user friendly but the domain doesn't actually have to serve any data. I would just use a trusted pubkey to sign P2P updates so nodes can block naughty IP addresses. Should get you very friendly user experience, easy node deployment, pretty low latency, and bittorrent level of legal resilience.
dackdel 31 minutes ago [-]
soulseek
i5heu 3 hours ago [-]
Peertube does this AFAIk (or they plan to do this)
globular-toast 3 hours ago [-]
It's easier to control people with a centralised architecture.
Nadya 4 hours ago [-]
There are at least two projects like this for watching anime. I won't name them in this forum but they do exist if you look for them.
cess11 2 hours ago [-]
As I understand it, P2P requires information sharing so when your distribution network grows this eventually turns into a performance bottleneck. You'll also need rather sophisticated mitigations against bad actors in the distribution network, like nodes that forward bad packets instead of distributing the good packets they receive and got requests for.
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.
Twitch streamers seem to be fine with the 10-60 second latency Twitch adds, depending on how bad their network is performing. Requirements will differ per industry but I don't think latency is a killer necessarily.
Am4TIfIsER0ppos 12 hours ago [-]
> Also i think it wouldnt have to be live, people would definitely not mind some amount of lag.
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.
aaron695 10 hours ago [-]
[dead]
Rendered at 09:26:52 GMT+0000 (Coordinated Universal Time) with Vercel.
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
> 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 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.
1. locally-randomizing segments download order
2. Create a larger buffer
3. Prioritize parts coming from slower connections
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.
But you can't live stream a conversation with someone if you have a 10s delay.
And the order is requested by the client, and there are clients that go in the sequential order, like Deluge
And, sure, some BT clients can stream the data, but what the default is makes a huge difference.
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.
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.
> Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.
I think its money well spent.
There is a lag between the source and the audience, maybe it's been improved in the last 4 years though, not sure.
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.
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.
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.
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
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.
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.
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
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 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.
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.
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.
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.)
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.
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.
There are other genuinely useful crypto projects (like Monero for privacy and I don't like the idea of smart contracts)
I really want to tell you the fact that most crypto is scam. These guys first went into crypto and now I am seeing so much crypto + AI.
As someone who genuinely is interested in crypto from a technology (decentralization perspective)
I see transactions as a byproduct not the end result & I see people wanting to earn a quick buck feel really weird.
Also crypto isn't safe. I just think like now its better to correlate as a tech stock though 99% of the time, its run by scams, so absolutely worse.
The technology is still fascinating. But just because the technology is fascinating doesn't mean its valuable. Many people are overselling their stuff.
That being said, I have actually managed to use crypto to create a permanent storage (something like ipfs but its forced to store it forever) , so I think this can be used where anonymity/decentralized is required. But still, this thing could be done without including money in the process as well & crypto is still not as decentralized as one might imagine.
Iroh contributor here. I don't know what you are referring to. Iroh is just a library to provide direct QUIC connections between devices, even if they are behind a NAT. We don't have any plans doing a blockchain or an ICO or anything like that.
I am not aware of any project called Iroh that is a scam, but if there is, please provide a link here. It's not us.
I know there have been some scammers trying to make a BLAKE3 coin or something, a year ago.
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.
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.
It is a thing.
For live streaming there is WebRTC. It is also a thing.
All of it started with the webtorrent project though. One of the first demos was booting Ubuntu while streaming the incomplete live ISO image, quite impressive for the time.
This is great tech for media files. Currently better than any other. But making it would make those media files very easy to redistribute, and it is hard to change that without loosing the P2Pness goodies.
If Popcorn Time had a synchronized multi-resolution catalog, bandwidth-sensitive auto switch and some paid seed servers, it would be better than any other streaming service (technically speaking).
https://github.com/johang/vlc-bittorrent/
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 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
Tailscale (or any other P2P overlay network) could solve this problem by re-enabling the multicast support that most ISPs block. It's not a terrible idea.
Edit: a comment elsewhere linked https://www.librecast.net/librecast.html which seems to be doing exactly this.
Orchestrating p2p realtime video distribution is going to have a lot of problems, and spend VC money until someone acquires you is just a lot easier.
Here's a small list of challenges you'd face:
You'll need to have a pretty good distribution network to handle users who just can't manage to p2p connect.
Figuring out the right amount of user's bandwidth you can use without people getting upset; there's a lot of internet accounts with bandwidth quotas, especially for mobile
Trying to arrange so that users connect to users with the least transmission delays would be needed to reduce overall latency. Between cross oceanic connections having unavoidable latency, the potential of buffer bloat, and having a reasonable jitter buffer, pretty soon you have wild delays and potential rebuffering.
Bandwidth constraints / layer switching is going to be a big challenge; it's one thing when your server can just push the best stream the client can manage, but if you're streaming from a peer and the stream is too big, the peer probably doesn't have a smaller stream to switch to and there's no good way to know if where the bandwidth constraint is ... maybe you should switch to the same stream from someone else or maybe you should switch to a smaller stream. Can you get even packets from one peer and odd packets from another ... should you?
Or to get back to your original question: https://docs.joinpeertube.org/use/create-upload-video
edit: Your'e not limited to these addresses, for one there are other instances, for another you can selfhost your own, if your'e into that.
Technically that is one of many possible solutions, 'ready to roll' right now.
addit: Regarding sustainability, and who is behind it, maybe https://framasoft.org/en/ would be of interest?
Linked from there https://framablog.org/2024/12/17/peertube-v7-offer-a-complet...
and
https://framablog.org/2025/04/10/2025-peertube-roadmap/
I just meant like never caught on as in like it's not super popular, but looks like it's on the come up. would be nice to have a real youtube competitor lol
If that's your thing. And you have some sort of presence online elsewhere, then you can link to peertube, no matter which, or selfhosted, without problem.
That's why I pointed you to it. If you need/want the most massive audience, because of platform familarity/network effect, then probably not. At least not now. But someone has to start somehow :)
0. https://ja.wikipedia.org/wiki/PeerCast
But after working in ISP for a while I realised that the issue is getting ISP's to use cool protocols is just impossible and everything must be built at higher levels.
> To enable multicast on the unicast Internet we start by building an encrypted overlay network using point-to-point links between participating nodes. Once established, our overlay network can run whatever protocols we require, unimpeded by routers and middleboxes and which is resistant to interception, interference and netblocks.
[0] https://www.librecast.net/librecast-strategy-2025.html
[1] https://spectra.video/w/9cBGzMceGAjVfw4eFV78D2
Off-topic but I'm impressed with how many potentially revolutionary projects get funding from NLNet.
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.
https://webtorrent.io/
You'd need to make a UI for it
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.