</code></pre></div></div><p><codeclass="language-plaintext highlighter-rouge">Lower</code>: 4-byte wide unsigned integer (UNIX time in seconds; oldest requested envelope’s creation time)<br/><codeclass="language-plaintext highlighter-rouge">Upper</code>: 4-byte wide unsigned integer (UNIX time in seconds; newest requested envelope’s creation time)<br/><codeclass="language-plaintext highlighter-rouge">Bloom</code>: 64-byte wide array of Waku topics encoded in a bloom filter to filter envelopes<br/><codeclass="language-plaintext highlighter-rouge">Limit</code>: 4-byte wide unsigned integer limiting the number of returned envelopes<br/><codeclass="language-plaintext highlighter-rouge">Cursor</code>: an array of a cursor returned from the previous request (optional)</p><p>The <codeclass="language-plaintext highlighter-rouge">Cursor</code> field SHOULD be filled in if a number of envelopes between <codeclass="language-plaintext highlighter-rouge">Lower</code> and <codeclass="language-plaintext highlighter-rouge">Upper</code> is greater than <codeclass="language-plaintext highlighter-rouge">Limit</code> so that the requester can send another request using the obtained <codeclass="language-plaintext highlighter-rouge">Cursor</code> value. What exactly is in the <codeclass="language-plaintext highlighter-rouge">Cursor</code> is up to the implementation. The requester SHOULD NOT use a <codeclass="language-plaintext highlighter-rouge">Cursor</code> obtained from one <codeclass="language-plaintext highlighter-rouge">Mailserver</code> in a request to another <codeclass="language-plaintext highlighter-rouge">Mailserver</code> because the format or the result MAY be different.</p><p>The envelope MUST be encrypted with a symmetric key agreed between the requester and the <codeclass="language-plaintext highlighter-rouge">Mailserver</code>.</p><h3id="receiving-historic-messages"><ahref="#receiving-historic-messages"class="anchor-heading"aria-labelledby="receiving-historic-messages"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Receiving historic messages </h3><p>Historic messages MUST be sent to a peer as a packet with a P2P Message code (<codeclass="language-plaintext highlighter-rouge">0x7f</code>) followed by an array of Waku envelopes.</p><p>In order to receive historic messages from a <codeclass="language-plaintext highlighter-rouge">Mailserver</code>, a node MUST trust the selected <codeclass="language-plaintext highlighter-rouge">Mailserver</code>, that is allowed to send packets with the P2P Message code. By default, the node discards such packets.</p><p>Received envelopes MUST be passed through the Waku envelope pipelines so that they are picked up by registered filters and passed to subscribers.</p><p>For a requester, to know that all messages have been sent by a <codeclass="language-plaintext highlighter-rouge">Mailserver</code>, it SHOULD handle P2P Request Complete code (<codeclass="language-plaintext highlighter-rouge">0x7d</code>). This code is followed by the following parameters:</p><divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>[ RequestID, LastEnvelopeHash, Cursor ]
</code></pre></div></div><ul><li><codeclass="language-plaintext highlighter-rouge">RequestID</code>: 32-byte wide array with a Keccak-256 hash of the envelope containing the original request</li><li><codeclass="language-plaintext highlighter-rouge">LastEnvelopeHash</code>: 32-byte wide array with a Keccak-256 hash of the last sent envelope for the request</li><li><codeclass="language-plaintext highlighter-rouge">Cursor</code>: an array of a cursor returned from the previous request (optional)</li></ul><p>If <codeclass="language-plaintext highlighter-rouge">Cursor</code> is not empty, it means that not all messages were sent due to the set <codeclass="language-plaintext highlighter-rouge">Limit</code> in the request. One or more consecutive requests MAY be sent with <codeclass="language-plaintext highlighter-rouge">Cursor</code> field filled in order to receive the rest of the messages.</p><h2id="security-considerations"><ahref="#security-considerations"class="anchor-heading"aria-labelledby="security-considerations"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Security considerations </h2><h3id="confidentiality"><ahref="#confidentiality"class="anchor-heading"aria-labelledby="confidentiality"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Confidentiality </h3><p>The node encrypts all Waku envelopes. A <codeclass="language-plaintext highlighter-rouge">Mailserver</code> node can not inspect their contents.</p><h3id="altruistic-and-centralized-operator-risk"><ahref="#altruistic-and-centralized-operator-risk"class="anchor-heading"aria-labelledby="altruistic-and-centralized-operator-risk"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Altruistic and centralized operator risk </h3><p>In order to be useful, a <codeclass="language-plaintext highlighter-rouge">Mailserver</code> SHOULD be online most of time. That means users either have to be a bit tech-savvy to run their own node, or rely on someone else to run it for them.</p><p>Currently, one of Status’s legal entities provides <codeclass="language-plaintext highlighter-rouge">Mailservers</code> in an altruistic manner, but this is suboptimal from a decentralization, continuance and risk point of view. Coming up with a better system for this is ongoing research.</p><p>A Status client SHOULD allow the <codeclass="language-plaintext highlighter-rouge">Mailserver</code> selection to be customizable.</p><h3id="privacy-concerns"><ahref="#privacy-concerns"class="anchor-heading"aria-labelledby="privacy-concerns"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Privacy concerns </h3><p>In order to use a <codeclass="language-plaintext highlighter-rouge">Mailserver</code>, a given node needs to connect to it directly, i.e. add the <codeclass="language-plaintext highlighter-rouge">Mailserver</code> as its peer and mark it as trusted. This means that the <codeclass="language-plaintext highlighter-rouge">Mailserver</code> is able to send direct p2p messages to the node instead of broadcasting them. Effectively, it will have access to the bloom filter of topics that the user is interested in, when it is online as well as many metadata like IP address.</p><h3id="denial-of-service"><ahref="#denial-of-service"class="anchor-heading"aria-labelledby="denial-of-service"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Denial-of-service </h3><p>Since a <codeclass="language-plaintext highlighter-rouge">Mailserver</code> is delivering expired envelopes and has a direct TCP connection with the recipient, the recipient is vulnerable to DoS attacks from a malicious <codeclass="language-plaintext highlighter-rouge">Mailserver</code> node.</p><h2id="changelog"><ahref="#changelog"class="anchor-heading"aria-labelledby="changelog"><svgviewBox="0 0 16 16"aria-hidden="true"><usexlink:href="#svg-link"></use></svg></a> Changelog </h2><h3id=
