## 6 System Development
### Crdt
#### 6.3.4 CRDT Implementation  
The base CRDT structure used for implementing a document-like structure is called a register. A register is a base structure that holds a series of information and functionality for the data structure that is changing:  
1. Value: the value synchronized between the peers;
2. State: the metadata required by the peers to agree on the same incoming update;
3. Merge functionality: offers a customizable way of handling the state mutation based on the remote state of the peer. Additionally, a register can require extra information like peer identification or a local identifier for the collaboration session. The merge function will have to define how the merging of states happens and on what terms between the peers. For the document collaboration scenario, the main acceptance criteria are the last emitted state by a user. This works on the assumption that regardless of the number of users and the order of the operations, the changes happen linearly. The nature of the event makes it unlikely for multiple users to work on the same document position while they introduce completely new content. The approach is called last write wins (LWWs). Depending on the scenario, the merge functionality can be customized to accommodate more logic like content differences check and timing checks. A last-writer-wins register (LWW register) generates a total order of assignments, associating a timestamp to each update. Timestamps are unique, totally ordered, and consistent with causal order [65]. This register can hold and merge states of any datatype. A document can hold more data and metadata, especially if the document contains rich formatted text. In this register example, the merge strategy will check the timestamp of the event and the peer dispatching that event to decide which state should be merged. For example, the document resource can contain the title entity and the actual text content. In that case, handling more document characteristics becomes expensive in terms of merging strategy and logic. The same issue applies when the state grows to a considerable size. In that case, a date modeling logic will minimize the object sizes transported over the network. Furthermore, it makes transportation more expensive because pieces of data that are not changed will get transported and included in the merge strategy evaluation process. To solve those issues regarding state organization, another conflict-free replication data type can be introduced: CRDT Map. A CRDT Map is a structure meant to combine multiple registers and control the merging strategies of each register [66]. For a proposed design for a last write wins map structure, a register is composed of a series of registers identifiable by a unique key. It is like a JSON-like object because it offers the flexibility of composing multiple convergent structures. The structure can be extended at runtime with other components or levels of CRDT structures. A CRDT Map can be extended to add a register on the fly, a behavior like adding sections of content in a text document dynamically. When a map requires a specific registry to merge and converge to a new state, the map will pass the remote state to the corresponding registry. The presented structure has another advantage: it provides the flexibility to compose registry or map entities to achieve big state objects. The map and registry structures agree to the same entity structure: value, state, and merge functionality, thus they are interchangeable. The document is composed of two changeable strings: title and content. Upon the start of a collaboration system, the user receives the document content snapshot from the server and creates a local CRDT copy of the document. On each local update of the content, the registers will update the local copy of the client, and at each peer update received it will merge the received state with the local copy. The local update is a core component of the state-based CRDT since it reflects the state of the current user.