Store protocol hash type and inputs #353
Conversation
| @@ -89,7 +89,8 @@ message HistoryRPC { | |||
| ### Index | |||
|
|
|||
| 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 hash of a `WakuMessage`. | |||
| - `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)). | |||
There was a problem hiding this comment.
What happens if we have another message with same contentTopic and payload but different topic or timestamp?
E.g. if I write "hello" in payload field at three different times over the same contentTopic
There was a problem hiding this comment.
I know that index comparison is done on both timestamp and digest. Does this mean that digest clashes are expected?
There was a problem hiding this comment.
What happens if we have another message with same contentTopic and payload but different topic or timestamp?
E.g. if I write "hello" in payload field at three different times over the same contentTopic
@oskarth
afaik, in the current implementation we are using one pubsub topic, right?
But if there would be more than one pubsub topic, then the two waku messages despite being published on distinct pubsub topics will be considered identical and will result in the same hash. But, it does not mean that only one of them gets to live! they both get stored. The hash output is only for the sake of pagination.
Also recall that we also make use of timestamp (not in the digest computation) to resolve ties. Timestamp is part of the index of a waku message and has a higher priority in the comparison of indexed waku messages than the message digest.
Does this mean that digest clashes are expected?
@jm-clius
Yes, that is true for messages with identical payload and content topic. But the timestamp part would resolve the tie.
There was a problem hiding this comment.
Aight, with timestamp as well we should be fine then, thanks!
Closes #301.
Also, specifies the inputs to the hash function for the computation of message digest.