Merge remote-tracking branch 'origin/main' into refactor-list

This commit is contained in:
Zixuan Chen 2022-11-18 21:03:05 +08:00
commit 4f1cb76964
2 changed files with 68 additions and 2 deletions

View file

@ -1,4 +1,36 @@
# Loro
<p align="center">
<a href="https://loro.dev">
<picture>
</picture>
<h1 align="center">Loro 🦜</h1>
</a>
</p>
# Dev
Loro is a fast [CRDT](https://crdt.tech/) framework with built-in end-to-end encryption ability.
It provides a set of data structures that can automatically sync without any conflict. With end-to-end encryption addon, all data can be encrypted without losing the ability to collaborate with the others. It aims to be the engine for building [local-first software](https://www.inkandswitch.com/local-first/).
# Why Loro
- 🚀 It is pretty fast
- 🔒 [WIP] Security built-in
- 💻 Syncing data made easy
- 📜 Preserve all history with low overhead
- 🪐 [WIP] Time travel the history in milliseconds
Loro supports a variety of data structures and CRDT algorithms.
- It supports the most used `List`, `Map` and `Text`.
- [TODO] [Peritext](https://www.inkandswitch.com/peritext/) for fine-grind rich text operations
- [TODO] [Moveable Tree]() for directory-like moving operations
- [WIP] Super fast version checkout and undo/redo
# Credits
- Automerge for its columnar encoding algorithm
- Yjs for the efficient algorithm of merging blocks
- Diamond-types for its idea of low-overhead merging algorithm
- Ink & Switch for Local-first Software and Peritext

34
docs/Glossary.md Normal file
View file

@ -0,0 +1,34 @@
# Glossary
| Name | Meaning | Note |
|-------------------------|----------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
| DAG | Directed Acyclic Graph | The changes in Loro form a DAG. The relationship is expressed by deps field. |
| [RLE](#rle) | Run Length Encoding | We not only use it on the encoding, but also in the vec and tree. |
| Change | A merged batch of ops | |
| Frontiers | The DAG nodes that no one has dependencies on them | They can be represented by a series of id |
| Op | Operation | |
| State (of a Container) | The | In the code, the state most refers to the visible state to users. For example, the text string of a text container, the key value pairs in the map container |
| Effect (of an Op) | How the op affect the state | We use CRDT to calculate the effect (obviously) |
| Tracker | A special data structure to calculate the effects | |
| [Container](#container) | A unit of CRDT data structure | |
| Content | Content of an Op | |
| ID | A global unit id for an Op | It has the structure of {clientId, counter} |
| Counter | The second field inside ID | |
| Lamport | [Lamport timestamp](https://en.wikipedia.org/wiki/Lamport_timestamp) | |
| Span | A series of continuous things | |
| Causal Order | The order of happen-before relationship | The DAG expresses the causal order of the changes |
| VV | [Version Vector](https://en.wikipedia.org/wiki/Version_vector) | |
### RLE
We not only use RLE on the encoding, but also in the vec and tree.
i.e. the elements can be merged, sliced and have lengths. We call the element with length of 1 as atom element (cannot be sliced).
We use a `Rle` trait to express it. So `Op`, `Change`, elements inside `RleTree` all implement `Rle`.
This gives us a compact way to represent the mergeable elements.
### Container
Each op is associated with one container. Different CRDT algorithms use different types of containers. There are hierarchical relationship between containers, but they cannot affect each other