Re: Mesh networks and PeerConnections in Workers - what I heard

> On 8 Feb 2022, at 18:57, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> 
> On Wed, Feb 2, 2022 at 12:18 PM Tim Panton <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> wrote:
> I think the (un?) surprising part of the matrix presentation was the desire to intercept fetch() in order to make it simpler to put existing UX’s onto the new p2p browser mesh. 
> In other words they wanted to be in the service worker so that the (complex) UI page(s) could continue using the same REST API as when it was talking to a server based crypto backend. Their view is that this would greatly speed adoption.  
> 
> This was my read of the presentation as well, which in hindsight doesn't seem a sufficient reason to contemplate exposing RTCPeerConnection in workers. It suggests an application written from scratch wouldn't have this problem. What am I missing?

That the API and the GUI’s already exist for server-based deployments. 
A more extreme example - using the data channel as a secure web-proxy - here the API is effectively fetch() and associated semantics. 
If we get this right _existing_ web pages will work correctly when served over webRTC even from behind NAT.

T