16/WAKU2-RPC: Inconsistencies and inaccuracies in RFC spec

[jm-clius]

Problem

There are some inconsistencies between the RFC and the main implementation in nwaku.

• The KeyPair fields are called in privateKey and publicKey in the RFC, but seckey and pubkey in the implementation.
• WakuMessage payload is defined as a hex-encoded data string in the RFC, but returned as an array of uint8 in the implementation.
• The Private API get methods (e.g. this one) must explicitly indicate that messages that can't be decrypted with the provided key will be discarded.
• The Private API must define encrypt/decrypt methods to allow applications to use multiple keys to encrypt or attempt decryption of received, encrypted messages.

Suggested solution:

• Change the implementation to reflect privateKey and publicKey as the field names for KeyPair.
• Change the specification to indicate that WakuMessage payload is an array of uint8 rather than a hex-encoded data string. This is currently a limitation of the implementation. Note that WakuMessage is only received in responses, while WakuRelayMessage, used in requests, do indeed contain a hex-encoded payload.

cc @richard-ramos

[richard-ramos]

For the specs for both get_waku_v2_private_v1_asymmetric_messages and get_waku_v2_private_v1_symmetric_messages, it should be clarified that messages that can't be decrypted with the provided keys will be ignored and discarded.

[jimstir]

Issue has been moved to here