bug: get_waku_v2_relay_v1_messages return an array has payload instead of expected hex string

[fryorcraken]

Problem

get_waku_v2_relay_v1_messages returns an array of decimal number in payload instead of the expected hex string defined in https://rfc.vac.dev/spec/16/#get_waku_v2_relay_v1_messages

Impact

Minor defect, just unexpected as an implementer.

To reproduce

1. Ensure the node receives some messages over relay

2. JSON RPC call:

 get_waku_v2_relay_v1_messages [ '/waku/2/default-waku/proto' ]
```

JSON RPC Response:

```
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": [
    {
      "payload": [
        76,
        105,
        103,
        104,
        116,
        32,
        80,
        117,
        115,
        104,
        32,
        119,
        111,
        114,
        107,
        115,
        33
      ],
      "contentTopic": "/test/1/waku-light-push/utf8",
      "version": 0,
      "timestamp": 1662821422291000000,
      "proof": {
        ...
      }
    }
  ]
}
```

### Expected behavior

`payload` is a hex string.

### nwaku version/commit hash

`v0.11`

[fryorcraken]

Odd, the crypto API returns hex:

RPC Query:  get_waku_v2_private_v1_asymmetric_messages [
  '/waku/2/default-waku/proto',
  '0xf604e5439d1df44b2f07153d14cc2d2f960997fa3672733309cb6ecbb33eea34'
] 
 {"jsonrpc":"2.0","id":1,"result":[{"payload":"0x546869732069732061206d657373616765204920616d20676f696e6720746f20656e6372797074","contentTopic":"/test/1/waku-message/utf8","timestamp":1662825744753000000}]} +4ms

[fryorcraken]

@richard-ramos I have witnessed the same behaviour on go-waku

[richard-ramos]

@fryorcraken in go-waku I added this behavior to match nwaku's. Otherwise Go would have encoded the byte array as base64 (which is what it's used in REST API)

[rymnc]

Upon some investigation,

• get_waku_v2_relay_v1_messages does not serialize the WakuMessage for the response

• get_waku_v2_private_v1_asymmetric_messages makes use of this function which applies the conversion

• The REST API has a few helper functions for this - https://github.com/status-im/nwaku/blob/7f23bdf29fc60d89a3ec1d2f759e8bc037122833/waku/v2/node/rest/relay/relay_api.nim#L156-L175

[jm-clius]

@fryorcraken @richard-ramos is it worth getting a fix in nwaku (and parity in the other clients)? Although the JSON-RPC API is going to be deprecated, we have to maintain it while still being used.

[fryorcraken]

IMHO, it'd be cleaner but now that I deal with it, I am not fussed:

https://github.com/waku-org/js-waku/blob/5bab85f93f22f853f0d2d07d134b8c5d0d4a93f1/src/test_utils/nwaku.ts#L316

@dao any thoughts on the matter as you use the JSON RPC API?

[dao]

IMHO, it'd be cleaner but now that I deal with it, I am not fussed:

https://github.com/waku-org/js-waku/blob/5bab85f93f22f853f0d2d07d134b8c5d0d4a93f1/src/test_utils/nwaku.ts#L316

@dao any thoughts on the matter as you use the JSON RPC API?

I vote for consistency - easy enough for us to make this change once

[jm-clius]

@rymnc this is not priority. Given your involvement with RLN, should we unassign you here and move this item to a backlog?

[rymnc]

Unassigned, although I would suggest to leave it in Todo since there are quite a few consumers of the json-rpc api, as @LNSD suggested. Will leave it up to you to decide though!

[LNSD]

As @richard-ramos commented above, the efficient way to serialize the messages' payload is to use base64 encoding.

I am assigning this issue to me, as I think it is feasible to fix this as part of v0.15.0.