spelling

x4.md

@@ -55,7 +55,7 @@ Conversational Security Layer provides various cryptographic properties:
 3. **Authentication** - Each participant in the conversation receives a proof of possession of a known long-term secret from all other participants. In addition, each participant is able to verify that a message was sent from the claimed source. 
 
    This assumes trust has already been established, see [Initial Trust Establishment Specification](x5.md).
-1. **Forward secrecy** - Also known as perfect forward secrecy (PFS), gives assurance that session keys will not be compromised even if the private key is compromised. Also, compromising one session key will not result in compromising other sessions.
+4. **Forward secrecy** - Also known as perfect forward secrecy (PFS), gives assurance that session keys will not be compromised even if the private key is compromised. Also, compromising one session key will not result in compromising other sessions.
 
 Please refer to [Initial Conversational Security Specification](x6.md) for more details.
 
@@ -71,13 +71,15 @@ Please refer to [Initial Transport Privacy through Whisper Specification](x7.md)
 
 # P2P layer
 
-P2P layer allows various clients to securely communicate with each other through the internet in a decetralized fashion, envetually forming a peer-to-peer network. Due to our close relationship to Ethereum and the fact that Whisper is built on top of [devp2p](https://github.com/ethereum/devp2p), we use [devp2p](https://github.com/ethereum/devp2p) as a P2P layer.
+P2P layer allows various clients to securely communicate with each other through the internet in a decentralized fashion, eventually forming a peer-to-peer network. Due to our close relationship to Ethereum and the fact that Whisper is built on top of [devp2p](https://github.com/ethereum/devp2p), we use [devp2p](https://github.com/ethereum/devp2p) as a P2P layer.
 
 A client in order to rely a message needs to first find other clients (this process is called node discovery and is out of scope of this specification) within the peer-to-peer network. Then, the message needs to be properly routed handling obstacles like NAT traversal. All these things are handled by devp2p.
 
+<!--
 # Censorship resistance
 
 TODO
+-->
 
 # Dependencies between layers
 

x5.md

@@ -47,7 +47,7 @@ No Name Squatting
 Asynchronous
 Scalable
 
-NOTE: Several of these we don't do, and e.g. ENS/mutlikey stuff can be noted as future enhancement
+NOTE: Several of these we don't do, and e.g. ENS/multikey stuff can be noted as future enhancement
 
 ## Trust establishment
 
@@ -135,7 +135,7 @@ comments:
 >  Key maintenance encompasses recurring effort users have to invest into maintaining keys. Some systems require that users sign other keys or renew expired keys. Usable systems require no key maintenance tasks
   
 - no key maintenance is required, only safekeeping of the backup seed phrase.
-- In the future, functionality like universal logins would be useful to extend the options of user-facing key maintanence and device risk/revocation.
+- In the future, functionality like universal logins would be useful to extend the options of user-facing key maintenance and device risk/revocation.
 
 #### Easy Key Discovery (YES)
 > When new contacts are added, no additional effort is needed to retrieve key material.
@@ -146,7 +146,7 @@ comments:
 #### Easy Key Recovery (YES)
 > When users lose long-term key material, it is easy to revoke old keys and initialize new keys (e.g., simply reinstalling the app or regenerating keys is sufficient).
 
-- Key recovery is re-initializing your account with your backed up recovery phrase, which rederives all needed keys
+- Key recovery is re-initializing your account with your backed up recovery phrase, which re-derives all needed keys
 
 #### In-band (YES)
 > No out-of-band channels are needed that require users to invest additional effort to establish.
@@ -162,7 +162,7 @@ comments:
 > If other participants renew their long-term keys, a user can proceed without errors or warnings.
  
 - There is no key renewal for base trust establishment, a user is a public-key
-- In the future, Universal logins will help with this maintanence and functionality
+- In the future, Universal logins will help with this maintenance and functionality
 
 #### Immediate Enrollment (YES)
 > When keys are (re-)initialized, other participants are able to verify and use them immediately
@@ -202,8 +202,8 @@ comments:
 > Users can choose their names and can be prevented from reserving a large number of popular names
 
 - In general, yes.
-- Public keys have a big space. For three-random words it is possible to generate arbitrary combinations with decent computational resources, but this doesn' amonut to "reserving" it.
-- For ENS, no. But for each name, a stake of 10 SNT is required, as well as the creation of a new identity (unless they interact directly with the ENSregistration contract directly and not through the app)
+- Public keys have a big space. For three-random words it is possible to generate arbitrary combinations with decent computational resources, but this doesn't amount to "reserving" it.
+- For ENS, no. But for each name, a stake of 10 SNT is required, as well as the creation of a new identity (unless they interact directly with the ENS registration contract directly and not through the app)
 
 #### Asynchronous (YES)
 > Trust establishment can occur asynchronously without all conversation participants online.

x6.md

@@ -171,7 +171,7 @@ There are two phases in the initial negotiation of a 1:1 chat:
 1. **Identity verification** (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial bundle retrieval;
 1. **Asynchronous initial key exchange**, using X3DH.
 
-TODO: I'd consider calling the first Trust Establishment and lnik to that document
+TODO: I'd consider calling the first Trust Establishment and link to that document
 
 #### 2.4.1. Initial key exchange flow (X3DH)
 
@@ -308,7 +308,7 @@ A peer is identified by two pieces of data:
 1) An `installation-id` which is generated upon creating a new account in the `Status` application
 2) Their identity whisper key
 
-## 3.1 Initializiation
+## 3.1 Initialization
 
 A new session is initialized once a successful X3DH exchange has taken place.
 Subsequent messages will use the established session until re-keying is necessary.
@@ -421,7 +421,7 @@ TODO: description here
 - Yes.
 - Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validates its signature from the sender, then it is not able to be altered in transit.
     * [igorm] i'm really not sure about it, Whisper provides a signature, but I'm not sure we check it anywhere (simple grepping didn't give anything)
-    * [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easilly create a random account)
+    * [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easily create a random account)
 
 #### Authentication (YES)
 >  Each participant in the conversation receives proof of possession of a known long-term secret from all other participants that they believe to be participating in the conversation. In addition, each participant is able to verify that a message was sent from the claimed source
@@ -456,7 +456,7 @@ TODO: description here
 [Andrea: This is not true, (Perfect) Forward Secrecy does not imply backward secrecy (which is also called post-compromise security, as signal calls it, or future secrecy, it's not well defined). Technically this is a NO , double ratchet offers good Backward secrecy, but not perfect. Effectively if all the key material is compromised, any future message received will be also compromised (due to the hash ratchet), until a DH ratchet step is completed (i.e. the compromised party generate a new random key and ratchet)]
 
 #### Anonymity Preserving (PARTIAL)
-> Any anonymity features provided by the underlying transport privacy architecture are not undermined (e.g., if the transport privacy system provides anonymity, the conversation security level does not deanonymize users by linking key identifiers).
+> Any anonymity features provided by the underlying transport privacy architecture are not undermined (e.g., if the transport privacy system provides anonymity, the conversation security level does not de-anonymize users by linking key identifiers).
 
 - by default, yes
 - ENS Naming system attaches an identifier to a given public key
@@ -466,7 +466,7 @@ TODO: description here
 
 - We use Lamport timestamps for ordering of events.
 - In addition to this, we use local timestamps to attempt a more intuitive ordering. [Andrea: currently this was introduced as a regression during performance optimization and might result in out-of-order messages if sent across day boundaries, so I consider it a bug and not part of the specs (it does not make the order more intuitive, quite the opposite as it might result in causally related messages being out-of-order, but helps dividing the messages in days)]
-- Fundamentally, there's no single source of truth, nor consensus process for global ordering [Andrea: Global ordering does not need a consensus process i.e. if you order messages alphabetically, and you break ties consistenly, you have global ordering, as all the participants will see the same ordering (as opposed to say order by the time the message was received locally),  of course is not useful, you want to have causal + global to be meaningful]
+- Fundamentally, there's no single source of truth, nor consensus process for global ordering [Andrea: Global ordering does not need a consensus process i.e. if you order messages alphabetically, and you break ties consistently, you have global ordering, as all the participants will see the same ordering (as opposed to say order by the time the message was received locally),  of course is not useful, you want to have causal + global to be meaningful]
 
 TODO: Understand how this is different from Global Transcript
 [Andrea: This is basically Global transcript for a single participants, we offer global transcript]
@@ -507,7 +507,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
 #### Computational Equality (YES)
 >  All chat participants share an equal computational load
 
-- One a message is sent, all participanats in a group chat perform the same steps to retrieve and decrypt it. 
+- One a message is sent, all participants in a group chat perform the same steps to retrieve and decrypt it. 
 - If proof of work is actually used at the Whisper layer (basically turned off in Status) then the sender would have to do additional computational work to send messages.
 
 #### Trust Equality (PARTIAL)
@@ -515,7 +515,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
 
 - 1:1 chats and public chats are equal
 - group chats have admins (on purpose)
-- Private Group chats have Administrators and Members.  Upon construction, the creator is made an admin. These groups have the following priveledges:
+- Private Group chats have Administrators and Members.  Upon construction, the creator is made an admin. These groups have the following privileges:
     - Admins:
         - Add group members
         - Promote group members to admin
@@ -528,7 +528,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
         - Invited people don't opt-in to being invited
 
 TODO: Group chat dynamics should have a documented state diagram
-TODO: create issues for identity leak of invited members as well as current members of a group showing up who have not accepted yet [Andrea: that's an interesting point, didn't think of that. Currently we have this behaviour for 2 reasons, backward compatibility with previous releases, which had no concept of joining, and also because we rely on other peers to propagate group info, so we don't have a single-message point of failure (the invitation), the first can be addressed easilly, the second is trickier, without giving up the propagation mechanism (if we choose to give this up, then it's trivial)]
+TODO: create issues for identity leak of invited members as well as current members of a group showing up who have not accepted yet [Andrea: that's an interesting point, didn't think of that. Currently we have this behavior for 2 reasons, backward compatibility with previous releases, which had no concept of joining, and also because we rely on other peers to propagate group info, so we don't have a single-message point of failure (the invitation), the first can be addressed easily, the second is trickier, without giving up the propagation mechanism (if we choose to give this up, then it's trivial)]
 
 #### Subgroup Messaging (NO)
 > Messages can be sent to a subset of participants without forming a new conversation
@@ -588,4 +588,4 @@ TODO: this requires more detail
 
 - The protocol requires whisper relay servers and mailservers currently. 
 - The larger the number of whisper relay servers, the better the transport security but there might be potential scaling problems.
-- Mailservers act to provide asyncronicity so users can retreive messages after coming back from an offline period. 
+- Mailservers act to provide asynchronicity so users can retrieve messages after coming back from an offline period. 

x7.md

@@ -161,7 +161,7 @@ For more details regarding serialization and deserialization please consult [tra
 
 ## Content types
 
-Content types are required for a proper interpretation of incoming messaages. Not each message is a plain text but may carry a different information.
+Content types are required for a proper interpretation of incoming messages. Not each message is a plain text but may carry a different information.
 
 The following content types MUST be supported:
 * `text/plain` identifies a message which content is a plain text
@@ -175,7 +175,7 @@ TODO: select which are required and which are client-specific.
 
 ## Message types
 
-Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attacjed (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
+Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attached (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
 
 The following messages types MUST be supported:
 * `public-group-user-message` is a message to the public group
@@ -196,11 +196,11 @@ TBD
 
 # Whisper adapter
 
-Whisper in version 6 has been chosen as an messages exchange protocol because it was designed as an off-chain communication layer for the Ethereum nodes. It supports e2e encryption and uses epidemic spread to route data to all members of the network. It also provides [darkness to some extent](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness).
+Whisper in version 6 has been chosen as a messages exchange protocol because it was designed as an off-chain communication layer for the Ethereum nodes. It supports e2e encryption and uses epidemic spread to route data to all members of the network. It also provides [darkness to some extent](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness).
 
 However, using Whisper has a few tradeoffs:
 * was not designed to handle huge number of messages
-* was not designed to be real-time; some delays over a few seconods are expected
+* was not designed to be real-time; some delays over a few seconds are expected
 * does not scale well with the number of messages in the network
 
 This protocol can operate using a Whisper service which requires this protocol implementation to run in the same process as well as Whisper's RPC API which might be provided by a separate Whisper node process via IPC or WebSocket.
@@ -211,7 +211,7 @@ There is some tight coupling between the payload and Whisper:
 
 ## Whisper node configuration
 
-If you want to run a Whisper node and receive messages from Status clients, it must be properly cnofigured.
+If you want to run a Whisper node and receive messages from Status clients, it must be properly configured.
 
 Whisper's Proof Of Work algorithm is used to deter denial of service and various spam/flood attacks against the Whisper network. The sender of a message must perform some work which in this case means processing time. Because Status' main client is a mobile client, this easily leads to battery draining and poor performance of the app itself. Hence, all clients MUST use the following Whisper node settings:
 * proof-of-work not larger than `0.002`
@@ -233,7 +233,7 @@ Keys management for PFS is described in [Perfect forward secrecy section](#perfe
 
 All encryption algorithms used by Whisper should be described in the [Whisper V6 specification](http://eips.ethereum.org/EIPS/eip-627).
 
-Cryptographic algoritms used by PFS are described in [Perfect forward secrecy section](#perfect-forward-secrecy-pfs).
+Cryptographic algorithms used by PFS are described in [Perfect forward secrecy section](#perfect-forward-secrecy-pfs).
 
 ## Topic
 
@@ -287,7 +287,7 @@ As not all messages are encrypted with PFS, a following strategy MAY be used:
 2. Try to decrypt the message payload using PFS algorithm
 2.1. If successful, pass the decrypted value to (3)
 2.2. If failed, pass the unchanged payload to (3)
-3. Decode the payload as described in [Paylooad](#payload) section
+3. Decode the payload as described in [Payload](#payload) section
 
 TODO: link to a separate document (currently in the PR).
 
@@ -299,7 +299,7 @@ TODO: link to a separate document.
 
 # One-to-one messages
 
-One-to-one messages are also known as private messages. These are the messages sent beween two participants of the conversation.
+One-to-one messages are also known as private messages. These are the messages sent between two participants of the conversation.
 
 ## Sending
 
@@ -322,7 +322,7 @@ Learn more following [Whisper V6 RPC API](https://github.com/ethereum/go-ethereu
 
 ### Sending using PFS
 
-When one decides to use PFS, the flow is the same but the payload MUST be additionally encrypted following the [PFS specification](#pfs) before being hex-endoded and passed to `shh_post`.
+When one decides to use PFS, the flow is the same but the payload MUST be additionally encrypted following the [PFS specification](#pfs) before being hex-encoded and passed to `shh_post`.
 
 ## Receiving
 
@@ -342,7 +342,7 @@ Learn more following [Whisper V6 RPC API](https://github.com/ethereum/go-ethereu
 
 Public messages are encrypted with a symmetric key which is publicly known so anyone can participate in the conversation.
 
-The fact that anyone can participate makes the public chats voulnerable to spam attacks. Also, there are no moderators of these chats.
+The fact that anyone can participate makes the public chats vulnerable to spam attacks. Also, there are no moderators of these chats.
 
 ## Sending
 
@@ -433,7 +433,7 @@ This evaluates Whisper as a standalone protocol. However, we also note common us
 
 - However, since the "signature" of an envelope doesn't change, this means a Global Passive Adversary can watch a packet as it traverses the network.
 
-- Additionally, being fully surrounded by cooperating adverserial nodes breaks this. This is similar to an eclipse attack, since these nodes can cooperate and distinguish between relaying messages and new messages.
+- Additionally, being fully surrounded by cooperating adversarial nodes breaks this. This is similar to an eclipse attack, since these nodes can cooperate and distinguish between relaying messages and new messages.
 
 - Light clients that don't repeat traffic will leave more obvious metadata trail.
 
@@ -459,7 +459,7 @@ This evaluates Whisper as a standalone protocol. However, we also note common us
     - Private group chat
     - Public chats
 
-- Since Whisper is broadcast based, we use topics for this. This ensures the bandwidth usage is somewhat more managable, trading off darkness.
+- Since Whisper is broadcast based, we use topics for this. This ensures the bandwidth usage is somewhat more manageable, trading off darkness.
 
 - Public chats are hashed to a topic. Then we have a special discovery topic, which we use to coordinate further topics. E.g. for group chat there's a a secret, random topic that's agreed upon for further communication. 1:1 currently uses discovery topic, but you can either partition this or use things like topic ratcheting. This is at the expense of some more coordination, similar to how you generate a shared secret key.
 
@@ -479,7 +479,7 @@ This evaluates Whisper as a standalone protocol. However, we also note common us
 #### Global Adversary Resistant (NO)
 > Global adversaries cannot break the anonymity of the protocol
 
-- Sender anonymity is broken if an envelope has a unique signature, as well as in the abovementioned eclipse-like attack.
+- Sender anonymity is broken if an envelope has a unique signature, as well as in the above mentioned eclipse-like attack.
 
 ### --- Usability
 

x8.md

@@ -14,7 +14,7 @@ updated:
 
 This specification describes how the payload of each message in the Status Protocol looks like. It does not care how the payload is encrypted or exchanged later.
 
-The payload must be flexible enough to support messenging but also cases described in [Status Whitepaper](https://status.im/whitepaper.pdf) as well as various clients created using vastly different technologies.
+The payload must be flexible enough to support messaging but also cases described in [Status Whitepaper](https://status.im/whitepaper.pdf) as well as various clients created using vastly different technologies.
 
 # Wrapper
 
@@ -31,7 +31,7 @@ record:
 Where `signature` is the bytes of the signed `SHA3-256` of the payload, signed with
 the key of the author of the message.
 The signature is needed to validate authorship of the message, so that the message can be relayed to third parties.
-If a signature is not present but an author is provided by a layer below, the message is to be relayed to third parties and it's considered plausibly deniable.
+If a signature is not present but an author is provided by a layer below, the message is to be relayed to third parties and its considered plausibly deniable.
 
 # Encoding
 
@@ -65,7 +65,7 @@ The type `Message` represents a text message exchanged between clients.
 
 ### Payload
 
-Payload is a struct (a compound data type) with the following fields (order is importent):
+Payload is a struct (a compound data type) with the following fields (order is important):
 1. text `string`
 2. content type `enum` (more in [Content types](#content-types))
 3. message type `enum` (more in [Message types](#message-types))
@@ -76,7 +76,7 @@ Payload is a struct (a compound data type) with the following fields (order is i
 
 ### Content types
 
-Content types are required for a proper interpretation of incoming messaages. Not each message is a plain text but may carry a different information.
+Content types are required for a proper interpretation of incoming messages. Not each message is a plain text but may carry a different information.
 
 The following content types MUST be supported:
 * `text/plain` identifies a message which content is a plain text.
@@ -90,7 +90,7 @@ There are also other content types that MAY be implemented by the client:
 
 ### Message types
 
-Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attacjed (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
+Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attached (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
 
 The following messages types MUST be supported:
 * `public-group-user-message` is a message to the public group

x9.md

@@ -32,7 +32,7 @@ Everything else associated with the contact is either verified or derived from t
     - one-time prekey: $OPK$ (???? need this?)
 
 ## 2 Account Broadcasting
-- A user is reponsible for broadcasting certain information publicly so that others may contact them.
+- A user is responsible for broadcasting certain information publicly so that others may contact them.
 
 ### 2.1 X3DH Prekey bundles
 - A client [MUST/SHOULD] regenerate a group of X3DH prekey bundles every 24 hours and broadcast them through the appropriate channels