Suggested improvements on the specs and documentations

[staheri14]

This issue encapsulates some suggested improvements on the specs and documentations.

The suggested improvement is to add a section to the client spec https://github.com/status-im/specs/blob/master/docs/stable/1-client.md (or even dedicate a separate spec) describing a centralized messaging system with its services followed by a 1-1 mapping between those services and different layers of the protocol stack of Status. The following outline can be used for this section:

**Introduction and problem definition:**

1. The introduction shall describe a centralized messaging system with its services (in details). The list of services can be something like below (note that the followings are only examples and not an exhaustive and accurate list):
2. Registration: This service allows a user to register to the system and later becomes reachable to the other users. Typically, users register to the system by a username and password.

3.     1:1 messaging: Given that the two ends of communication know each other's usernames, they can initiate a 1-1 chat. Their messages will be communicated through the central provider. 
   

4.     Group messaging: Group chats/channels are usually associated with a name similar to usernames. Users can join a group by knowing the group name, and then start messaging in the group. Note that group messages get delivered to all the members of the group.
   

5.     Discovery: All the usernames and group names are stored at the service provider-side. Users can search for each others usernames or group names through the central provider.
   

6.     Messaging Access Control management: Each user or group is associated with an access policy that determines who can participate in a group messaging or in a 1:1 messaging with a particular user. Messaging policies can be broadly categorized into public/permission-less and private/permission-based. 
   

7.     Asynchronous messaging: In an asynchronous chat e.g., emails, two ends of communication do not need to be online simultaneously. One end of the communication can be offline and yet the messages intended for her will get stored at the service provider database and delivered when she gets back online. Given that the service provider is always up and running, the delivery of the asynchronous messages is guaranteed.
   

8. Message delivery notification: This property allows the two ends of the communication to know whether their message is received/seen by the other end.

9.     …
   

10. The introduction shall also explain the security issues (or any other issues) of the centralized architecture that Status is going to overcome. Such issues shall be itemized and precisely described, examples of such issues can be:
    1. The lack of communication anonymity: The two ends of the communication are known to the service provider.
    2. The lack of privacy of the communication pattern: The central provider learns how frequent two users communicate thus infer some information regarding the strength of their social relations.
    3. Lack of data privacy: users messages are in plaintext format and accessible by the service provider

4. …

1. The introduction shall also briefly describe the contributions of Status and its advantages over a central messaging system (e.g., to overcome the aforementioned security issues).

Status Architecture
This part introduces the protocol stack and provides a mapping between the services listed in the introduction and each layer of the stack. Different layers of the stack can be itemized, and each item may be followed by the list of services it provides and the security issues that are meant to be solved by that layer.