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

> On 24 Jan 2022, at 22:08, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> Forgive the ruminations, but after listening to the Matrix presentations last week, I feel the need to expand on some of my contemplations of the issue.
> 
> To me, mesh networks running in browsers have two important properties:
> 
> - They have to be booted from somewhere (a Web page and some initial connection to the Mesh)
> 
> - They have to remember where the other peers it makes sense to talk to are
> 
> Ideally, we'd like to have the required "booting" part be as small as possible. Discussions about using (for instance) mDNS names for discovering resources to connect to have been had before; I won't revisit these now.
> 
> The "memory" part is more interesting.
> 
> Once the node is connected to the mesh, there's a large amount of state to be kept - especially about neighbours and routing, where it makes sense to forward messages and so on. This is learned via communication with the network of peers.
> 
> If one Web context does all the messaging, it's easy - just keep it in the page. Perhaps store some of it in local storage for quick recovery.
> 
> But if multiple Web contexts (multiple tabs, multiple apps) are starting to use the same web, this does not make sense any more. Each tab shouldn't need to be its own node. And those tabs might sometimes share the same origin - but sometimes they might not. And they will be closed, more or less at random, when the user decides to close them.
> 
> This seems to qualify for workers.
> 
> Dedicated workers helps a bit, in keeping logic out of the page. But being bound to a single tab, they don't share.
> 
> Shared workers help a bit more, as long as all tabs have the same origin. (Is this correct?)

Shared Workers should be/are partitioned by origin.
MessagePort can be used for cross origin communications.

> 
> Service workers, objects that live longer and can be shared between multiple orgins, may be the best answer.

Service Workers should be/are partitioned by origin, like SharedWorker, for the same privacy & security reasons.
Service Workers help when the last page that has a SharedWorker navigates away to a new page that would use the same SharedWorker scope.
In that case, the solution is for the service worker handling the navigation to have its own SharedWorker instance so that the SharedWorker scope continues throughout the navigation (worth testing though).
I do not expect service worker benefits compared to shared workers in the mesh scenario.
Shared workers have lifetime predictability benefits compared to service workers that make them more suitable for RTCPeerConnection long living networking.

> 
> But in all those cases, we need the memory, the connection state, and therefore the peerconnections themselves, to live in workers.
> 
> I don't see a need to transfer a PeerConnection. I dont' even see a great need (in this scenario) to transfer DataChannels - message ports send messages too, and we need to send messages anyway.

DataChannel can be shimed using postMessage, like WHATWG Streams or MediaStreamTracks (with MediaCapture transform).
In these cases, transferring makes life easier for web developers and allows optimizations for engine developers.
As an example, transferring a data channel between two contexts living in the same process can be implemented with zero processing cost (past the initial postMessage/transferring steps themselves).

> 
> But I think we need PeerConnections in workers to make robust meshes that live in the browser.

I would not say it is strictly needed, but it certainly helps in optimising meshes in browsers.
In any case, similarly to other networking technologies like WebSocket or fetch, it should be made available to workers. 

At this point, given we have identified a few usecases, I think we should look for implementors interest.
Then propose a PR to expose WebRTC constructs to workers in webrtc-extensions (existing issue at https://github.com/w3c/webrtc-extensions/issues/77 <https://github.com/w3c/webrtc-extensions/issues/77>), plus merge https://github.com/w3c/mediacapture-extensions/pull/26 <https://github.com/w3c/mediacapture-extensions/pull/26>.


> What have I missed?
> 
> Harald
> 
> 
>