Reactive P2P architecture with hypercore

[santakadev]

Current architecture:

All write operations are performed by the peer initiating the session:

• Single write database owned by session intiator.
• Previous database is replicated to the rest of peers for reading.

We have some features that need all peers to be able to perform write operation like:

• set its display name
• set the position of its cursor
• enable/disable peer audio
• take edit control

Proposed architecture/solution:

Allow write operation to all peers:

• Each peer has its own writable hypercore DB.
• All write operations of a peer are stored in its own DB
• When a connection to a peer is established via WebRTC, we perform DB replications:
  • we replicate our database to the connecting peer
  • connecting peer replicates its database to us

In summary, each peer has a write hypercore DB and a read hypercore DB for each connected peer.

In this architecture, when a peer performs an action that wants to publish (for example: CHANGE_DISPLAY_NAME action), he/she simply store the action in its own DB. This action will be recieved by all peers by replication, and they will react to this action.

After a lot of try, error and documentation, I have a working prototype of this architecture that uses WebRTC datachannel, that we can translate to P2P Editor.

This architecture can be plugged easily with Redux and any frontend framework like React and Vue.

Other options that I have try without success:

• Use signalhub for nickname, cursor, etc. communication: discarted because is a non P2P solution
• Use SimplePeer to send raw data (peer.send()) in the same DataChannel: discarted conflicts with hypercore replication
• Create new DataChannel in SimplePeer to send raw data -> multiplexing already not available.

[JavierCane]

Good work Mr. @santakadev !

At least seems something worth it to try 🙂

I've some concerns about possible concurrency issues. I mean, if the peers doesn't share the very same source of truth, what would happen when there're race conditions situations like the following one:

• Peers A and B have the same DB state 1 (character . on screen let say)
• Peer A modifies the DB state to 1.A (delete character, resulting on an empty screen)
• Peer B modifies the DB state to 1.B (add character -, resulting on .-)
• Peer A receives the 1.B state afterwards, so it would have - on screen)
• Peer B receives the 1.A state modification, so it applies the change and end up having . again on screen because applying a delete operation could only remove the last character, and it previously had .-.

I don't know if my assumptions are correct, so please question them because I could be missing a lot of considerations, and correct me where I'm wrong 👼

[santakadev]

Good point @JavierCane

I had made a little research about this concurrency problem when we start this project.

There are some interesting papers that try to solve this problem. Here are some examples:

• Data consistency for collaborative P2P editing
• Logoot-Undo: Distributed Collaborative Editing System on P2P networks

The problem is complex, and I think that for now we can avoid these race conditions that leads to inconsistent data, don't allowing collaborative editing (only session owner can write to the file)

We can create new issues for solving these problems:

• Collaborative editing.
• Consensus for determine who has the control for writing.

[JavierCane]

Ok. I agree with going ahead for this approach for now in order to unlock the Milestone 1.1 features, and we'll revisit it once we plan to add multiple users editing functionalities.

🤟

[santakadev]

fixed in #40