From f77dd07d22b88325a9c671a995369974ccdc142c Mon Sep 17 00:00:00 2001 From: Dean Eigenmann Date: Tue, 27 Aug 2019 11:34:42 +0200 Subject: [PATCH 1/9] Update x8.md --- x8.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/x8.md b/x8.md index 321a47a..543ecf8 100644 --- a/x8.md +++ b/x8.md @@ -12,23 +12,21 @@ updated: - [Encoding](#Encoding) - [Upgradability](#Upgradability) -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 messaging but also cases described in [Status Whitepaper](https://status.im/whitepaper.pdf) as well as various clients created using vastly different technologies. +This specification describes how the payload of each message in the Status Protocol looks. # Wrapper Payloads are wrapped in a [protobuf record](https://developers.google.com/protocol-buffers/) record: -``` - message StatusProtocolMessage { - bytes signature = 1; - bytes payload = 2; - } +```protobuf +message StatusProtocolMessage { + bytes signature = 1; + bytes payload = 2; +} ``` -Where `signature` is the bytes of the signed `SHA3-256` of the payload, signed with +`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 its considered plausibly deniable. From 01d9455c4672f373e6c9cef10ddfef3284b63ddb Mon Sep 17 00:00:00 2001 From: Dean Eigenmann Date: Tue, 27 Aug 2019 13:26:21 +0200 Subject: [PATCH 2/9] Update x8.md --- x8.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/x8.md b/x8.md index 543ecf8..e97d15a 100644 --- a/x8.md +++ b/x8.md @@ -26,8 +26,7 @@ message StatusProtocolMessage { } ``` -`signature` is the bytes of the signed `SHA3-256` of the payload, signed with -the key of the author of the message. +`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 its considered plausibly deniable. @@ -55,11 +54,11 @@ For more details regarding serialization and deserialization please consult [tra The type `Message` represents a text message exchanged between clients. -- [Payload](###Payload) -- [Content types](###Content-types) -- [Message types](###Message-types) -- [Clock vs Timestamp and message ordering](###Clock-vs-Timestamp-and-message-ordering) -- [Replies](###Replies) +- [Payload](#payload) +- [Content types](#content-types) +- [Message types](#message-types) +- [Clock vs Timestamp and message ordering](#clock-vs-timestamp-and-message-ordering) +- [Replies](#replies) ### Payload From 4e9a44a3e0406d0d5fe7b08d353a7f06b08c4e30 Mon Sep 17 00:00:00 2001 From: Dean Eigenmann Date: Tue, 27 Aug 2019 13:33:02 +0200 Subject: [PATCH 3/9] Update x8.md --- x8.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/x8.md b/x8.md index e97d15a..010b569 100644 --- a/x8.md +++ b/x8.md @@ -8,9 +8,9 @@ created: 2019-04-22 updated: --- -- [Wrapper](#Wrapper) -- [Encoding](#Encoding) -- [Upgradability](#Upgradability) +- [Wrapper](#wrapper) +- [Encoding](#encoding) +- [Upgradability](#upgradability) This specification describes how the payload of each message in the Status Protocol looks. From 8f0144cbe94fdf2901b42496054fef17407e9aea Mon Sep 17 00:00:00 2001 From: Dean Eigenmann Date: Tue, 27 Aug 2019 13:38:09 +0200 Subject: [PATCH 4/9] Update x8.md --- x8.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/x8.md b/x8.md index 010b569..da655fe 100644 --- a/x8.md +++ b/x8.md @@ -32,7 +32,7 @@ If a signature is not present but an author is provided by a layer below, the me # Encoding -The payload is encoded using [Transit format](https://github.com/cognitect/transit-format). It is a text-based format so even encoded version is easily readable by humans. Transit was chosen over JSON in order to reduce the bandwidth. +The payload is encoded using [Transit format](https://github.com/cognitect/transit-format). Transit was chosen over JSON in order to reduce the bandwidth. Example of a valid encoded payload: @@ -48,7 +48,7 @@ For more details regarding serialization and deserialization please consult [tra # Message types -- [Message](##Message) +- [Message](#message) ## Message From ef348611699ceb36c3bb8249b11509e7441abd3e Mon Sep 17 00:00:00 2001 From: Dean Eigenmann Date: Tue, 27 Aug 2019 13:41:25 +0200 Subject: [PATCH 5/9] Update x8.md --- x8.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/x8.md b/x8.md index da655fe..ea780c9 100644 --- a/x8.md +++ b/x8.md @@ -63,13 +63,15 @@ 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 important): -1. text `string` -2. content type `enum` (more in [Content types](#content-types)) -3. message type `enum` (more in [Message types](#message-types)) -4. clock `int64` -5. timestamp `int64` -6. content `struct { chat-id string, text string }` +| Field | Name | Type | +| ----- | ---- | ---- | +| 1 | text | `string` | +| 2 | content type | `enum` (more in [Content types](#content-types)) | +| 3 | message type | `enum` (more in [Message types](#message-types)) | +| 4 | clock | `int64` | +| 5 | timestamp | `int64` | +| 6 | content | `struct { chat-id string, text string }` | ### Content types From 1cfecbb2764cf6d879aa8e7b77793a4651e22475 Mon Sep 17 00:00:00 2001 From: decanus Date: Mon, 26 Aug 2019 15:33:09 +0200 Subject: [PATCH 6/9] spelling --- x5.md | 50 ++++++++---------- x7.md | 165 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ x8.md | 2 + 3 files changed, 190 insertions(+), 27 deletions(-) diff --git a/x5.md b/x5.md index 21668cd..cfe97d3 100644 --- a/x5.md +++ b/x5.md @@ -21,35 +21,31 @@ TODO: Something briefly on adversary model, i.e. https://code.briarproject.org/b TODO: Elaborate on section of requirements below Security properties -- Network MitM Prevented -- Operator MitM Prevented -- Operator MitM Detected -- Operator Accountability -- Key Revocation Possible -- Privacy Preserving -- Usability - -
+Network MitM Prevented +Operator MitM Prevented +Operator MitM Detected +Operator Accountability +Key Revocation Possible +Privacy Preserving +Usability -- Automatic Key Initialization -- Low Key Maintenance -- Easy Key Discovery -- Easy Key Recovery -- In-Band -- No Shared Secrets -- Alert-less Key Renewal -- Immediate Enrollment -- Inattentive User Resistant -- Adoptability - -
+Automatic Key Initialization +Low Key Maintenance +Easy Key Discovery +Easy Key Recovery +In-Band +No Shared Secrets +Alert-less Key Renewal +Immediate Enrollment +Inattentive User Resistant +Adoptability -- Multiple Key Support -- No Service Provider -- No Auditing Required -- No Name Squatting -- Asynchronous -- Scalable +Multiple Key Support +No Service Provider +No Auditing Required +No Name Squatting +Asynchronous +Scalable NOTE: Several of these we don't do, and e.g. ENS/multikey stuff can be noted as future enhancement diff --git a/x7.md b/x7.md index 62cc085..5018f06 100644 --- a/x7.md +++ b/x7.md @@ -307,7 +307,172 @@ This evaluates Whisper as a standalone protocol. However, we also note common us - [EIP-627, aka Whisper v6](https://eips.ethereum.org/EIPS/eip-627) - [Whisper PoC 2 spec (more motivation)](https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec) +<<<<<<< HEAD +======= +### --- Privacy + +#### Sender Anonymity (PARTIAL) +> When a chat message is received, no non-global entities except for the sender can determine which entity produced the message. + +- Generally speaking, a peer can't tell if a neighbor is the message originator. + +- 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 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. + +- Using a mix format would partially mitigate this, e.g. [Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) + +- Moot account + - All messages are signed by (identity) private key that can be generated at will, which provides pseudonymity. The Moot account is a shared key. The more people that use it, the larger the anonymity set is. + - potential for hard coding it into app for increasing its anonymity set + +#### Recipient Anonymity (YES) +> No non-global entities except the receiver of a chat message know which entity received it. + +- One caveat is that if you listen to too specialized topics you might give up too much information. This is a trade-off with bandwidth consumption. + +- 1:1 chats are currently under one topic, but will be partitioned (somehow) + - ask Roman [IGOR: partitioning was implemented, a few topics are generated from each user's public keys] + +- We are working with an optional ACK message to verify receipt of message + * [IGOR] only from mailservers + +- The various types of chat we provide right now are: + - 1:1 chat + - Private group chat + - Public chats + +- 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. + +#### Participant Anonymity (YES) +> No non-global entities except the conversation participants can discover which set of network nodes are engaged in a conversation + +- See Conversation Security + +#### Unlinkability (YES) + +> No non-global entities except the conversation participants can discover that two protocol messages belong to the same conversation. + +- Since it is broadcast based, there's no unique recipient. + +- (This might change depending on topic usage). + +#### 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 above mentioned eclipse-like attack. + +### --- Usability + +#### Contact Discovery (YES) + +> The system provides a mechanism for discovering contact information. + +- A "contact" identifier in Whisper is a public-key. You can get this via a few methods + - out of band + - in-band in a public chat + - ENS naming scheme + +- Assuming you have a public key, you can contact them. + +##### Notes +For a mixnet based approach, see e.g. https://github.com/w3f/messaging/issues/22 + +#### No Message Delays (YES) +> No long message delays are incurred. + +- No real time communication but assuming reasonable node connectivity the number of relays is a low constant. + +#### No Message Drops (NO) +> No Message Drops: Dropped messages are retransmitted. + +- Whisper messages have a TTL + +- With Whisper mailserver extensions expired messages can be received through a direct TCP connection over some timeframe. + +#### Easy Initialization (YES) +> The user does not need to perform any significant tasks before starting to communicate. + +- True. + +#### No Fees Required (YES) +> The scheme does not require monetary fees to be used. + +- True. + +[Igor: how does that matches with Network Incentivization? Woudn't it break this?] + +### --- Adoption + +#### Topology independent (YES) +> No network topology is imposed on the conversation security or trust establishment schemes + +- The topology has no impact on the security of the network + +##### Notes +-https://github.com/w3f/messaging/issues/12 + + +#### No Additional Services (YES*) +> The architecture does not depend on availability of any infrastructure beyond the chat participants. + +- Technically nothing breaks if only the participants are relaying Whisper messages, but some of the security assumptions are based on a broader userbase + +#### Spam/Flood Resistant (PARTIAL) +> The availability of the system is resistant to denial-of-service attacks and bulk messaging + +- Proof of work produces a nonce based on payload and TTL. However, this doesn't take heterogenerous devices into account. + +- For Status this is a NO since PoW is set arbitrarily low. + +#### Low Storage (NO) +> The system does not require a large amount of storage capacity for any entity + +- Entities receive messages they don't "need". However, there's no requirement for individual nodes to keep messages or write to disk. + +- Storage requirement of entire network of N nodes for M messages can be up to M*TTL*N. + +#### Low Bandwidth (NO) +> The system does not require a large amount of bandwidth usage for any entity. + +- You receive messages you don't need, by relaying, also redundantly. + +- It's a flood-like network. + +- Use of bloom filters and partial relaying (light mode of operation) reduces this somewhat, at the expense of weaker privacy guarantees. + +##### Notes + +- Compare redundant messages in Whisper vs PSS: https://status.im/research/whisper_pss.html + +#### Low Computation (NO) +> The system does not require a large amount of processing power for any entity + +- Must attempt to decrypt every message received on the network, also must provide PoW to send + +#### Asynchronous (NO) +> Messages sent to recipients who are offline will be delivered when the recipient reconnects, even if the sender has since disconnected. + +- There's a TTL for each message. + +- As an extension, there's a Whisper mailserver that resend messages on demand to trusted peers. However, this happens outside of the normal Whisper transport through a direct TCP connection. [Andrea: I am not sure this is accurate, first whisper uses TCP and direct connections to any peer (through devp2p). the request happens at the devp2p channel, which is the one whisper uses to communicate, and the sending of envelopes is not much different from other peers, although this envelopes are different (might be expired, but we accept them as the peer is trusted), but the mailserver is a peer (although a trusted one) Dshulyak can help out to confirm, but it seems that the point is debatable] + +#### Scalable (NO) +> The amount of resources required to maintain system availability scales linearly with the number of users. + +- It's :whale: worse than linear, as every additional user must carry the load of all other users. + +- The trade-off of partitioning the network is losing security around dark routing of messages. + +- This trade-off appears suboptimal. + +- Peer steering: https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec +>>>>>>> 2256f28... spelling diff --git a/x8.md b/x8.md index ea780c9..319e97a 100644 --- a/x8.md +++ b/x8.md @@ -14,6 +14,8 @@ updated: This specification describes how the payload of each message in the Status Protocol looks. +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 Payloads are wrapped in a [protobuf record](https://developers.google.com/protocol-buffers/) From 507ecb4edd236a2b4f94b92a3207b9e70ada5689 Mon Sep 17 00:00:00 2001 From: Oskar Thoren Date: Tue, 27 Aug 2019 14:22:50 +0200 Subject: [PATCH 7/9] add todo inline --- x8.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/x8.md b/x8.md index 319e97a..0a98124 100644 --- a/x8.md +++ b/x8.md @@ -66,6 +66,8 @@ The type `Message` represents a text message exchanged between clients. Payload is a struct (a compound data type) with the following fields (order is important): + + | Field | Name | Type | | ----- | ---- | ---- | | 1 | text | `string` | From 0fbd17349a65f28328615265d104705fee0ff12e Mon Sep 17 00:00:00 2001 From: Oskar Thoren Date: Tue, 27 Aug 2019 14:24:00 +0200 Subject: [PATCH 8/9] rename file --- README.md | 2 +- x8.md => status-payloads-spec.md | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename x8.md => status-payloads-spec.md (100%) diff --git a/README.md b/README.md index 92a3b57..d19c517 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ Drafts are prepended with x to indicate that they aren't accepted yet. | x5 | [Initial Trust Establishment Specification](x5.md) | | x6 | [Initial Conversational Security Specification](x6.md) | | x7 | [Initial Transport Privacy through Whisper Specification](x7.md) | -| x8 | [Initial Message Payload Specification Specification](x8.md) | +| x8 | [Initial Message Payload Specification Specification](status-payloads-spec.md) | | x9 | [Status Account Creation and Maintenance Specification](x9.md) | ## Protocol Research diff --git a/x8.md b/status-payloads-spec.md similarity index 100% rename from x8.md rename to status-payloads-spec.md From d84fdb8e709ab38e6d7b23a8277b52bab56fb514 Mon Sep 17 00:00:00 2001 From: Oskar Thoren Date: Tue, 27 Aug 2019 14:31:03 +0200 Subject: [PATCH 9/9] unfuck merge conflict --- x5.md | 50 ++++++++++-------- x7.md | 165 ---------------------------------------------------------- 2 files changed, 27 insertions(+), 188 deletions(-) diff --git a/x5.md b/x5.md index cfe97d3..21668cd 100644 --- a/x5.md +++ b/x5.md @@ -21,31 +21,35 @@ TODO: Something briefly on adversary model, i.e. https://code.briarproject.org/b TODO: Elaborate on section of requirements below Security properties -Network MitM Prevented -Operator MitM Prevented -Operator MitM Detected -Operator Accountability -Key Revocation Possible -Privacy Preserving -Usability +- Network MitM Prevented +- Operator MitM Prevented +- Operator MitM Detected +- Operator Accountability +- Key Revocation Possible +- Privacy Preserving +- Usability + +
-Automatic Key Initialization -Low Key Maintenance -Easy Key Discovery -Easy Key Recovery -In-Band -No Shared Secrets -Alert-less Key Renewal -Immediate Enrollment -Inattentive User Resistant -Adoptability +- Automatic Key Initialization +- Low Key Maintenance +- Easy Key Discovery +- Easy Key Recovery +- In-Band +- No Shared Secrets +- Alert-less Key Renewal +- Immediate Enrollment +- Inattentive User Resistant +- Adoptability + +
-Multiple Key Support -No Service Provider -No Auditing Required -No Name Squatting -Asynchronous -Scalable +- Multiple Key Support +- No Service Provider +- No Auditing Required +- No Name Squatting +- Asynchronous +- Scalable NOTE: Several of these we don't do, and e.g. ENS/multikey stuff can be noted as future enhancement diff --git a/x7.md b/x7.md index 5018f06..62cc085 100644 --- a/x7.md +++ b/x7.md @@ -307,172 +307,7 @@ This evaluates Whisper as a standalone protocol. However, we also note common us - [EIP-627, aka Whisper v6](https://eips.ethereum.org/EIPS/eip-627) - [Whisper PoC 2 spec (more motivation)](https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec) -<<<<<<< HEAD -======= -### --- Privacy - -#### Sender Anonymity (PARTIAL) -> When a chat message is received, no non-global entities except for the sender can determine which entity produced the message. - -- Generally speaking, a peer can't tell if a neighbor is the message originator. - -- 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 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. - -- Using a mix format would partially mitigate this, e.g. [Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) - -- Moot account - - All messages are signed by (identity) private key that can be generated at will, which provides pseudonymity. The Moot account is a shared key. The more people that use it, the larger the anonymity set is. - - potential for hard coding it into app for increasing its anonymity set - -#### Recipient Anonymity (YES) -> No non-global entities except the receiver of a chat message know which entity received it. - -- One caveat is that if you listen to too specialized topics you might give up too much information. This is a trade-off with bandwidth consumption. - -- 1:1 chats are currently under one topic, but will be partitioned (somehow) - - ask Roman [IGOR: partitioning was implemented, a few topics are generated from each user's public keys] - -- We are working with an optional ACK message to verify receipt of message - * [IGOR] only from mailservers - -- The various types of chat we provide right now are: - - 1:1 chat - - Private group chat - - Public chats - -- 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. - -#### Participant Anonymity (YES) -> No non-global entities except the conversation participants can discover which set of network nodes are engaged in a conversation - -- See Conversation Security - -#### Unlinkability (YES) - -> No non-global entities except the conversation participants can discover that two protocol messages belong to the same conversation. - -- Since it is broadcast based, there's no unique recipient. - -- (This might change depending on topic usage). - -#### 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 above mentioned eclipse-like attack. - -### --- Usability - -#### Contact Discovery (YES) - -> The system provides a mechanism for discovering contact information. - -- A "contact" identifier in Whisper is a public-key. You can get this via a few methods - - out of band - - in-band in a public chat - - ENS naming scheme - -- Assuming you have a public key, you can contact them. - -##### Notes -For a mixnet based approach, see e.g. https://github.com/w3f/messaging/issues/22 - -#### No Message Delays (YES) -> No long message delays are incurred. - -- No real time communication but assuming reasonable node connectivity the number of relays is a low constant. - -#### No Message Drops (NO) -> No Message Drops: Dropped messages are retransmitted. - -- Whisper messages have a TTL - -- With Whisper mailserver extensions expired messages can be received through a direct TCP connection over some timeframe. - -#### Easy Initialization (YES) -> The user does not need to perform any significant tasks before starting to communicate. - -- True. - -#### No Fees Required (YES) -> The scheme does not require monetary fees to be used. - -- True. - -[Igor: how does that matches with Network Incentivization? Woudn't it break this?] - -### --- Adoption - -#### Topology independent (YES) -> No network topology is imposed on the conversation security or trust establishment schemes - -- The topology has no impact on the security of the network - -##### Notes --https://github.com/w3f/messaging/issues/12 - - -#### No Additional Services (YES*) -> The architecture does not depend on availability of any infrastructure beyond the chat participants. - -- Technically nothing breaks if only the participants are relaying Whisper messages, but some of the security assumptions are based on a broader userbase - -#### Spam/Flood Resistant (PARTIAL) -> The availability of the system is resistant to denial-of-service attacks and bulk messaging - -- Proof of work produces a nonce based on payload and TTL. However, this doesn't take heterogenerous devices into account. - -- For Status this is a NO since PoW is set arbitrarily low. - -#### Low Storage (NO) -> The system does not require a large amount of storage capacity for any entity - -- Entities receive messages they don't "need". However, there's no requirement for individual nodes to keep messages or write to disk. - -- Storage requirement of entire network of N nodes for M messages can be up to M*TTL*N. - -#### Low Bandwidth (NO) -> The system does not require a large amount of bandwidth usage for any entity. - -- You receive messages you don't need, by relaying, also redundantly. - -- It's a flood-like network. - -- Use of bloom filters and partial relaying (light mode of operation) reduces this somewhat, at the expense of weaker privacy guarantees. - -##### Notes - -- Compare redundant messages in Whisper vs PSS: https://status.im/research/whisper_pss.html - -#### Low Computation (NO) -> The system does not require a large amount of processing power for any entity - -- Must attempt to decrypt every message received on the network, also must provide PoW to send - -#### Asynchronous (NO) -> Messages sent to recipients who are offline will be delivered when the recipient reconnects, even if the sender has since disconnected. - -- There's a TTL for each message. - -- As an extension, there's a Whisper mailserver that resend messages on demand to trusted peers. However, this happens outside of the normal Whisper transport through a direct TCP connection. [Andrea: I am not sure this is accurate, first whisper uses TCP and direct connections to any peer (through devp2p). the request happens at the devp2p channel, which is the one whisper uses to communicate, and the sending of envelopes is not much different from other peers, although this envelopes are different (might be expired, but we accept them as the peer is trusted), but the mailserver is a peer (although a trusted one) Dshulyak can help out to confirm, but it seems that the point is debatable] - -#### Scalable (NO) -> The amount of resources required to maintain system availability scales linearly with the number of users. - -- It's :whale: worse than linear, as every additional user must carry the load of all other users. - -- The trade-off of partitioning the network is losing security around dark routing of messages. - -- This trade-off appears suboptimal. - -- Peer steering: https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec ->>>>>>> 2256f28... spelling