test(rln-relay): rpc handler to support waku rln relay

[rymnc]

• Modifies the endpoint post_waku_v2_relay_v1_message so that when rln is enabled in the node the proof is included automatically in the message that is published.
• Before this PR, it wasn't possible to publish messages containing RLN proofs via the RLN.

[alrevuelta]

should we modify the rpc endpoint post_waku_v2_relay_v1_message to include something like useRln? The behaviour would be:

• If useRln=true but rln is not enabled in the node, return error.
• If useRln=true and rln is enabled in the node, publish the msg including an rln proof
• If useRln=false do not include the rln proof (legacy behaviour)

would also require changing the spec

[vpavlin]

Would this introduce unnecessary level of complexity? As in if the node has RLN membership info configured and RLN relay enabled, always attach the proof, otherwise, do not

Is there particular reason/need for not sending proof when RLN is enabled on the node?

[rymnc]

I think it's to maintain slight backwards compatibility

…

On Mon, Aug 7, 2023, 20:38 Vaclav Pavlin ***@***.***> wrote: Would this introduce unnecessary level of complexity? As in if the node has RLN membership info configured and RLN relay enabled, always attach the proof, otherwise, do not Is there particular reason/need for not sending proof when RLN is enabled on the node? — Reply to this email directly, view it on GitHub <#1852 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKNQ6FDSFRENCTEW2NJRTKLXUEAIRANCNFSM6AAAAAA2LKV2J4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alrevuelta]

@vpavlin yeap agree with the complexity here. The main reason for adding this complexity would be to have always the same input, same output. Without the useRln we have different behavours for the same input.

But well, as an advocate of simplicity im actually leaning towards your suggestion. Same api call but proof is attached or not depending on how the node is configured.

[jm-clius]

Unless there's some hidden complexity, my suggestion would be to leave the API untouched and simply attach proof based on whether node is RLN-configured/compiled or not.

[Ivansete-status]

I agree with @vpavlin's suggestion.
On the other hand, should we do that in the REST handler? I thought we were moving out from rpc and the idea is to only have REST.

[alrevuelta]

@rymnc Seems we have quorum. Mind rebasing and implementing the changes? Ideally we can have it for the REST api but I'm fine with leaving it for another PR.

Thanks!

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:1852

[vpavlin]

Will the appendRLNProof print out any more specific error log? This seems to be too ambiguous for users to know what is going on:)

[rymnc]

I agree, we're working on it on the zerokit side where we return an error enum atleast so the error code is known

[vpavlin]

lgtm, just one comment/question