Re: WebRTC NV Use Cases

I just want to second everything that @feross just said. The browser needs
a way to:
  - persist peer connections and
  - periodically ping them to maintain an up-to-date list of peers.

If it worked in Service Workers, then it would work similarly to Web Push
Event API – a quick blast of data from a peer, maybe to notify that there
is new content, and it could decide whether to establish a full connection
and download that content now, or simply acknowledge the message, or 
present a Push Notification to the user.

William Hilton
@wmhilton on github and twitter
Author of Isomorphic-Git

> 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/>.

Sent from Mail for Windows 10