search

mafintosh / todo

I add my TODOs as issues in this repository.
3 stars 0 forks source link

Gossip based webrtc signalling over streams #1

Open mafintosh opened 8 years ago

mafintosh commented 8 years ago

The new hypercore extension api would be great for this

hackergrrl commented 8 years ago

Could you say more about your thoughts on this? Very interested.

mafintosh commented 8 years ago

yes. basically lets say you have the following topology

   a
  / \
 b   c
      \
       d
  1. peer c wants to connect to more peers so it sends a message to a with a digest of the peers it's connected to (minus a since that's trivial). the digest is (d).
  2. since peer a has a peer (b) that is not in that digest it sends a message to both c and b that they should forward signalling data (it picks a random one as the initiator).
  3. this allows b and c to connect directly to each other using a as a signalling server
mafintosh commented 8 years ago

then later one c ask b for the same thing etc to form a more connected topology

hackergrrl commented 8 years ago

This seems really powerful: peers build routing tables to each over time via gossip, and volunteer themselves as relays for signalling data. It could even be agnostic to topology -- peers could share gossip selectively to encourage the formation of topologies that the network prefers. I'm not familiar with hypercore, but this seems like a powerful enough module to be standalone.

I had been thinking along similar lines recently: about a flooding-based approach to add to webrtc-swarm, where a fresh node could flood an introduction signal message to the network (with some TTL), gather signal responses from interested parties, and then connect to whoever seemed the most appealing (with the goal of getting a uniform distro of peer distances, probably). Flooding probably won't scale, but it means only one round-trip to get the signal data exchange done. Periodic gossip seems much better for long term network health though.

cc @diasdavid, who is very well versed on this subject.

mafintosh commented 8 years ago

yup i'm gonna make this into a separate module. my main application for this was to use it in hypercore (a simple distributed append-only log network)

does webrtc support flooding the same signalling data to multiple peers?

hackergrrl commented 8 years ago

If only. Each invitation can only be accepted once, it seems. So a node would need to flood N times for N new peers. On Mar 4, 2016 9:50 PM, "Mathias Buus" notifications@github.com wrote:

yup i'm gonna make this into a separate module. my main application for this was to use it in hypercore (a simple distributed append-only log network)

does webrtc support flooding the same signalling data to multiple peers?

— Reply to this email directly or view it on GitHub https://github.com/mafintosh/todo/issues/1#issuecomment-192584472.

lmatteis commented 8 years ago

The only real problem with this is churn: when users go offline and then go back online they need to restart from bootstrap servers (using IP addresses/DNS names). They can't restart via previously discovered webrtc tabs, because they need to be reintroduced and redo the handshaking.