Problem

The current Filter implementation has a few gaps:

Dev Ex

• library consumers are more used to an event-based approach for subscription-like implementations
  • await filter.subscribe(xyz, callback) works can be improved as it unintuitive to use await in a scenario like such
  • filter.subscribe.addEventListener(xyz) feels more intuitive

Readability and Maintainability

• the implementation has logic like

  js-waku/packages/core/src/lib/filter/index.ts

  Line 417 in 1ec0c20

  const decodedMessage = await Promise.any(decodePromises);

  and

  js-waku/packages/core/src/lib/filter/index.ts

  Line 151 in 1ec0c20

  this.subscriptionCallbacks.set(contentTopic, subscriptionCallback);

  that can be improved where we store the decoder, per content topic, and don't need to store callbacks and are able to dispatch the decoded message

Proposed Solutions

API:

  const subscription = await waku.filter.createSubscription(decoders);
  
  subscription.addEventListener(
        createKeyFromDecoder(decoder),
        (evt) => {
         const decodedMessage = evt.detail;
         }
      );

which users are more familiar with.

Along with that, improvements like:

• separate Filter and Subscription files
• takes in decoders on Filter.createSubscription() and calls it internally to avoid an extra step
• use event emitters for Subscription

Notes

• PR addressing this issue: chore: refactor Filter to an event-based API #1682
• related to bug: align filter subscribe to relay behavior #1678 and dev ex