doc/book: ircd: add specification

bin/ircd2/src/irc/client.rs

@@ -158,10 +158,6 @@ impl<C: AsyncRead + AsyncWrite + Send + Unpin + 'static> IrcClient<C> {
             return Err(Error::MalformedPacket)
         }
 
-        if self.irc_config.password.is_empty() {
-            self.irc_config.is_pass_init = true
-        }
-
         let (command, value) = parse_line(&line)?;
         let (command, value) = (command.as_str(), value.as_str());
 
@@ -185,6 +181,12 @@ impl<C: AsyncRead + AsyncWrite + Send + Unpin + 'static> IrcClient<C> {
     }
 
     async fn registre(&mut self) -> Result<()> {
+        if !self.irc_config.is_pass_init {
+            if self.irc_config.password.is_empty() {
+                self.irc_config.is_pass_init = true
+            }
+        }
+
         if !self.irc_config.is_registered &&
             self.irc_config.is_cap_end &&
             self.irc_config.is_nick_init &&

bin/ircd2/src/irc/mod.rs

@@ -70,7 +70,6 @@ impl IrcConfig {
 
 pub struct IrcServer {
     settings: Args,
-    irc_config: IrcConfig,
     clients_subscriptions: SubscriberPtr<PrivMsgEvent>,
 }
 
@@ -79,10 +78,8 @@ impl IrcServer {
         settings: Args,
         clients_subscriptions: SubscriberPtr<PrivMsgEvent>,
     ) -> Result<Self> {
-        let irc_config = IrcConfig::new(&settings)?;
-        Ok(Self { settings, irc_config, clients_subscriptions })
+        Ok(Self { settings, clients_subscriptions })
     }
-
     pub async fn start(&self, executor: Arc<Executor<'_>>) -> Result<()> {
         let (notifier, recv) = async_channel::unbounded();
 
@@ -170,15 +167,12 @@ impl IrcServer {
         // Subscription for the new client
         let client_subscription = self.clients_subscriptions.clone().subscribe().await;
 
+        // new irc configuration
+        let irc_config = IrcConfig::new(&self.settings)?;
+
         // New irc client
-        let mut client = IrcClient::new(
-            writer,
-            reader,
-            peer_addr,
-            self.irc_config.clone(),
-            notifier,
-            client_subscription,
-        );
+        let mut client =
+            IrcClient::new(writer, reader, peer_addr, irc_config, notifier, client_subscription);
 
         // Start listening and detach
         executor

doc/src/SUMMARY.md

@@ -22,10 +22,10 @@
     - [Anonymous voting](zkas/examples/voting.md)
 - [Miscellaneous tools](misc/misc.md)
   - [vanityaddr](misc/vanityaddr.md)
-  - [ircd](misc/ircd.md)
+  - [ircd](misc/ircd/ircd.md)
+  	- [Specification](misc/ircd/specification.md)
   - [tau](misc/tau.md)
   - [HashChain](misc/hashchain/hashchain.md)
-  	- [Architecture](misc/hashchain/architecture.md)
   	- [Network Protocol](misc/hashchain/network_protocol.md)
   - [darkwiki](misc/darkwiki.md)
   - [dnetview](misc/dnetview.md)

doc/src/misc/hashchain/architecture.md

@@ -1,110 +0,0 @@
-# Structures 
-
-## EventId
-
-Hash of `Event` 
-
-	type EventId = [u8; 32];	
-
-## EventAction 
-
-The `Event` could have many actions according to the underlying data.
-
-	enum EventAction { ... };	
-
-### 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. 
-
-| 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  		 	   |
-| events_queue  | `EventsQueue`					   | Communication channel 
-
-## View 
-
-The `View` check the `Model` for new `Event`s, then dispatch these `Event`s to the clients. 
-
-`Event`s are sorted according to the timestamp attached to each `Event`.
-
-| Description   | Data Type      	   		    | Comments               |
-|-------------- | ----------------------------- | ---------------------- |
-| seen  		| HashMap<`EventId`, `Event`>   | A list of `Event`s 	 |
-
-## EventsQueue 
-
-The `EventsQueue` used to transport the event from `Model` to `View`.
-
-The `Model` fill The `EventsQueue` with the new `Event`, while the `View` keep
-fetching `Event`s from queue continuously.
-
-# 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.
-
-## Add new Event
-
-Once receiving new `Event` from the network protocol, the `Event` will be add to the
-orphans list. 
-
-After the ancestor for the new orphan gets found, The orphan `Event` will be add to the chain
-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 leaves 
-
-Remove leaves which are too far from the head leaf(the leaf in the longest chain).
-
-The depth difference from the common ancestor between a leaf to be removed and a head leaf 
-must be greater than `MAX_DEPTH`. 
-
-## Update the root 
-
-Finding the highest common ancestor for the leaves and assign it as the root
-for the tree.
-
-The highest common ancestor must have height greater than `MAX_HEIGHT`.
-
-![data structure](../../assets/mv_event.png)
-
-Example1
-
-
-
-

doc/src/misc/hashchain/hashchain.md

@@ -1,2 +1,108 @@
-# HashChain
+# Structures 
+
+## EventId
+
+Hash of `Event` 
+
+	type EventId = [u8; 32];	
+
+## EventAction 
+
+The `Event` could have many actions according to the underlying data.
+
+	enum EventAction { ... };	
+
+#### 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. 
+
+| 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  		 	   |
+| events_queue  | `EventsQueue`					   | Communication channel 
+
+## View 
+
+The `View` check the `Model` for new `Event`s, then dispatch these `Event`s to the clients. 
+
+`Event`s are sorted according to the timestamp attached to each `Event`.
+
+| Description   | Data Type      	   		    | Comments               |
+|-------------- | ----------------------------- | ---------------------- |
+| seen  		| HashMap<`EventId`, `Event`>   | A list of `Event`s 	 |
+
+## EventsQueue 
+
+The `EventsQueue` used to transport the event from `Model` to `View`.
+
+The `Model` fill The `EventsQueue` with the new `Event`, while the `View` keep
+fetching `Event`s from queue continuously.
+
+# 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.
+
+## Add new Event
+
+Once receiving new `Event` from the network protocol, the `Event` will be add to the
+orphans list. 
+
+After the ancestor for the new orphan gets found, The orphan `Event` will be add to the chain
+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 leaves 
+
+Remove leaves which are too far from the head leaf(the leaf in the longest chain).
+
+The depth difference from the common ancestor between a leaf to be removed and a head leaf 
+must be greater than `MAX_DEPTH`. 
+
+## Update the root 
+
+Finding the highest common ancestor for the leaves and assign it as the root
+for the tree.
+
+The highest common ancestor must have height greater than `MAX_HEIGHT`.
+
+![data structure](../../assets/mv_event.png)
+
+Example1
+
+
+
 

doc/src/misc/ircd.md

@@ -1,178 +1 @@
-# P2P IRC
-
-In DarkFi, we organize our communication using resilient and
-censorship-resistant infrastructure. For chatting, `ircd` is a
-peer-to-peer implementation of an IRC server in which any user can
-participate anonymously using any IRC frontend and by running the
-IRC daemon. `ircd` uses the DarkFi P2P engine to synchronize chats
-between hosts.
-
-
-## Installation
-
-```shell
-% git clone https://github.com/darkrenaissance/darkfi 
-% cd darkfi
-% make BINS=ircd
-% sudo make install BINS=ircd
-```
-
-Follow the instructions in the
-[README](https://darkrenaissance.github.io/darkfi/index.html) to ensure
-you have all the necessary dependenices.
-
-## Usage (DarkFi Network)
-
-Upon installing `ircd` as described above, the preconfigured defaults
-will allow you to connect to the network and start chatting with the
-rest of the DarkFi community.
-
-First, try to start `ircd` from your command-line so it can spawn its
-configuration file in place. The preconfigured defaults will autojoin
-you to the `#dev` channel, where the community is most active and
-talks about DarkFi development.
-
-```shell
-% ircd
-```
-
-After running it for the first time, `ircd` will create a configuration
-file you can review and potentially edit. It might be useful if you
-want to add other channels you want to autojoin (like `#philosophy`
-and `#memes`), or if you want to set a shared secret for some channel
-in order for it to be encrypted between its participants.
-
-When done, you can run `ircd` for the second time in order for it to
-connect to the network and start participating in the P2P protocol:
-
-```shell
-% ircd
-```
-
-## Clients
-
-### Weechat
-
-In this section, we'll briefly cover how to use the [Weechat IRC
-client](https://github.com/weechat/weechat) to connect and chat with
-`ircd`.
-
-Normally, you should be able to install weechat using your
-distribution's package manager. If not, have a look at the weechat
-[git repository](https://github.com/weechat/weechat) for instructions
-on how to install it on your computer.
-
-Once installed, we can configure a new server which will represent our
-`ircd` instance. First, start weechat, and in its window - run the
-following commands (there is an assumption that `irc_listen` in the
-`ircd` config file is set to `127.0.0.1:6667`):
-
-```
-/server add darkfi localhost/6667 -autoconnect
-/save
-/quit
-```
-
-This will set up the server, save the settings, and exit weechat.
-You are now ready to begin using the chat. Simply start weechat
-and everything should work.
-
-## Usage (Local Deployment)
-
-These steps below are only for developers who wish to make a testing
-deployment. The previous sections are sufficient to join the chat.
-
-### Seed Node
-
-First you must run a seed node. The seed node is a static host which
-nodes can connect to when they first connect to the network. The
-`seed_session` simply connects to a seed node and runs `protocol_seed`,
-which requests a list of addresses from the seed node and disconnects
-straight after receiving them.
-
-The first time you run the program, a config file will be created in
-`~/.config/darkfi` if your are using Linux or in 
-`~/Library/Application Support/darkfi/` on MacOS. 
-You must specify an inbound accept address in your config file to configure a seed node:
-
-```toml
-## P2P accept addresses
-inbound=["127.0.0.1:11001"]
-```
-
-Note that the above config doesn't specify an external address since
-the seed node shouldn't be advertised in the list of connectable
-nodes. The seed node does not participate as a normal node in the
-p2p network. It simply allows new nodes to discover other nodes in
-the network during the bootstrapping phase.
-
-### Inbound Node
-
-This is a node accepting inbound connections on the network but which
-is not making any outbound connections.
-
-The external addresses are important and must be correct.
-
-To run an inbound node, your config file must contain the following
-info:
-		
-```toml
-## P2P accept addresses
-inbound=["127.0.0.1:11002"]
-
-## P2P external addresses
-external_addr=["127.0.0.1:11002"]
-
-## Seed nodes to connect to 
-seeds=["127.0.0.1:11001"]
-```
-### Outbound Node
-
-This is a node which has 8 outbound connection slots and no inbound
-connections.  This means the node has 8 slots which will actively
-search for unique nodes to connect to in the p2p network.
-
-In your config file:
-
-```toml
-## Connection slots
-outbound_connections=8
-
-## Seed nodes to connect to 
-seeds=["127.0.0.1:11001"]
-```
-
-### Attaching the IRC Frontend
-
-Assuming you have run the above 3 commands to create a small model
-testnet, and both inbound and outbound nodes above are connected,
-you can test them out using weechat.
-
-To create separate weechat instances, use the `--dir` command:
-
-    weechat --dir /tmp/a/
-    weechat --dir /tmp/b/
-
-Then in both clients, you must set the option to connect to temporary
-servers:
-
-    /set irc.look.temporary_servers on
-
-Finally you can attach to the local IRCd instances:
-
-    /connect localhost/6667
-    /connect localhost/6668
-
-And send messages to yourself.
-
-### Running a Fullnode
-
-See the script `script/run_node.sh` for an example of how to deploy
-a full node which does seed session synchronization, and accepts both
-inbound and outbound connections.
-
-## Global Buffer
-
-Copy [this script](https://github.com/narodnik/weechat-global-buffer/blob/main/buffclone.py) to `~/.weechat/python/autoload/`,
-and you will create a single buffer which aggregates messages from all channels. It's useful to monitor activity
-from all channels without needing to flick through them.
+# ircd

doc/src/misc/ircd/ircd.md

@@ -0,0 +1,178 @@
+# P2P IRC
+
+In DarkFi, we organize our communication using resilient and
+censorship-resistant infrastructure. For chatting, `ircd` is a
+peer-to-peer implementation of an IRC server in which any user can
+participate anonymously using any IRC frontend and by running the
+IRC daemon. `ircd` uses the DarkFi P2P engine to synchronize chats
+between hosts.
+
+
+## Installation
+
+```shell
+% git clone https://github.com/darkrenaissance/darkfi 
+% cd darkfi
+% make BINS=ircd
+% sudo make install BINS=ircd
+```
+
+Follow the instructions in the
+[README](https://darkrenaissance.github.io/darkfi/index.html) to ensure
+you have all the necessary dependenices.
+
+## Usage (DarkFi Network)
+
+Upon installing `ircd` as described above, the preconfigured defaults
+will allow you to connect to the network and start chatting with the
+rest of the DarkFi community.
+
+First, try to start `ircd` from your command-line so it can spawn its
+configuration file in place. The preconfigured defaults will autojoin
+you to the `#dev` channel, where the community is most active and
+talks about DarkFi development.
+
+```shell
+% ircd
+```
+
+After running it for the first time, `ircd` will create a configuration
+file you can review and potentially edit. It might be useful if you
+want to add other channels you want to autojoin (like `#philosophy`
+and `#memes`), or if you want to set a shared secret for some channel
+in order for it to be encrypted between its participants.
+
+When done, you can run `ircd` for the second time in order for it to
+connect to the network and start participating in the P2P protocol:
+
+```shell
+% ircd
+```
+
+## Clients
+
+### Weechat
+
+In this section, we'll briefly cover how to use the [Weechat IRC
+client](https://github.com/weechat/weechat) to connect and chat with
+`ircd`.
+
+Normally, you should be able to install weechat using your
+distribution's package manager. If not, have a look at the weechat
+[git repository](https://github.com/weechat/weechat) for instructions
+on how to install it on your computer.
+
+Once installed, we can configure a new server which will represent our
+`ircd` instance. First, start weechat, and in its window - run the
+following commands (there is an assumption that `irc_listen` in the
+`ircd` config file is set to `127.0.0.1:6667`):
+
+```
+/server add darkfi localhost/6667 -autoconnect
+/save
+/quit
+```
+
+This will set up the server, save the settings, and exit weechat.
+You are now ready to begin using the chat. Simply start weechat
+and everything should work.
+
+## Usage (Local Deployment)
+
+These steps below are only for developers who wish to make a testing
+deployment. The previous sections are sufficient to join the chat.
+
+### Seed Node
+
+First you must run a seed node. The seed node is a static host which
+nodes can connect to when they first connect to the network. The
+`seed_session` simply connects to a seed node and runs `protocol_seed`,
+which requests a list of addresses from the seed node and disconnects
+straight after receiving them.
+
+The first time you run the program, a config file will be created in
+`~/.config/darkfi` if your are using Linux or in 
+`~/Library/Application Support/darkfi/` on MacOS. 
+You must specify an inbound accept address in your config file to configure a seed node:
+
+```toml
+## P2P accept addresses
+inbound=["127.0.0.1:11001"]
+```
+
+Note that the above config doesn't specify an external address since
+the seed node shouldn't be advertised in the list of connectable
+nodes. The seed node does not participate as a normal node in the
+p2p network. It simply allows new nodes to discover other nodes in
+the network during the bootstrapping phase.
+
+### Inbound Node
+
+This is a node accepting inbound connections on the network but which
+is not making any outbound connections.
+
+The external addresses are important and must be correct.
+
+To run an inbound node, your config file must contain the following
+info:
+		
+```toml
+## P2P accept addresses
+inbound=["127.0.0.1:11002"]
+
+## P2P external addresses
+external_addr=["127.0.0.1:11002"]
+
+## Seed nodes to connect to 
+seeds=["127.0.0.1:11001"]
+```
+### Outbound Node
+
+This is a node which has 8 outbound connection slots and no inbound
+connections.  This means the node has 8 slots which will actively
+search for unique nodes to connect to in the p2p network.
+
+In your config file:
+
+```toml
+## Connection slots
+outbound_connections=8
+
+## Seed nodes to connect to 
+seeds=["127.0.0.1:11001"]
+```
+
+### Attaching the IRC Frontend
+
+Assuming you have run the above 3 commands to create a small model
+testnet, and both inbound and outbound nodes above are connected,
+you can test them out using weechat.
+
+To create separate weechat instances, use the `--dir` command:
+
+    weechat --dir /tmp/a/
+    weechat --dir /tmp/b/
+
+Then in both clients, you must set the option to connect to temporary
+servers:
+
+    /set irc.look.temporary_servers on
+
+Finally you can attach to the local IRCd instances:
+
+    /connect localhost/6667
+    /connect localhost/6668
+
+And send messages to yourself.
+
+### Running a Fullnode
+
+See the script `script/run_node.sh` for an example of how to deploy
+a full node which does seed session synchronization, and accepts both
+inbound and outbound connections.
+
+## Global Buffer
+
+Copy [this script](https://github.com/narodnik/weechat-global-buffer/blob/main/buffclone.py) to `~/.weechat/python/autoload/`,
+and you will create a single buffer which aggregates messages from all channels. It's useful to monitor activity
+from all channels without needing to flick through them.

doc/src/misc/ircd/specification.md

@@ -0,0 +1,110 @@
+
+# Ircd Specification
+
+Ircd use [Hashchain](https://darkrenaissance.github.io/darkfi/misc/hashchain/hashchain.html)
+to maintain the synchronization between nodes. The messages are handled as
+events in Ircd network.
+
+
+## PrivMsgEvent
+
+This is the main message type inside Ircd. The `PrivMsgEvent` is an
+[event action](https://darkrenaissance.github.io/darkfi/misc/hashchain/hashchain.html#eventaction).
+
+
+| Description	| Data Type		| Comments																	| 
+|-------------- |-------------- | ------------------------------------------------------------------------- |
+| nickname		| String		| The nickname for the sender (must be less than 32 chars)					|
+| target		| String		| The target for the message (recipient)									|
+| message		| String		| The actual content of the message											|
+
+## ChannelInfo
+
+Preconfigured channel in the configuration file.
+
+In the TOML configuration file, the channel is set as such:
+
+```toml
+[channel."#dev"]
+secret = "GvH4kno3kUu6dqPrZ8zjMhqxTUDZ2ev16EdprZiZJgj1"
+topic = "DarkFi Development Channel"
+```
+
+| Description	| Data Type		| Comments																	|
+|-------------- |-------------- | ------------------------------------------------------------------------- |
+| topic			| String		| Optional topic for the channel											|
+| secret		| String		| Optional NaCl box for the channel, used for {en,de}cryption.				|
+| joined		| bool			| Indicate whether the user has joined the channel							|
+| names			| Vec<String>	| All nicknames which are visible on the channel							|
+
+
+## ContactInfo
+
+Preconfigured contact in the configuration file.
+
+In the TOML configuration file, the contact is set as such:
+
+```toml
+[contact."nick"]
+pubkey = "7CkVuFgwTUpJn5Sv67Q3fyEDpa28yrSeL5Hg2GqQ4jfM"
+```
+
+| Description	| Data Type		| Comments												|
+|-------------- |-------------- | ----------------------------------------------------- |
+| pubkey		| String		| A Public key for the contact to encrypt the message	|
+
+## IrcConfig
+
+The base Irc configuration for each new `IrcClient`.
+
+| Description	| Data Type						  | Comments																		|
+|-------------- |-------------------------------- | ------------------------------------------------------------------------------- |
+| is_nick_init	| bool							  | Confirmation of receiving /nick command											|
+| is_user_init	| bool							  | Confirmation of receiving /user command											|
+| is_cap_end	| bool							  | Indicate whether the irc client finished the Client Capability Negotiation		|
+| is_pass_init	| bool							  | Confirmation of checking the password in the configuration file					|
+| is_registered | bool							  | Indicate the `IrcClient` is initialized and ready to sending/receiving messages	|
+| nickname		| String						  | The irc client nickname															|
+| password		| String						  | The password for the irc client. (it could be empty)							|
+| private_key	| Option<String>				  | A private key to decrypt direct messages from contacts							|
+| capabilities	| HashMap<String, bool>			  | A list of capabilities for the irc clients and the server to negotiate			|
+| auto_channels	| Vec<String>					  | Auto join channels for the irc clients											|
+| channels		| HashMap<String, `ChannelInfo`>  | A list of preconfigured channels in the configuration file						|
+| contacts		| HashMap<String, `ContactInfo`>  | A list of preconfigured contacts in the configuration file for direct message	|
+
+## IrcServer
+
+The server start listening to an address specifed in the configuration file. 
+
+For each irc client get connected, an `IrcClient` instance created.
+
+A Communication channel get initialized by the server for the new `IrcClient` 
+and add to the subscriptions list for handling data between them. 
+in this way the server handle and maintain each irc client connection separately.  
+
+| Description				| Data Type						| Comments												|
+|-------------------------- |------------------------------ | ----------------------------------------------------- |
+| settings					| `Settings`					| The base settings parsed from the configuration file  |
+| clients_subscriptions		| SubscriberPtr<`PrivMsgEvent`> | Channels to notify the `IrcClient`s about new messages|
+
+##  IrcClient
+
+The `IrcClient` handle all irc opeartions and commands from the irc client.
+
+The subscription channel listen to the server for new messages from the ircd 
+network and pass them to the irc client. While notify the server to broadcast 
+new messages from the irc client.
+
+
+| Description		| Data Type							| Comments																	|
+|-------------------------- |------------------------------ | ----------------------------------------------------- |
+| write_stream		| WriteHalf<Stream>					| A writer for sending data to the connection stream						|
+| read_stream		| ReadHalf<Stream>					| Read data from the connection stream										|
+| address			| SocketAddr						| The actual address for the irc client connection							|
+| irc_config		| `IrcConfig`						| Base configuration for irc												|
+| server_notifier 	| Channel<(`PrivMsgEvent`, u64)> 	| A Channel to notify the server about a new message from the irc client	|
+| subscription 		| Subscription<`PrivMsgEvent`> 		| A channel to receive messages from the server 							|
+
+
+
+