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

> On 24 Jan 2022, at 21: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?)
> 
> Service workers, objects that live longer and can be shared between multiple orgins, may be the best answer.

I think there are 2 sorts of state here, long term state (e.g. remote identities, conversation names/content etc) and short term state (who has received which message, current key ratchet etc) - there is a huge benefit of putting the short term state into a shared worker (provided it is valid for all the consumers). The long term state probably has to be in indexDB. 

Then of course there are the peer connections themselves, which are an expensive form of state!

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

Since we can’t intercept web sockets in service workers, the nearest equivalent is to open a data channel  and transfer that back in place of a web socket (The APIs are similar enough that the app can’t tell). This trick won’t work with message ports. 

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

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.  

We’ve done experiments where we serve pages by intercepting fetch in a service worker and getting the content over a peer connection, the pages don’t know or care that this is happening.

Tim.

> 
> Harald
> 
> 
>

Received on Wednesday, 2 February 2022 17:17:50 UTC