Re: WebRTC NV Use Cases

Here are my use cases for the next version of WebRTC:

Peer-assisted delivery.
  - See products from companies like PeerCDN (my company, sold to Yahoo),
Peer5, and Streamroot. See open source projects like WebTorrent, PeerTube,
etc.
  - All of these products would benefit from being able to use a
ServiceWorker to intercept HTTP requests and then handle them via a WebRTC
Data Channel instead. Currently, this requires creating the Data Channel in
the main window and shuttling data back-and-forth between the main window
and the ServiceWorker. If we add support for WebRTC Data Channel in Workers
(see https://github.com/w3c/webrtc-pc/issues/230) then these use cases
become a lot easier to support. Less data copying, simpler architecture,
better battery life, etc.

Distributed Hash Tables (DHTs).
  - DHTs are decentralized distributed systems that provide a lookup
service similar to a hash table. DHTs are useful for finding peers without
a central signaling infrastructure, and they're used in almost every
widely-deployed peer-to-peer system, including BitTorrent, Bitcoin, IPFS,
Dat, etc.
  - With the current WebRTC connection model, DHTs are nearly impossible to
build. We need the ability to store the "contact information" for a peer,
close the connection to that peer, and then re-connect to that peer at some
point in the future (if they're still online). With TCP/UDP, this is quite
easy to accomplish. Simply store the ip:port (12.34.56.78:9000) and try to
connect. If the peer is still online, it will just work.
  - Peers need the ability to "listen" for incoming connections. Peers also
need the ability to publish a "reusable SDP" that multiple peers can use to
connect to listening peers (currently an SDP is usable only once)

Lighter-weight connections.
  - It seems that the current WebRTC spec is very complex (or perhaps
currently implementations are still immature). But this leads to a
situation where it's really hard to open more than a dozen connections at
once without the browser process hitting 100% CPU utilization. This
prevents applications that would like to open 20+ connections from doing
so, which makes Data Channels a lot less useful for use cases like
peer-assisted delivery, peer-assisted live streaming, WebTorrent, DHTs,
in-browser cryptocurrency networks, etc.

Feross

I write at feross.org and tweet as @feross <https://twitter.com/feross>.
I work on WebTorrent <https://webtorrent.io/>, Standard
<https://standardjs.com/>, and Study Notes <https://www.apstudynotes.org/>.


On Tue, May 22, 2018 at 12:31 PM Lennart Grahl <lennart.grahl@gmail.com>
wrote:

> As a supplement to the "mandatory permission request" idea:
>
> I think we should try to find a way how to resolve the issue with IPs
> leaking in WebRTC, optimally without impacting the ability to establish
> direct connections. Using mode 3 by default (which Apple's Safari
> already does) would significantly hamper the ability to establish a
> direct connection. Moreover, this would have a significantly negative
> impact on applications where high throughput is required. The permission
> request idea is a cheap way to fix this but probably not optimal either
> because permission requests are always annoying and others have raised
> concerns that the user may not be able to understand the permission
> request.
> However, there may be another solution: Youenn Fablet has added a
> feature to Safari that allows the use of temporary host names created
> and resolved by using mDNS to hide the IPs (see
> https://bugs.webkit.org/show_bug.cgi?id=174500). I think this is a
> clever approach and we should discuss it. Maybe Youenn or other Safari
> folks can also share their experiences with it.
>
> Cheers
> Lennart
>
>
> On 22.05.2018 20:54, Lennart Grahl wrote:
> > [...]
> >
> > ## High Throughput / High Performance
> >
> > [...]
> >
> > Ideas:
> > [...]
> > - API: A mandatory permission request for direct connections (mode 1) as
> > an alternative to gUM. Other non-A/V or A/V receive only use cases would
> > also benefit from that. This would also solve our problems with privacy
> > extensions that hate WebRTC for leaking IPs because we could possibly go
> > restrictive (srflx) by default.
> >
> > [...]
>
>