doc/book: hashchain: reorganize message types & remove structures page

doc/src/SUMMARY.md

@@ -27,7 +27,6 @@
   - [HashChain](misc/hashchain/hashchain.md)
   	- [Architecture](misc/hashchain/architecture.md)
   	- [Network Protocol](misc/hashchain/network_protocol.md)
-  	- [Structures](misc/hashchain/structures.md)
   - [darkwiki](misc/darkwiki.md)
   - [dnetview](misc/dnetview.md)
 - [Learn](learn/learn.md)

doc/src/misc/hashchain/architecture.md

@@ -1,39 +1,90 @@
+# Structures 
 
-# Architecture 
+## EventId
 
-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.
+Hash of `Event` 
+
+	type EventId = [u8; 32];	
+
+## EventAction 
+
+The `Event` could have many actions according to the underlying data.
+
+	enum EventAction { ... };	
 
-## Model
+### Actions types
+
+#### Privmsg 
+
+| Description 	| Data Type   	| Comments																	|
+|-------------- |-------------- | ------------------------------------------------------------------------- |
+| 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 				 									|
+
+## Event
+
+| Description            | Data Type      | Comments                    |
+|----------------------- | -------------- | --------------------------- |
+| previous_event_hash    | `EventId` 	  | Hash of the previous `Event`|
+| Action     			 | `EventAction`  | `Event`'s action 			|
+| Timestamp     		 | u64  		  | `Event`'s timestamp 		|
+| read_confirms			 | u8	 		  | A confirmation counter 	    |
+
+## EventNode
+
+| Description    | Data Type      		  | Comments                    			 			  |
+|--------------- | ---------------------- | ----------------------------------------------------- |
+| parent    	 | Option<`EventId`> 	  | Only current root has this set to None   			  |
+| Event     	 | `Event`  			  | The `Event` itself 					       			  |
+| Children     	 | Vec<`EventId`>  	      | The `Event`s which has parent as this `Event` hash    |
+
+## Model 
 
 The `Model` consist of chains(`EventNodes`) structured as a tree, each chain has Event-based
 list. To maintain strict order in chain, Each `Event` dependent on the hash of the previous `Event`. 
 All the chains share a root `Event` to preserve the tree structure. 
 
-### Add new Event
+| Description   | Data Type      		  		   | Comments                      |
+|-------------- | -------------------------------- | ----------------------------- |
+| current_root  | `EventId` 	  		  		   | The root `Event` for the tree |
+| orphans       | HashMap<`EventId`, `Event`>  	   | Recently added `Event`s 	   |
+| event_map     | HashMap<`EventId`, `EventNode`>  | The actual tree  		 	   |
 
-On receiving new `Event` from the network protocol, the `Event` add to the
-orphans list, `Event` from orphans list add to chains according to its ancestor. 
+## View 
 
-For example, in the <em> Example1 </em> below, An `Event` add to the first chain if
-its previous hash is Event-A1
+The `View` asking `Model` for new `Event`s, then dispatching these `Event`s to the clients. 
 
-### Remove old chains 
+The `Event`s in `View` are sorted according to the timestamp attached to each `Event`.
 
-TODO
+| Description   | Data Type      	   | Comments                    					|
+|-------------- | -------------------- | ---------------------------------------------- |
+| seen  		| HashSet<`EventId`>   | A list of `Event`s have imported from Model	|
 
-### Update the root 
+# Architecture 
 
-TODO
+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.
 
-## View
+## Add new Event
 
-The `View` asking `Model` for new `Event`s, then dispatching these `Event`s to the clients. 
+On receiving new `Event` from the network protocol, the `Event` add to the
+orphans list. 
 
-The `Event`s in `View` are sorted according to the timestamp attached to each `Event`.
+`Event` from orphans list add to chains according to its ancestor. 
+
+For example, in the <em> Example1 </em> below, An `Event` add to the first chain if
+its previous hash is Event-A1
+
+## Remove old chains 
+
+	TODO
+
+## Update the root 
 
+	TODO
 
 ![data structure](../../assets/mv_event.png)
 

doc/src/misc/hashchain/network_protocol.md

@@ -8,33 +8,34 @@ been read from other nodes in the network.
 
 The protocol classify the Events by their state:
 
-	| Unread   |  read_confirms < `MAX_CONFIMRS`  | 
-	| Read 	   |  read_confirms >= `MAX_CONFIMRS` | 
+	Unread: read_confirms < `MAX_CONFIMRS` 
+	Read: 	read_confirms >= `MAX_CONFIMRS` 
 
-## Receiving a new `Event`
 
-The new received `Event` with unread status gets add to the `UnreadMessages` buffer after
-increasing the read_confirms by one. 
+## InvId
 
-The `Event` with read status gets add to the `Model`.
+	type InvId = u64;
 
-The protocol broadcast the received `Event` to the network again, to ensure every nodes
-in the network get the Event.
+## InvItem
 
-## Sending an `Event`
+| Description   | Data Type      	   | Comments      			    |
+|-------------- | -------------------- | -------------------------- |
+| Id  			| `InvId`  			   | Unique generated integer	|
+| Hash  		| `EventId`   		   | Hash of Event				|
 
-A new created `Event` has unread status with read_confirms equal to 0.
+## Inv
 
-The protocol broadcast the `Event` to the network after adding it to the
-`UnreadMessages`.
+| Description   | Data Type      	   | Comments           		|
+|-------------- | -------------------- | -------------------------- |
+| Invs	  	  	| Vec<`InvItem`> 	   | A list of `InvItem`		|
 
-## Receiving an `Inv` message
+### Receiving an `Inv` message
 
 An `Inv` message is a confirmation from a node in the network that the `Event`
 has been read.
 
 Confirmation for an `Event` not exist in the `UnreadMessages` list, 
-A `GetData` message must send back to request the missing `Event`.
+The protocol send a `GetData` message to request the missing `Event`.
 
 The protocol update the `Event` in the `UnreadMessages` list by increasing the
 read_confirms by one.
@@ -44,25 +45,30 @@ The state for updated `Event` change to read when the read_confirms exceed
 
 The protocol rebroadcast the received `Inv` to the network.
 
-## Sending an `Inv` message
+### Sending an `Inv` message
 
 On receiving an `Event` with unread status from the network, The protocol send back 
 an `Inv` message to confirm that the `Event` has been read.
 
-## Receiving a `GetData` message
+## GetData
+
+| Description   | Data Type      	   | Comments              		|
+|-------------- | -------------------- | -------------------------- |
+| Invs	  	    | Vec<`EventId`> 	   | A list of `EventId`   		|
+
+### Receiving a `GetData` message
 
 The protocol search in both `Model` and `UnreadMessages` for requested `Event`
 in `GetData` message.
 
-## Add new `Event` to `Model` 
 
-For the `Event` to be successfully add to the `Model`, the protocol check if
-the previous `Event`'s hash inside the `Event` is exist in the `Model`.
+## UnreadMessages
 
-In case the check for previous `Event` failed The protocol 
-send a `GetData` message requesting the previous `Event`.
+| Description | Data Type                   | Comments                                                                             |
+|-------------|---------------------------- | -------------------------------------------------------------------------------------|
+| Messages    | HashMap<`EventId`, `Event`> | Hold all the `Event`s that have broadcasted to other nodes but haven't confirmed yet |
 
-## Add new `Event` to `UnreadMessages` 
+### Add new `Event` to `UnreadMessages` 
 
 To add an `Event` to `UnreadMessages`, the protocol first must check the validity of
 `Event`. 
@@ -70,13 +76,19 @@ To add an `Event` to `UnreadMessages`, the protocol first must check the validit
 The `Event` is not valid in the network if it's too far in the future from now,
 or too far in the past from now.
 
-## Updating `UnreadMessages` list
+### Updating `UnreadMessages` list
 
 The protocol continually broadcast unread `Event` to the network 
 after a certain period of time(`SEND_UNREAD_EVENTS_INTERVAL`), 
 Until the state of `Event` updated to read.
 
-## Synchronization
+## SyncEvent 
+
+| Description | Data Type    	| Comments					 	|
+|-------------|---------------- |------------------------------ |
+| Leaves	  | Vec<`EventId`> 	| hash of `Event`s   			|
+
+### Synchronization
 
 To achieve complete synchronization between nodes, the protocol send a
 `SyncEvent` message every 2 seconds to other nodes in the network.
@@ -87,3 +99,37 @@ On receiving `SyncEvent` message, The leaves in `SyncEvent` should match the
 leaves in the `Model`'s tree, Otherwise the protocol send `Event`s which are the childern of
 `Event`s in `SyncEvent` 
 
+## Seen<ObjectId>
+
+This used to prevent receiving duplicate Objects.
+The list will contains only 2^16 ids.
+
+| Description | Data Type      | Comments			  		   |
+|-------------|--------------- |------------------------------ |
+| Ids		  | Vec<ObjectId>  | Contains objects ids    	   |
+
+
+## Receiving a new `Event`
+
+The new received `Event` with unread status add to the `UnreadMessages` buffer after
+increasing the read_confirms by one. 
+
+The `Event` with read status add to the `Model`.
+
+The protocol broadcast the received `Event` to the network again, to ensure every nodes
+in the network get the Event.
+
+## Sending an `Event`
+
+A new created `Event` has unread status with read_confirms equal to 0.
+
+The protocol broadcast the `Event` to the network after adding it to the
+`UnreadMessages`.
+
+## Add new `Event` to `Model` 
+
+For the `Event` to be successfully add to the `Model`, the protocol check if
+the previous `Event`'s hash inside the `Event` is exist in the `Model`.
+
+In case the check for previous `Event` failed The protocol 
+send a `GetData` message requesting the previous `Event`.

doc/src/misc/hashchain/structures.md

@@ -1,103 +0,0 @@
-# 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 		|
-| read_confirms			 | u8	 		  | A confirmation counter 	    |
-
-## EventNode
-
-| Description    | Data Type      		  | Comments                    			 			  |
-|--------------- | ---------------------- | ----------------------------------------------------- |
-| parent    	 | Option<`EventId`> 	  | Only current root has this set to None   			  |
-| Event     	 | `Event`  			  | The `Event` itself 					       			  |
-| Children     	 | Vec<`EventId`>  	      | The `Event`s which has parent as this `Event` hash    |
-
-## Model 
-
-| Description   | Data Type      		  		   | Comments                      |
-|-------------- | -------------------------------- | ----------------------------- |
-| current_root  | `EventId` 	  		  		   | The root `Event` for the tree |
-| orphans       | HashMap<`EventId`, `Event`>  	   | Recently added `Event`s 	   |
-| event_map     | HashMap<`EventId`, `EventNode`>  | The actual tree  		 	   |
-
-## View 
-
-| Description   | Data Type      	   | Comments                    					|
-|-------------- | -------------------- | ---------------------------------------------- |
-| seen  		| HashSet<`EventId`>   | A list of `Event`s have imported from Model	|
-
-## InvId
-
-	type InvId = u64;
-
-## InvItem
-
-| Description   | Data Type      	   | Comments      			    |
-|-------------- | -------------------- | -------------------------- |
-| Id  			| `InvId`  			   | Unique generated integer	|
-| Hash  		| `EventId`   		   | Hash of the Event			|
-
-## Inv
-
-| Description   | Data Type      	   | Comments           		|
-|-------------- | -------------------- | -------------------------- |
-| Invs	  	  	| Vec<`InvItem`> 	   | A list of `InvItem`		|
-
-## GetData
-
-| Description   | Data Type      	   | Comments              		|
-|-------------- | -------------------- | -------------------------- |
-| Invs	  	    | Vec<`EventId`> 	   | A list of `EventId`   		|
-
-## UnreadMessages
-
-| Description | Data Type                   | Comments                                                                             |
-|-------------|---------------------------- | -------------------------------------------------------------------------------------|
-| Messages    | HashMap<`EventId`, `Event`> | Hold all the `Event`s that have broadcasted to other nodes but haven't confirmed yet |
-
-## SyncEvent 
-
-| Description | Data Type    	| Comments					 	|
-|-------------|---------------- |------------------------------ |
-| Leaves	  | Vec<`EventId`> 	| hash of `Event`s   			|
-
-## Seen<ObjectId>
-
-This used to prevent receiving duplicate Objects.
-The list will contains only 2^16 ids.
-
-| Description | Data Type      | Comments			  		   |
-|-------------|--------------- |------------------------------ |
-| Ids		  | Vec<ObjectId>  | Contains objects ids    	   |
-
-
-## Actions types
-
-### Privmsg 
-
-| Description 	| Data Type   	| Comments																	|
-|-------------- |-------------- | ------------------------------------------------------------------------- |
-| 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 				 									|
-
-
-
-