Payload differs when ECIES is used with lightpush

[vpavlin]

This is a bug report

Problem

When you use ECIES createEncoder from message-encryption package and publish via Lightpush, the message is encrypted for each peer, which results in different payload for each lighpush peer (because randomness is part of encryption https://github.com/waku-org/js-waku/blob/master/packages/message-encryption/src/crypto/ecies.ts#L128)

This is problematic because it wastes resources on encrypting multiple time and it also means differen message hash, so it is harder to deduplicate.

Proposed Solutions

Not sure:)

Notes

[weboko]

The problems that are mentioned:

• wastes resources on encrypting multiple time;
• differen message hash;
• harder to deduplicate;

Multiple time encryption - seems to be a minor problem but a good follow up.
Different message hash - isn't it anyway the problem when message sent to different peers as each will have it's own proof?

Harder to deduplicate - this one shouldn't be a problem for js-waku as I think we are catching duplicates just fine in our SDK level Filter subscription implementation.
This comes problematic when we talk about js-waku <-> go-waku communication. As to address that I think we need to align SDK implementations so that they are more or less compatible in that regard and provide similar toolchains.

We can try to pin point such places and follow up with particular fixes so that in our case I believe we need to align message deduplication for js-waku and go-waku. Is it the case @vpavlin ?

[weboko]

Moving back to triage as we are figuring criteria for this task.

[vpavlin]

Yeah, I guess it makes sense to tie this to other client SDKs - I would not focus on go-waku, since it is going away anyway, so we need to match this with nwaku in the future.

But no need to prioritize probably