Live data from Hacker News

WebTorrent

webtorrent.io

31–40 of 149 posts

Re: WebTorrent

#31
I'm building a decentralized ai marketplace and guess what? This piece of software is the backbone of our off-chain file transfer protocol. It just works; however, its seeder (BitTorrent-tracker) depends on node-webrtc, and it is not an official node package for web-rtc. It has some weird issues. For example, when you seed the torrent through BitTorrent-tracker, and on the client side (chrome browser), I used chrome://webrtc-internals to debug rtc connections. First time in my life, I coined the term connection leakage. A bug in the WebRTC handshake leads to too many connections (300+) for even 1kb torrents.

I hope it gets solved very soon.

I also attach my node profiling output. Looking for some advise if you have any..

[C++]:

   ticks  total  nonlib   name

   5511   16.9%   43.2%  epoll_pwait

    692    2.1%    5.4%  __pthread_cond_timedwait

    682    2.1%    5.3%  __lll_lock_wait

    413    1.3%    3.2%  __GI___pthread_mutex_lock

    338    1.0%    2.6%  __GI___pthread_mutex_unlock

    128    0.4%    1.0%  __write

     84    0.3%    0.7%  __pthread_cond_broadcast

     83    0.3%    0.6%  __lll_unlock_wake

     62    0.2%    0.5%  __mprotect
[Summary]:

   ticks  total  nonlib   name

    153    0.5%    1.2%  JavaScript

   8206   25.2%   64.3%  C++

    116    0.4%    0.9%  GC

  19811   60.8%          Shared libraries

   4411   13.5%          Unaccounted
[C++ entry points]:

   ticks    cpp   total   name

    692   27.3%    2.1%  __pthread_cond_timedwait

    679   26.8%    2.1%  __lll_lock_wait

    413   16.3%    1.3%  __GI___pthread_mutex_lock

    337   13.3%    1.0%  __GI___pthread_mutex_unlock

    100    3.9%    0.3%  __write

     84    3.3%    0.3%  __pthread_cond_broadcast

     82    3.2%    0.3%  __lll_unlock_wake

     52    2.1%    0.2%  __mprotect

Re: WebTorrent

#32

I've always been very, very nervous about the privacy implications of this technology. Creating a persistent, public record of every IP that has ever accessed a particular video is a HUGE step backwards compared to current video/file distribution systems, and I don't think end-users correctly appreciate the trade-offs yet of making that sort of information public and joinable across domains / different activity (i.e.…

I think the good ol’ saying applies here as well that security through obscurity is not secure. Here like in other aspects it is best to secure users in such a way that if a christian school does a search like that and punishes students based on what they do in their free time (or worse their gender perception or sexual orientation) then there should be an easy course of action through the legal system for the student to get justice (and for the school admins to be punished).

Re: WebTorrent

#33
post #31

I'm building a decentralized ai marketplace and guess what? This piece of software is the backbone of our off-chain file transfer protocol. It just works; however, its seeder (BitTorrent-tracker) depends on node-webrtc, and it is not an official node package for web-rtc. It has some weird issues. For example, when you seed the torrent through BitTorrent-tracker, and on the client side (chrome browser), I used chrome:…

Perhaps node-datachannel could be a viable alternative? https://github.com/murat-dogan/node-datachannel

Re: WebTorrent

#34

P2P connections over the web are usually not possible due to typical consumer router configurations and bad decisions in the design of WebRTC protocol. The vast majority of these P2P web projects, including WebTorrent, is actually using proxy servers to fake the illusion of P2P connectivity (to be specific, they are using TURN servers to proxy traffic). Here's a stackoverflow question I asked about this and burned a…

This isn't true. In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being-... Reading your stackoverflow link my guess is that you aren't using STUN. A P2P connection can't be established without a NAT hole punch. Also if possible I would avoid the terms `Full-cone NAT` and `Symmetric NAT` they don't do a good job of describing what i…

> In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being-...

Thank you for this. I guess P2P connectivity is more often possible than I thought! For the record, I have tried to form P2P connections with multiple different devices and multiple different network conditions, and although I have been able to achieve connectivity with Python, I have not been able to achieve connectivity with WebRTC. So I have reason to be suspicious about claims regarding web P2P connectivity.

> Reading your stackoverflow link my guess is that you aren't using STUN. A P2P connection can't be established without a NAT hole punch.

I described NAT hole punching in my stackoverflow question, where I asked why isn't WebRTC doing this? I was using a STUN server (edit: I mixed up TURN and STUN servers and edited this post to fix that. My stackoverflow question has clear references to how I was trying to achieve connectivity - it has been a while so not everything is in clear memory for me.)

Re: WebTorrent

#35
WebTorrent is obviously well suited for p2p file distribution, but using a minimal subset of the protocol also provides a nice hack for easily bootstrapping peer connections between web app users. Piggybacking on public mediums already designed to do peer exchange can let you rapidly prototype a WebRTC project without the hassle of running your own server anywhere.

I built a library that explores this idea: https://github.com/dmotz/trystero

And here's how it talks to WebTorrent servers to bootstrap peer connections: https://github.com/dmotz/trystero/blob/main/src/torrent.js

It also allows encrypting your peers' session descriptions to hide them from the torrent server. All of this is of course experimental and I'm very open to feedback.

Re: WebTorrent

#36
post #12
post #5

Besides being an amazing technical achievement, I find this very interesting legally, as it further blurs the line between passively viewing content hosted somewhere and redistributing/actively sharing content. Have there already been cases of websites making their visitors unwitting peers, similar to e.g. JavaScript cryptocurrency mining?

Well spotted. In other words, WebRTC lets a site owner have their visitors distribute content directly to others without their knowledge or consent, basically making it impossible to argue that the distributor has intent to do so in the general case. That said, it was already highly questionable for legal application, since a torrent client can run on any machine connected to a home wifi, including guests and comprom…

I totally agree, that's how it should be. In reality right now there are countries in which you get cease and desist letters and a ~800 Euro fine for even a short amount of seeding. This is a cool technology but also allows more automation in this shady industry and laws will take years and years to follow up.

Re: WebTorrent

#37
post #5

Besides being an amazing technical achievement, I find this very interesting legally, as it further blurs the line between passively viewing content hosted somewhere and redistributing/actively sharing content. Have there already been cases of websites making their visitors unwitting peers, similar to e.g. JavaScript cryptocurrency mining?

I am on a 200GB capped residential LTE internet connection. Upload is included in that data cap. If this was surreptitiously deployed that would cost me money and generally be not cool.

Thankfully internet innovation doesn’t stop because a few people have terrible internet service providers.

Re: WebTorrent

#38

Imagine visiting a website and the ads are sent to you via webtorrent and your browser diligently reshares it. Not only do you suffer the ads, you unwittingly contribute your resources (power and bandwidth) to propagating them

That is a great example of how all technological developments have an equal and opposite negative side.

Re: WebTorrent

#40

Earlier quoted context omitted.

This isn't true. In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being-... Reading your stackoverflow link my guess is that you aren't using STUN. A P2P connection can't be established without a NAT hole punch. Also if possible I would avoid the terms `Full-cone NAT` and `Symmetric NAT` they don't do a good job of describing what i…

> In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being- ... Thank you for this. I guess P2P connectivity is more often possible than I thought! For the record, I have tried to form P2P connections with multiple different devices and multiple different network conditions, and although I have been able to achieve connectivity with P…

STUN servers are only required for NAT punching, they don’t relay traffic. Only TURN servers are used as relays in the event that a direction connection can’t be established.
Post reply on HN