The original poster wonders why there isn't a widely adopted peer-to-peer (P2P) protocol for live streaming similar to how BitTorrent works for file sharing. They envision a system where viewers contribute their bandwidth to distribute the stream, reducing the load on the original broadcaster and potentially improving stability and scalability, especially for events with large audiences. The existing solutions mentioned, like WebRTC, are acknowledged but considered inadequate for various reasons, primarily due to complexity, latency issues, or lack of true decentralization. Essentially, they're asking why the robust distribution model of torrents hasn't been effectively translated to live video.
FilePizza allows for simple, direct file transfers between browsers using WebRTC. It establishes a peer-to-peer connection, eliminating the need for an intermediary server to store the files. The sender generates a unique URL that they share with the recipient. When the recipient opens the URL, a direct connection is established and the file transfer begins. Once the transfer is complete, the connection closes. This allows for fast and secure file sharing, particularly useful for larger files that might be cumbersome to transfer through traditional methods like email or cloud storage.
HN commenters generally praised FilePizza's simplicity and clever use of WebRTC for direct file transfers, avoiding server-side storage. Several appreciated its retro aesthetic and noted its usefulness for quick, informal sharing, particularly when privacy or speed are paramount. Some discussed potential improvements, like indicating transfer progress more clearly and adding features like drag-and-drop. Concerns were raised about potential abuse for sharing illegal content, along with the limitations inherent in browser-based P2P, such as needing both parties online simultaneously. The ephemeral nature of the transfer was both praised for privacy and questioned for practicality in certain scenarios. A few commenters compared it favorably to similar tools like Snapdrop, highlighting its minimalist approach.
During its early beta phase, Spotify reportedly used unlicensed MP3 files sourced from various locations, including The Pirate Bay, according to TorrentFreak. The files were apparently utilized as placeholders while the company secured proper licensing agreements with rights holders. This practice allegedly allowed Spotify to quickly build a vast music library for testing and development purposes before its official launch. While the company later replaced these files with licensed versions, the revelation sheds light on the challenges faced by nascent streaming services in navigating complex copyright issues.
Hacker News users discuss the implications of Spotify using pirated MP3s during its beta phase. Some commenters downplay the issue, suggesting it was a pragmatic approach in a pre-streaming era, using readily available files for testing functionality, and likely involving low-quality, variable bitrate MP3s unsuitable for a final product. Others express skepticism that Spotify didn't know the files' source, highlighting the easily identifiable metadata associated with Pirate Bay releases. Several users question the legal ramifications, particularly if Spotify benefited commercially from using these pirated files, even temporarily. The possibility of embedded metadata revealing the piracy is also raised, leading to discussions about user privacy implications. A few commenters point out that the article doesn't accuse Spotify of serving pirated content to users, focusing instead on their internal testing.
Summary of Comments ( 165 )
https://news.ycombinator.com/item?id=43684286
HN users discussed the challenges of real-time P2P streaming, citing issues with latency, the complexity of coordinating a swarm for live content, and the difficulty of achieving stable, high-quality streams compared to client-server models. Some pointed to existing projects like WebTorrent and Livepeer as partial solutions, though limitations around scalability and adoption were noted. The inherent trade-offs between latency, quality, and decentralization were a recurring theme, with several suggesting that the benefits of P2P might not outweigh the complexities for many streaming use cases. The lack of a widely adopted P2P streaming protocol seems to stem from these technical hurdles and the relative ease and effectiveness of centralized alternatives. Several commenters also highlighted the potential legal implications surrounding copyrighted material often associated with streaming.
The Hacker News post "Ask HN: Why is there no P2P streaming protocol like BitTorrent?" generated a robust discussion with a variety of perspectives on the challenges and existing solutions for P2P streaming.
Several commenters pointed out that P2P streaming protocols do exist, albeit with limitations that prevent widespread adoption. Examples cited include WebTorrent, Livepeer, and Tribler. Some argued that the question's premise was flawed, highlighting the existence of these protocols, while others elaborated on why these existing solutions haven't achieved mainstream success.
A recurring theme in the comments was the inherent difficulty of real-time streaming via P2P. Commenters explained that the strict timing requirements of streaming content differ significantly from downloading files, where order and completion are paramount, but timing is less critical. The unpredictable nature of P2P networks, with peers joining and leaving intermittently, makes it challenging to guarantee smooth, uninterrupted playback. Issues like latency, buffering, and ensuring data arrives in the correct sequence were frequently mentioned as obstacles.
Several technical challenges were discussed in detail. These included:
Some commenters suggested that centralized Content Delivery Networks (CDNs) offer a more reliable and efficient solution for streaming, at least for now. The infrastructure and optimization provided by CDNs address many of the challenges inherent in P2P streaming.
While acknowledging the difficulties, some expressed optimism about the future of P2P streaming. They pointed to advancements in technologies like WebRTC and distributed hash tables (DHTs) as potential solutions to some of the existing challenges. The potential for reduced infrastructure costs and increased resilience against censorship were cited as key motivators for continued development in this area.
One compelling comment thread delved into the complexities of live streaming versus on-demand streaming in a P2P context. Live streaming poses greater challenges due to the real-time nature of the content and the need for low latency. On-demand content, in contrast, allows for more flexibility in piece acquisition and can tolerate higher latency.
Another interesting discussion focused on the potential of blockchain technology to incentivize participation in P2P streaming networks. By rewarding seeders with cryptocurrency, it might be possible to create a more robust and sustainable ecosystem.
In summary, the comments offered a nuanced perspective on the state of P2P streaming. While acknowledging the existence of such protocols, they highlighted the significant technical hurdles that have prevented widespread adoption. The discussion covered various aspects, from the challenges of real-time data delivery to the potential of emerging technologies like WebRTC and blockchain. The overall sentiment reflected a cautious optimism, acknowledging the difficulties while recognizing the potential benefits of a decentralized streaming future.