Closed ahdinosaur closed 5 years ago
Here's something that could work: 2 gossip networks. The first gossip network uses websockets and has a few high-uptime nodes to bootstrap the network, but with initial connections all based on bootstrap lists. The first network will provide basic address and subnet tables. One of these subnets can be used to store webrtc signal messages.
Browsers will connect to the webrtc subnet and attempt to connect to N peers over webrtc. The webrtc gossip network will function the same way as the websocket network with application-specific subnets.
Everyone who wants to rx or tx a feed will join the subnet for that public key (or the subnet named by the hash of a public key with a salt). The peers in the subnet can announce the latest HEAD of the feed they have and their neighbors can send updates accordingly until everyone in the subnet has the latest version.
moose-team/friends uses signalhub, which is just an http server right now but could be made to serve as the first gossip network with some work. signalhub is more than adequate right now because ssb doesn't have huge scaling problems yet. It will be nice to have something that is fully p2p, even at the server level, but with a 2-tier network the client routing can at least be fully distributed.
I think at least with webrtc storing signal messages would not work, since you have to create new signal messages everytime you want to peer with another peer (new port every time, cant reuse).
I commented a bit about this here: it would be great if this would work client-side only where only static files would need to be hosted. That would allow this code to be added to cheap WiFi routers so that users could just open a page there and connect with others. This is useful for community wireless networks/mesh networks. A good thing is that in such networks you often do not have NATs but only end-to-end connectivity, so WebRTC could work pretty well.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
as i understand, peers currently poll pub servers in order to send or receive new messages. this works well, but leads to a slower propagation of messages than if peers were able to directly notify each other with any new messages. it's been mentioned before that we should use pub servers as introducers for direct WebRTC data channels between peers. this way we can support the low latency real-time communication necessary for an interface comparable to Slack or moose-team/friends. i couldn't find an issue for this, so here's one.