The role of Filter among light protocols

[s-tikhomirov]

Starting from the basics: before thinking about incentivization of lightweight protocols (see #21), I want to make sure that I understand how they fit together.

Please correct me if my understanding is wrong. From what I see, we have three light protocols: Lightpush, Store, and Filter. They all describe relationships between a light node (a client) and a full node (let's call it a server). A server is a peer in the P2P Waku network via the Relay protocol. The client wants to communicate with the network but cannot or doesn't want to dedicate the necessary resources for this purpose. Instead, it asks the server to do the heavy lifting.

Fundamentally, there are two things a client may want: to publish a message or to read messages, which are of two flavors: old and fresh (real-time). Hence, we have three protocols. A client asks a server to:

• Lightpush: publish a message;
• Store: provide old messages originally relayed within a specified time frame;
• Filter: provide fresh messages passing a specified filter.

A few things are not completely clear to me though.

First, is Filter only for receiving messages, or also for sending them? The specs say:

Strictly speaking, it is not just doing basic request response, but performs sender push based on receiver intent. While this can be seen as a form of light pub/sub, it is only used between two nodes in a direct fashion. Unlike the Gossip domain, this is meant for light nodes which put a premium on bandwidth. No gossiping takes place.

What does it mean by "a form of light pub/sub"? If this means that a client can also send messages via Filter, why do we need Lightpush?

Second, if Filter can also be used to push messages, would it be correct to say that in the corner case, with a filter that always returns true, Filter is equivalent to Relay? If do, why do we need Filter as a separate protocol, and not just one configuration option for Relay?

[alrevuelta]

we have three light protocols: Lightpush, Store, and Filter

• I would also add peer-exchange. It allows light nodes to use full nodes to "discover" peers.
• Regarding store, guess it can be considered "light" as well, but its a bit different. store can be used between two full nodes to synchronize their db (not implemented by now). But ofc if used by a light node to get past messages, then it can be considered as a light protocol. Note that filter and store are similar, since both allow to fetch messages, but filter has a more real time approach.

First, is Filter only for receiving messages, or also for sending them?

Its only to receive messages. "WakuFilter is a protocol that enables subscribing to messages that a peer receives"

What does it mean by "a form of light pub/sub"? If this means that a client can also send messages via Filter, why do we need Lightpush?

Guess it means that a filter node piggybacks on a full node running gossipsub to receive the messages. Perhaps it would be more accurate to say "a form of light sub".

Naming can be confusing. I actually would rename to:

• filter = light-subscribe
• light-push = light-publish

[s-tikhomirov]

I would also add peer-exchange. It allows light nodes to use full nodes to "discover" peers.

Do full-nodes use it as well? If so, it sounds to me that peer-exchange is not light-node specific.

Thinking about it, what is the definition of full nodes vs light nodes? I branched this question out into #28.

Guess it means that a filter node piggybacks on a full node running gossipsub Naming can be confusing

Indeed it can, considering that the spec uses the term "filter node" to refer to the server in the filter protocol, and you seem to be referring to the client... Some terminology unification could be of great help here (which I hope the whitepaper will help with).

[alrevuelta]

Do full-nodes use it as well? If so, it sounds to me that peer-exchange is not light-node specific.

Full nodes don't use it, but they can provide this service. Light nodes do use it, as client. That's why I think its also a light protocol.

Indeed it can, considering that the spec uses the term "filter node" to refer to the server in the filter protocol, and you seem to be referring to the client

Protocols like filter are req/resp protocols. So they have a client and a server. Eg.

WakuFilterSubscribeCodec = "/vac/waku/filter-subscribe/2.0.0-beta1" WakuFilterPushCodec = "/vac/waku/filter-push/2.0.0-beta1"

Perhaps @jm-clius can help here. Why does filter have a "client" and a "server" protocol, and not store?

[jm-clius]

Why does filter have a "client" and a "server" protocol, and not store?

Since the filter service node needs to setup a libp2p stream to the filter client when pushing messages, which requires mounting an appropriate protocol client side (i.e. Filter is not a simple request-response protocol but requires actions initiated from client side for filter subscriptions and actions initiated from the service node's side for message pushes). For store protocol all interactions happen in simple request-response sequences which only requires mounting a protocol server-side: client initiates connection using protocol-id mounted by Store service node, sends query criteria in a request, and receives matching messages in a response. There is no need for the Store service node to initiate a connection towards the client at any point.

cc @s-tikhomirov @alrevuelta

[s-tikhomirov]

Thank you for the clarification @jm-clius !

So am I right that the key distinction is that Filter is asynchronous? Please let me know if the following summary is correct.

For simple protocols, like Store, a client sends a request and immediately gets a response. The client doesn't have to have its own protocol mounted to do that. In Filter, in contrast, a client subscribes to a particular filter, which results in many responses in the future. To be able to accept those responses, a Filter client needs a client-side protocol mounted.

[jm-clius]

Indeed. Filter works like a Store query, but instead of returning past messages, it returns messages as they arrive in real time (i.e. async).