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

Maybe take a look at : https://www.peersm.com/Convergence.pdf - 2015
proposal modified by http://www.peersm.com/Convergence-2020.pdf

You can notice that the latest proposal does not intend to specify the
peer discovery system (and bootstrapping, most likely bootstrap process
is using WS and later on peers can discover them via others)

I have not worked on this since some time but there were some
discussions on W3C lists some years ago with myself, still don't get why
ws (against wss) inside https is forbidden, and as far as I remember
Service Workers was the right solution for me for permanent/resilient
nodes inside browsers, but with some limitations

Sorry for the approximation, again not concentrating on this since some
time, maybe look at past discussions, for Convergence the plan right now
is just a webapp inside a web page


Le 24/01/2022 à 22:55, Youenn Fablet a écrit :
>
>
>> On 24 Jan 2022, at 22:08, Harald Alvestrand <harald@alvestrand.no
>> <mailto: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), plus
> merge https://github.com/w3c/mediacapture-extensions/pull/26.
>
>
>> What have I missed?
>>
>> Harald
>>
>>
>>
>

-- 
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com