A node which wants to provide history node functionality MUST store envelopes from incoming Messages 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.
A history node 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.
In order to request historic envelopes, a node MUST send a packet P2P Request (`0x7e`) to a peer providing history node functionality. This packet requires one argument which MUST be a Waku envelope.
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 history node in a request to another history node because the format or the result MAY be different.
If `Topics` is used the `Cursor` field MUST be specified for the argument order to be unambiguous. However, it MAY be set to `null`. `Topics` is used to specify which topics a node is interested in. If `Topics` is not empty, a history node MUST only send envelopes that belong to a topic from `Topics` list and `Bloom` value MUST be ignored.
Historic envelopes MUST be sent to a peer as a packet with a P2P Message code (`0x7f`) followed by an array of Waku envelopes. A history node MUST limit the amount of messages sent, either by the `Limit` specified in the request or limited to the maximum [RLPx packet size](./waku#maximum-packet-size), whichever limit comes first.
In order to receive historic envelopes from a history node, a node MUST trust the selected history node, that is allow to receive expired packets with the P2P Message code. By default, such packets are discarded.
For a requester, to know that all envelopes have been sent by history node, it SHOULD handle P2P Request Complete code (`0x7d`). This code is followed by a list with:
If `Cursor` is not empty, it means that not all envelopes were sent due to the set `Limit` in the request. One or more consecutive requests MAY be sent with `Cursor` field filled in in order to receive the rest of the envelopes.
There are several security considerations to take into account when running or interacting with History nodes. Chief among them are: scalability, DDoS-resistance and privacy.
A history node client has to trust a history node, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP).
A history node has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning history node can overwhelm an individual node.
