diff --git a/doc/src/assets/mv_event.png b/doc/src/assets/mv_event.png new file mode 100644 index 000000000..df895df68 Binary files /dev/null and b/doc/src/assets/mv_event.png differ diff --git a/doc/src/misc/tau.md b/doc/src/misc/tau.md index 69800ba35..7260578f1 100644 --- a/doc/src/misc/tau.md +++ b/doc/src/misc/tau.md @@ -1,7 +1,7 @@ # Tau -Encrypted tasks management app using peer-to-peer network and raft consensus. -multiple users can collaborate by working on the same tasks, and all users will have synced task list. +Encrypted tasks management app using peer-to-peer network. +Multiple users can collaborate by working on the same tasks, and all users will have synced task list. ## Install @@ -196,3 +196,87 @@ Note: All filters from the previous section could work with mod commands. ```shell % tau switch darkfi # darkfi workspace needs to be configured in config file ``` + +## Tau Architecture + +Tau using Model–view software architecture. All the operations, main data structures, +and handling messages from network protocol, happen in the Model side. +While keeping the View independent of the Model and focusing on getting update +from it continuously, and preserve and apply rules to received data. + +### Model + +The Model consist of chains(EventNodes) structured as a tree, each chain has Event-based +list. To maintain strict order each event dependent on the hash of the previous event +in the chain's events. All the chains will shared a root event to preserve the tree +structure. check the diagram bellow + +On receiving new event from the network protocol, the event will be added to the +orphans list, then a process of reorganizing the events in orphans list will +start, if the Model doesn't have the ancestor event it will ask the network +for the missing events, otherwise the event will be added to a chain in the +model according to its ancestor. For example, in the diagram below, +if new event (Event-A2) received, it will be added to the first chain. + +### View + +The view's responsibility is to checking the chains in the Model and asking for +new events, while keeping a list of event ids which have been imported +previously to prevent importing the same event twice, then order these events +according to the timestamp attached to each event, the last step is +dispatching these events to the clients. + check the diagram bellow + + +![data structure](../assets/mv_event.png) + + +## Structures + +### EventId + +Hash of all the metadata in the event + + type EventId = [u8; 32]; + +### EventAction + +The event could have many actions according to the underlying data. + + enum EventAction { ... }; + +### Event + +| Description | Data Type | Comments | +|----------------------- | -------------- | --------------------------- | +| previous_event_hash | `EventId` | Hash of the previous event | +| Action | `EventAction` | event's action | +| Timestamp | u64 | event's timestamp | + +### EventNode + +| Description | Data Type | Comments | +|--------------- | ---------------------- | ---------------------------------------- | +| parent | Option<`EventNode`> | Only current root has this set to None | +| Event | `Event` | The event itself | +| Children | Vec<`EventNode`> | The events followed this event | + +### Model + +| Description | Data Type | Comments | +|-------------- | -------------------------------- | --------------------------- | +| current_root | `EventId` | The root event for the tree | +| orphans | Vec<`Event`> | Recently added events | +| event_map | HashMap<`EventId`, `EventNode`> | The actual tree | + +### View + +| Description | Data Type | Comments | +|-------------- | -------------------- | ------------------------------------------ | +| seen | HashSet<`EventId`> | A list of events have imported from Model | + + + + + +