Layers Definition

[echarles]

We have following non coherent 2 definitions for the layers. Are we talking about the same concept? If yes, we should align them, or better define them at a single place

# On https://jupyter-rtc.readthedocs.io/en/latest/developer/design.html
- Base: CRDT implementation, lumino and/or other JS implementations
- Middle: Friendly real time datastore using this with React integration
- Higher level/Jupyter: Support for editing all data in Jupyter server
- Jupyter clients: JupyterLab integration, Spyder integration, nteract integration (examples)

# On https://jupyter-rtc.readthedocs.io/en/latest/developer/spec.html
- Jupyter RTC: Specification of the schemas that correspond to the entities in the Jupyter Server and a specification of how the supernode interacts with these records. There are other protocols at this level as well, for things like chat, commenting, - Jupyter Widgets and other extensions.
- RTC: Specification of how to represent schemas and how updates to the data in those schemas can be serialized as transactions.
- Synchronized Append-only Log: Provides a way to share between all clients a shared append only log of transactions.
- Bidirectional Asynchronous Communication: Allows clients to send and recieve messages to one another.

[echarles]

Y.js does not really define layers, but they are architectured in three parts:

1. Y-Bindings: For now to editors (y-prosemirror, y-quill, y-codemirror, y-monaco).
2. Y.js it self responsible for CRDT data structures.
3. Y-Providers: Setting up the communication between clients, managing awareness information, and storing shared data for offline (y-webrtc, y-websocket, y-indexeddb, y-dat)

I am also wondering about the current relay server we are using in the examples. The main reason for CRDT vs OT (as far as I understand) is the ability to make a central server optional, so acting more like peer-to-peer. OT on the other hand needs a single central server to transform and propagate the operations. As the relay is now defined as a separate layer Synchronized Append-only Log, it sounds to me like it is a mandatory layer, so prevents us to do peer-to-peer. Or is this layer optional?

After having crunched more articles, and taken into account our jupyter context, maybe something like this could work

1. Jupyter Application Bindings: Integration in JupyterLab, Nteract, Dashboard... - this is custom to the application and use the second layer shared data structures.
2. The shared data structures: lumino-datastore wrapped in a javascript library (with optional redux binding) to propagate the changes via a communication provider.
3. The communication providers: There would be there 2 types: [1] Non-persistent ones (peer-to-peer with websocket, webrtc...) [2] Persistent ones (dat, ipfs and of course the jupyter rtc server).

Then comes the jupyter rtc server: These are the needed server components (nodejs or python hosted as a jupyter-server extension) to persist the operations/transactions (in an append-only log, or any other structure).