Waku Filter and Lightpush: Evaluation and improvement

[jm-clius]

Background

This forms part of a series of issues raised as output of the recent Status client offsite.

Filter and Lightpush are useful protocols for resource-restricted devices. Although these protocols are separate they are often used in conjunction as an alternative to relay. For example, they are core to an initial strategy to address Waku Relay scalability challenges in browsers and similarly restricted environments.

What has been done

• Basic development and implementation of these protocols, fixes to get this working on multiple clients, interclient tests, integration into testnets/toychat, etc.
• A roadmap for improvements to the protocol that we believe necessary.

Problem

Although there's ongoing work to improve these protocols, both the protocols and various client implementations must be properly dogfooded and evaluated against the following open questions:

• both of these protocols implies significant anonymity and privacy tradeoffs. There’s ongoing work to provide different options and mitigations here (each coming again with another set of tradeoffs).
• what is the scalability of these protocols? Neither protocol has been integrated into proper dogfooding efforts yet.
• how urgent/critical are the proposed improvements on the roadmap? What have we missed in this roadmap?

This issue tracks the overarching effort to dogfood and improve both protocols, both on a spec and implementation level across all clients.

[jm-clius]

An idea from @richard-ramos: waku-org/nwaku#1423

[fryorcraken]

@jm-clius can this be closed?

[jm-clius]

Yes, although dogfooding is still in progress, initial feedback has been good and the implementation seems stable.