- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 24 Jan 2022 22:08:44 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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. 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. But I think we need PeerConnections in workers to make robust meshes that live in the browser. What have I missed? Harald
Received on Monday, 24 January 2022 21:09:00 UTC