Show HN: A JavaScript SDK to reduce video streaming costs
api.peervadoo.com
api.peervadoo.com
Have spent only a couple of minutes looking at it but it works by connecting to a websocket server where everyone who watches the video announces themselves, when 2 people are watching the same video a WebRTC data channel is opened for streaming video content.
Have you guys considered the security aspect of such a service? Specially a data channel open between 2 anonymous party is a very nice attack vector imo.
Is this enabled by default in modern browsers?
Datachannels by themselves are secure since all videoconferencing software use the same technology to connect users and there are no visible security concerns.
Also we make sure the data being transferred is not malicious by having checks for data consistency
Video conferencing is multicast, video streaming is broadcast. I can essentially opt in to opening a data channel to a peer because its core to the technology and feature set. I don't expect opening a link to a video exposes me to another random person or computer watching the same video.
Another fundamental difference is that video conferences are temporary. Hosted videos are persistent. I can just have a machine hang out watching a video on loop and sniff peers coming in, quite reliably if the video is popular.
Another point I'd bring up is that video conferencing apps' threat model is essentially around unauthorized access. It's dealt with by obscuring the video stream's link, making it temporary, and securing it behind an authorization protocol (on Zoom you have login, password, and manual admitting by the host, for example). That doesn't really fit if you're hosting videos to be persistent.
My second point w.r.t comparison is regarding the security of data channels of webrtc which is a pretty secure channel which is used in video conferencing as well but there is no known security loopholes in that and thus no concern
Some day webtorrent itself would be capable of streaming large files [4]. And of course, there's peertube [5].
[0] https://gigaom.com/2013/03/28/peercdn-p2p-cdn/
[1] https://www.ycombinator.com/companies/1559
[2] https://p2p.cdnbye.com/en/
Interestingly, your GitHub table on compatibility matches exactly with theirs. I guess both of you are hitting into the same limitations.
As an admin, if anyone in my wifi opens a page using this technology, their increased upload traffic will slow down or potentially even block more important things like off-site backups.
That's why companies and universities tend to block p2p "CDN"s. Or at the very least, they heavily throttle it, which means your watching experience suffers.
However, I believe GP was referring to companies blocking such CDNs on their internal networks (used by their employees). That corroborates my experience and that of my colleagues (healthcare, education, defense).
They were quickly blocked for using P2P in pretty much every company firewall. I remember sending a funny video link around, but nobody could watch it in their lunch break. Also, so many regular users reported their "Giraffic Video Accelerator" for suspicious behavior (high CPU usage, high network usage) that antivirus companies started flagging it as a Trojan.
Then, Veoh went bankrupt. And eventually, they were acquired.
Similarly for people accessing content from remote locations always face a lot of issues since the cdn centers stay away in metro cities. Their experience would be enhanced too since they can now fetch the content from a nearby peer than a far-away cdn
Users who wish to be part of the network for better experience streaming the content can be part of the network. Also there are options available to enable/disable p2p for 4g/wifi/based on location and various other constraints to take care of user experience.
This is an interesting idea. If this gets widespread-enough adoption, and if non-metro folks can, on average, find a nearby peer for $whatever they're looking for (and those are very big "if"s), I still imagine some problems might crop up:
Determining "distance" is quite tricky, and the trickiness goes up substantially the further onto rural/less normal latency distribution networks/ISPs you get--and that's just in the first world. If latency is the main signal used to inform distance, you could end up inflicting a pretty punishing upload-bandwidth cost on users/ISPs because of, for example, a fortuitous peering agreement upstream.
There may also be a significant penalty paid for "medium distance" non-hub-routed peers: situations in which the presence of many uploaders congest the last-mile/backhaul infrastructure of small-scale providers that are least capable of managing the unexpected surge in consumption (least capable as in: most congestion-prone infrastructure and fewest technical solutions on hand to mitigate unexpected long-term congestion).
And in places where small-scale providers don't control much of the market and mobile networks are the main bandwidth providers, expect a swift no-warning traffic block. There are ways to circumvent those, but they get expensive (in engineering time, user experience, and user bandwidth) fast.
And it is a swarm based network which by default will never overload a single peer and shares the bandwidth across all the peers in general
As a user, battery life and bandwidth limits are super important to me, and this seems like a thing that will eat through both.
With regards to bandwidth there are options to limit upload and disable it for 4g/for certain location
The title here mentions reducing costs by 90%, but on the homepage you list reducing cost by 50% (twice), reducing bandwidth by 99%, and offloading 90% of bandwidth. On the github page it lists reducing costs by 30%
From a first-read perspective those are vastly different numbers (30-99%), for what all sound like the same thing (reducing bandwidth by 99% sounds like it should reduce my costs by 99%).
Might want to be more specific (or pick a single number).
As more users watch a single stream concurrently the savings increase proportionately. We have seen max bandwidth savings of up-to 90% in live streaming scenario with 100 users concurrently watching the stream.
I am working on a web sdk which can reduce video streaming costs of CDN by up-to 90% using a hybrid decentralized load sharing technology. I have opened it up for beta-access for developers to try it out. Looking for feedback w.r.t the technology and any features you would want to have.
A web demo is available here https://api.peervadoo.com/test . Click on Add new peer to see the tech in action
Sdk link :- https://github.com/vadootvpeer/sdk-javascript
Happy to answer any queries
If I've found out some website is using my upload bandwidth without my consent I would just quit using it.
It's a dick move to utilize user's resources.
In addition, there are many countries (like India for example) where wired internet is not the norm and instead 3G/4G/LTE sticks or hotspots are.
Not to mention data caps are a thing on wired internet anyway, like Comcast in US.
Are you using WebRTC with a torrent like network (ex:Filecoin)? I can imagine people renting a percentage of their existing home servers.
It's be nice if webrtc was somewhat more opt in.
Many people including me have just stopped watching Twitch because of the new ads, but I'd love to help build a movement towards a no-advertising-ever streaming site.
If we can bring the cost of streaming the video content down I think it's doable.
You could suggest that by removing ads, they'll get more of other revenue streams, but that doesn't seem to be the case with Twitch, people chuck money at streamers anyway. So there is no real incentive for creators to move, or even be worried about these changes by Twitch.
That's putting aside the huge community inertia that Twitch has. Neither Microsoft nor Google nor Facebook have neen able to make headway with their game streaming services.
Adopting any new technology takes time and effort, which translates to invested money that need to make sense in the long run.