add data-structure and sync proposal

Author: nikgraf

docs/data-structure-and-sync.md

@@ -0,0 +1,77 @@
+# Data structure & Sync
+
+## Data per Space
+
+Each space has multiple `Nodes`. Each `Node` can either be an `Entity` or a `Triple` in indicating a relationship between two `Entities`.
+
+## Proposal
+
+Each `Node` is a small CRDT document by itself and the content of the node is derived from the Yjs document.
+
+This would allow to setup an event log per space. There can be 3 kinds of operations:
+
+- set
+- delete
+
+### Operations
+
+#### Set
+
+```json
+{
+  "spaceId": "abc",
+  "nodeId": "xyz",
+  "type": "set",
+  "content": "base64 encoded yjs update"
+}
+```
+
+#### Delete
+
+```json
+{
+  "spaceId": "abc",
+  "nodeId": "xyz",
+  "type": "delete"
+}
+```
+
+### Rules
+
+- `delete` always wins over `set`
+- `set` updates must contain a commutative operation (CRDT update)
+
+Therefor no conflicts can occur.
+
+### Syncing
+
+With a single sync server we could rely on an ordered event log per space managed by the server.
+
+To make sure we can sync even when switching sync server we should create a structure that allows to sync in a decentralized fashion. Merkel-search-trees seem to be a good fit for this.
+
+#### Merkel-search-trees
+
+- https://inria.hal.science/hal-02303490/document
+- https://github.com/domodwyer/merkle-search-tree
+
+#### End-to-End Encryption
+
+The actual content should be encrypted. Therefor we want a structure like this:
+
+```json
+{
+  "spaceId": "abc",
+  "nodeId": "xyz",
+  "ciphertext": "base64", // contains the type and content in case it's a `set`
+  "nonce": "base64",
+  "commitment": "base64", // needed?
+  "signature": "base64"
+}
+```
+
+For the Merke-search-tree we probably would use the hash of the whole structure above.
+
+### Downsides
+
+- Currently doesn't support any kind of access control inside a space
+- Doesn't allow to sync only a part of a space