Jelajahi Sumber

doc/book: add more pages to tau

ghassmo 3 tahun lalu
induk
melakukan
07a54d6eab

+ 4 - 2
doc/src/SUMMARY.md

@@ -22,8 +22,10 @@
 - [Miscellaneous tools](misc/misc.md)
 - [Miscellaneous tools](misc/misc.md)
   - [vanityaddr](misc/vanityaddr.md)
   - [vanityaddr](misc/vanityaddr.md)
   - [ircd](misc/ircd.md)
   - [ircd](misc/ircd.md)
-  - [ircd new](misc/ircd_new.md)
-  - [tau](misc/tau.md)
+  - [tau](misc/tau/tau.md)
+  	- [Architecture](misc/tau/architecture.md)
+  	- [Specification](misc/tau/specification.md)
+  	- [Network Protocol](misc/tau/network_protocol.md)
   - [darkwiki](misc/darkwiki.md)
   - [darkwiki](misc/darkwiki.md)
   - [dnetview](misc/dnetview.md)
   - [dnetview](misc/dnetview.md)
 - [Learn](learn/learn.md)
 - [Learn](learn/learn.md)

+ 0 - 86
doc/src/misc/ircd_new.md

@@ -1,86 +0,0 @@
-# Ircd Protocol
-
-## Structures
-
-### Chain
-
-All the nodes have only one chain contains all the `Privmsg`s in stricted order
-
-| Description | Data Type    | Comments                                                       	|
-|-------------|--------------|----------------------------------------------------------------- |
-| Buffer      | Vec<Privmsg> | Contains the last 2^12 Confirmed `Privmsg`s                    	|
-| Hashes      | Vec<String>  | Hold the hashes of all `Privmsg`s including the genesis `Privmsg`|
-
-### UnreadMessages
-
-Once a `Privmsg` received from the network it will be added to this list unless it has `read_confirms` above the `MAXIMUM CONFIRMATION`. 
-All unread `Privmsg`s are continually sent until receiving confirmations from other nodes.  
-
-All the `Privmsg`s will apply to these filtering rules: 
-- Reject new `Privmsg` too far in the future from now (20 Minutes)
-- Reject old `Privmsg` too far in the past from now (1 Hour)
-- All `Privmsg`s are organized by timestamp. Older `Privmsg`s just gently expired and are then ignored.
-
-| Description | Data Type                | Comments                                                                             |
-|-------------|--------------------------|--------------------------------------------------------------------------------------|
-| Messages    | HashMap<String, Privmsg> | Hold all the `Privmsg`s that have broadcasted to other nodes but haven't confirmed yet |
-
-### SeenIds
-
-Every message received its id will be add to this list to prevent duplicate messages.
-The list will contains only 2^16 ids.
-
-| Description | Data Type   | Comments							   |
-|-------------|-------------|------------------------------------- |
-| Ids		  | Vec<String> | Contains all the network message ids |
-
-## Message types
-
-### Privmsg 
-
-| Description 	| Data Type   	| Comments																	|
-|-------------- |-------------- | ------------------------------------------------------------------------- |
-| id	  	  	| String	 	| A Hash of all metadata including the previous `Privmsg`'s id	  			|
-| nickname    	| String		| The nickname for the sender (must be less than 32 chars) 					|
-| target      	| String		| The target for the `Privmsg` (recipient) 				 					|
-| message     	| String		| The `Privmsg`'s content 				 									|
-| timestamp	  	| i64	 		| The timestamp for `Privmsg` (created by the sender)						|
-| read_confirms	| u8	 		| A confirmation counter 	  												|
-| prev_id	  	| String	 	| The id for the previous `Privmsg`	  										|
-
-
-### Inv
-
-On receiving a new `Privmsg`, the node must broadcast this message to all other nodes
-
-| Description | Data Type   | Comments													|
-|-------------|-------------|---------------------------------------------------------- |
-| Id		  | String 		| A unique ID string   										|
-| Hash	  	  | String 		| A hash of all `Privmsg`'s metadata RIPEMD-160(`Privmsg`)  |
-
-### GetMsgs 
-
-On receiving an `Inv` message if the node doesn't have the hash in `Inv`, 
-Then the node will send back a `GetMsgs` to request the `Privmsg`
-
-| Description | Data Type   | Comments													|
-|-------------|-------------|---------------------------------------------------------- |
-| Invs	  	  | Vec<String> | A list of `Privmsg` hashes  								|
-
-### SyncHash 
-
-Every 2 seconds each node must broadcast this message which contains the height of its chain
-to ensure the chain remain roughly in sync.
-
-| Description | Data Type   | Comments													|
-|-------------|-------------|---------------------------------------------------------- |
-| Height	  | u64 		| The Height of the chain  									|
-
-### Hashes
-
-Once receiving a `SyncHash` message, the node will send back all the missed hashes from the height in `SyncHash`
-
-| Description | Data Type   | Comments																	|
-|-------------|-------------|-------------------------------------------------------------------------- |
-| Hashes	  | Vec<String> | A list of `Privmsg` hashes  												|
-| Height  	  | u64			| The height of chain in which the first message in the Hashes list begin 	|

+ 43 - 0
doc/src/misc/tau/architecture.md

@@ -0,0 +1,43 @@
+
+# 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. <em> check the diagram bellow  </em>
+
+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.
+
+## Find head event 
+	TODO
+
+## Find common ancestors
+	TODO
+
+## 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. 
+<em> check the diagram bellow  </em>
+
+
+![data structure](../../assets/mv_event.png)
+
+
+
+

+ 4 - 0
doc/src/misc/tau/network_protocol.md

@@ -0,0 +1,4 @@
+# Network Protocol
+	TODO
+
+

+ 46 - 0
doc/src/misc/tau/specification.md

@@ -0,0 +1,46 @@
+# Specification
+
+## 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	|
+
+
+

+ 0 - 90
doc/src/misc/tau.md → doc/src/misc/tau/tau.md

@@ -135,96 +135,6 @@ Note: All filters from the previous section could work with mod commands.
 % tau switch darkfi	# darkfi workspace needs to be configured in config file
 % 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. <em> check the diagram bellow  </em>
-
-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.
-
-### Find head event 
-	TODO
-
-### Find common ancestors
-	TODO
-
-### 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. 
-<em> check the diagram bellow  </em>
-
-
-![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	|
-
-
-
-## Tau network protocol
-	TODO
-
-
 ## Local Deployment
 ## Local Deployment
 
 
 ### Seed Node
 ### Seed Node