Skip to content
This repository has been archived by the owner on Jun 14, 2024. It is now read-only.

Store protocol hash type and inputs #353

Merged
merged 2 commits into from
Apr 22, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion content/docs/rfcs/13/README.md
Original file line number Diff line number Diff line change
@@ -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)).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that index comparison is done on both timestamp and digest. Does this mean that digest clashes are expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aight, with timestamp as well we should be fine then, thanks!

- `receivedTime`: the UNIX time at which the waku message is received by the node running the `13/WAKU2-STORE` protocol.

### PagingInfo