Re: WebRTC NV Use Cases

+1 for data channel in service worker.
It would also be interesting in a world where we would use the QUIC API on the web page server QUIC connection.


> On May 22, 2018, at 5:17 PM, Feross Aboukhadijeh <feross@feross.org> wrote:
> 
> 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 <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 <http://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 <https://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 <mailto: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 <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.
> > 
> > [...]
>