feat: amending computeDigest func. + related test cases

[ABresting]

Description

Amending the computeDigest function to add pubSubTopic as a function parameter, will help introduce a new messageHash attribute. The corresponding queue driver code is updated to accommodate the amended function.

Amending the existing test cases that use the older version of the computeDigest function.

Changes

• computeDigest function amended
• related existing test cases amended
• queue driver code adjusted to the new change

Issue

#2112

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2132

Built from 414d10a

[vpavlin]

If I am not mistaken, this does not really change the DB schema or how messages are stored or searched for. It may result in some duplicate messages being stored after the node upgrades - as the unique index values will change for the same message after upgrade, but that should not be a problem.

Thanks for updating the tests!

LGTM

[alrevuelta]

lgtm.

I actually dont understant why the pubsub topic wasnt part of the digest if the RFC specifies so: https://rfc.vac.dev/spec/14/#deterministic-message-hashing

And related in case you want to have a look. Seems we have two hashed, one mainly used for store (the one you modified) and one for relay defaultMessageIdProvider. Wondering if we should unify both.

nwaku/waku/waku_relay/message_id.nim

Lines 31 to 37 in 459331e

	proc defaultMessageIdProvider*(message: messages.Message): Result[MessageID, ValidationResult] =
	let hash = sha256.digest(message.data)
	ok(@(hash.data))
	## Waku message Unique ID provider
	# TODO: Add here the MUID provider once `meta` field RFC PR is merged

[ABresting]

If I am not mistaken, this does not really change the DB schema or how messages are stored or searched for. It may result in some duplicate messages being stored after the node upgrades - as the unique index values will change for the same message after upgrade, but that should not be a problem.

The schema is going to be changed, we aim to replace id attribute to the messageHash attribute this will improve the storage and searching of messages. The schema change code I will push today as it was suggested by Ivan to push changes incrementally based on some layer that they impact, such as Queue driver, SQLite, Postgres, today I will push SQLite related changes.

Thanks for updating the tests!

LGTM

[ABresting]

lgtm.

I actually dont understant why the pubsub topic wasnt part of the digest if the RFC specifies so: https://rfc.vac.dev/spec/14/#deterministic-message-hashing

And related in case you want to have a look. Seems we have two hashed, one mainly used for store (the one you modified) and one for relay defaultMessageIdProvider. Wondering if we should unify both.

nwaku/waku/waku_relay/message_id.nim

Lines 31 to 37 in 459331e

	proc defaultMessageIdProvider*(message: messages.Message): Result[MessageID, ValidationResult] =
	let hash = sha256.digest(message.data)
	ok(@(hash.data))
	## Waku message Unique ID provider
	# TODO: Add here the MUID provider once `meta` field RFC PR is merged

AFAIK, the messageID or id attribute will be replaced by messageHash, i.e. the way messageID is computed is being changed along with it's name. Indeed, we add pubSubTopic inside the hash as referred by this rfc