Updates pagination logic by replacing receiver timestamp with the sender timestamp (#417)

* adds description of paging using sender timestamp

* updates rfc, brings back receiver timestamp

* brings back the receiver timestamp

* renames sender timestamp

* adds discussion about the use of robust timestamp and different usecases of receiver and sender time

* link to open timestamp

* adjusts spacing

* sembr

* minor

* rewording and rephrasing

* formatting

* formatting

* applies comments

* explains attack by an example

* fixes a wrong ts value

* aligns paragraphs

content/docs/rfcs/13/README.md

@@ -53,7 +53,8 @@ syntax = "proto3";
 
 message Index {
   bytes digest = 1;
-  double receivedTime = 2;
+  double receiverTime = 2;
+  double senderTime = 3;
 }
 
 message PagingInfo {
@@ -95,7 +96,8 @@ message HistoryRPC {
 To perform pagination, each `WakuMessage` stored at a node running the `13/WAKU2-STORE` protocol is associated with a unique `Index` that encapsulates the following parts. 
 - `digest`:  a sequence of bytes representing the SHA256 hash of a `WakuMessage`.
   The hash is computed over the concatenation of `contentTopic` and `payload` fields of a `WakuMessage` (see [14/WAKU2-MESSAGE](/spec/14)).
-- `receivedTime`: the UNIX time at which the waku message is received by the node running the `13/WAKU2-STORE` protocol.
+- `receiverTime`: the UNIX time at which the waku message is received by the receiving node.
+- `senderTime`: the UNIX time at which the waku message is generated by its sender.
 
 ### PagingInfo
 
@@ -122,7 +124,13 @@ RPC call to query historical messages.
   Leaving this field empty means no filter on the content topic of message history is required.
   This field SHOULD be left empty in order to retrieve historical waku messages regardless of their content topics.
 - `PagingInfo` holds the information required for pagination.  Its `pageSize` field indicates the number of  `WakuMessage`s to be included in the corresponding `HistoryResponse`. If the `pageSize` is zero then no pagination is required. If the `pageSize` exceeds a threshold then the threshold value shall be used instead. In the forward pagination request, the `messages` field of the `HistoryResponse` shall contain at maximum the `pageSize` amount of waku messages whose `Index` values are larger than the given `cursor` (and vise versa for the backward pagination). Note that the `cursor` of a `HistoryQuery` may be empty (e.g., for the initial query), as such, and depending on whether the  `direction` is `BACKWARD` or `FORWARD`  the last or the first `pageSize` waku messages shall be returned, respectively.
-The queried node MUST sort the `WakuMessage`s based on their `Index`, where the `receivedTime` constitutes the most significant part and the `digest` comes next, and then perform pagination on the sorted result. As such, the retrieved page contains an ordered list of `WakuMessage`s from the oldest message to the most recent one.
+The queried node MUST sort the `WakuMessage`s based on their `Index`, where the `senderTime` constitutes the most significant part and the `digest` comes next, and then perform pagination on the sorted result. 
+As such, the retrieved page contains an ordered list of `WakuMessage`s from the oldest message to the most recent one.
+
+Alternatively, the `receiverTime` (instead of `senderTime` ) MAY be used to sort `WakuMessage`s during the paging process. 
+However, we RECOMMEND the use of the `senderTime` for sorting as it is invariant and consistent across all the nodes.
+This has the benefit of `cursor` reusability i.e., a `cursor` obtained from one node can be consistently used to query from another node.
+However, this `cursor` reusability  does not hold when the `receiverTime` is utilized as the receiver time is affected by the network delay and nodes' clock asynchrony.
 
 ### HistoryResponse
 
@@ -150,7 +158,26 @@ However, one can consider preserving anonymity through one of the following ways
   <!-- TODO: add a reference for PSIs? --> <!-- TODO: more techniques to be included --> 
 <!-- TODO: Censorship resistant: this is about a node that hides the historical messages from other nodes. This attack is not included in the specs since it does not fit the passive adversarial model (the attacker needs to deviate from the store protocol).-->
 
+- **Robust and verifiable timestamps**: Messages timestamp is a way to show that the message existed prior to some point in time. However, the lack of timestamp verifiability can create room for a range of attacks, including injecting messages with invalid timestamps pointing to the far future.   
+To better understand the attack, consider a store node whose current clock shows `2021-01-01 00:00:30` (and assume all the other nodes have a synchronized clocks +-20seconds).
+The store node already has a list of messages `(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20)` that are sorted based on their timestamp.  
+An attacker sends a message with an arbitrary large timestamp e.g., 10 hours ahead of the correct clock `(m',2021-01-01 10:00:30)`. 
+The store node places `m'` at the end of the list `(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20), (m',2021-01-01 10:00:30)`. 
+Now another message arrives with a valid timestamp e.g., `(m11, 2021-01-01 00:00:45)`. However, since its timestamp precedes the malicious message `m'`, it gets placed before `m'` in the list i.e.,  `(m1,2021-01-01 00:00:00), (m2,2021-01-01 00:00:01), ..., (m10:2021-01-01 00:00:20), (m11, 2021-01-01 00:00:45), (m',2021-01-01 10:00:30)`.
+In fact, for the next 10 hours, `m'` will always be considered as the most recent message and served as the last message to the querying nodes irrespective of how many other messages arrive afterward. 
+
+  A robust and verifiable timestamp allows the receiver of a message to verify that a message has been generated prior to the claimed timestamp. 
+One solution is the use of [open timestamps](https://opentimestamps.org/) e.g.,  block height in Blockchain-based timestamps. 
+That is, messages contain the most recent block height perceived by their senders at the time of message generation. 
+This proves accuracy within a range of minutes (e.g., in Bitcoin blockchain) or seconds (e.g., in Ethereum 2.0) from the time of origination. 
+
+# References
+1. [Open timestamps](https://opentimestamps.org/) 
+   
 # Copyright
 
 Copyright and related rights waived via
 [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+
+