vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update waku.md

This commit is contained in:
Dean Eigenmann 2019-11-25 06:21:53 +01:00 committed by GitHub
parent aedf95d4a1
commit 605e0616b7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 29 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
waku.md
View File

@ -257,11 +257,37 @@ Light nodes are identified by the `light_node` value in the status message.
### Mailserver and client ### Mailserver and client
Mailservers are waku nodes that can archive messages and delivering them to its peers on-demand. Mailservers are waku nodes that can archive messages and delivering them to its peers on-demand. A node which wants to provide mailserver functionality MUST store envelopes from incoming message packets (Waku packet-code 0x01). The envelopes can be stored in any format, however they MUST be serialized and deserialized to the Waku envelope format.
Messages MAY be requested from mailservers by sending a packet with the `p2pRequestCode` code. Once received a mailserver SHOULD respond at some point in the future with packets containing the `p2pMessageCode` code. A mailserver SHOULD store envelopes for all topics to be generally useful for any peer, however for specific use cases it MAY store envelopes for a subset of topics.
<!-- TODO: Clean up vocabulary, is it mailserver and mailserver client? mailclient? mailserver node? historynode? etc --> #### Requesting messages
In order to request historic messages, a node MUST send a packet P2P Request (`0x7e`) to a peer providing mailserver functionality. This packet requires one argument which MUST be a Whisper envelope.
In the Whisper envelope's payload section, there MUST be RLP-encoded information about the details of the request:
```
[ Lower, Upper, Bloom, Limit, Cursor ]
```
`Lower`: 4-byte wide unsigned integer (UNIX time in seconds; oldest requested envelope's creation time)
`Upper`: 4-byte wide unsigned integer (UNIX time in seconds; newest requested envelope's creation time)
`Bloom`: 64-byte wide array of Whisper topics encoded in a bloom filter to filter envelopes
`Limit`: 4-byte wide unsigned integer limiting the number of returned envelopes
`Cursor`: 32-byte wide array of a cursor returned from the previous request (optional)
The `Cursor` field SHOULD be filled in if a number of envelopes between `Lower` and `Upper` is greater than `Limit` so that the requester can send another request using the obtained `Cursor` value. What exactly is in the `Cursor` is up to the implementation. The requester SHOULD NOT use a `Cursor` obtained from one mailserver in a request to another mailserver because the format or the result MAY be different.
The envelope MUST be signed with a symmetric key agreed between the requester and Mailserver.
#### Receiving historic messages
Historic messages MUST be sent to a peer as a packet with a P2P Message code (`0x7f`) followed by an array of Whisper envelopes. It is incompatible with the original Whisper spec (EIP-627) because it allows only a single envelope, however, an array of envelopes is much more performant. In order to stay compatible with EIP-627, a peer receiving historic message MUST handle both cases.
In order to receive historic messages from a mailserver, a node MUST trust the selected mailserver, that is allow to receive packets with the P2P Message code. By default, such packets are discarded.
Received envelopes MUST be passed through the Whisper envelopes pipelines so that they are picked up by registered filters and passed to subscribers.
## Backwards Compatibility ## Backwards Compatibility