Feature to subscribe based on attachment and tag, instead of just tag.

[VAIBHAVJINDAL3012]

Feature description

In the current setup, clients can subscribe only to tags. Once the client receives all notes corresponding to a subscribed tag, it locally filters out the notes that are actually relevant to it.

This leads to unnecessary bandwidth usage, since the node may send a large number of notes that the client ultimately discards.

Based on the discussion from @bobbinth here:
#2130 (comment)

I think we could support a more sophisticated subscription model where:

• the client subscribes to a note category (represented by the tag), and
• additionally provides filter inputs derived from the attachment data.

Under this model, the node would first match notes by tag, and then apply the attachment-level filters before forwarding notes to the client.

Conceptually, I am thinking about this similarly to how event subscriptions work in the EVM ecosystem:

• tags are analogous to contract addresses, and
• attachments are analogous to emitted event data/topics.

In that sense, clients would subscribe not just to a broad category, but to a filtered event stream, similar to how dapps consume indexed event data through subgraphs or indexing services.

One open question is whether this functionality belongs directly in the node, or whether it should live in a separate indexing sidecar.

A dedicated sidecar/indexer could provide:

• more advanced querying capabilities,
• richer filtering semantics,
• and potentially better scalability for sophisticated subscription patterns.

[igamigo]

A couple of things to note in this:

This leads to unnecessary bandwidth usage, since the node may send a large number of notes that the client ultimately discards.

Unless we implement changes to the sync endpoints in the node, there is no way we can reduce the used bandwidth. I believe the intention in the original comment was to provide filters based exclusively on the client-side (but let me know if I'm wrong).

Generally, I think the mechanisms to do this are (mostly) there on the client already, but they might need higher-level wrappers or helpers. Today, we have the OnNoteReceived trait, which is used by the StateSync struct. This trait has a simple interface comprised of just a callback that gets executed whenever the sync receives a new note,:

#[async_trait(?Send)]
pub trait OnNoteReceived {
    /// Callback that gets executed when a new note is received as part of the sync response.
    ///
    /// It receives:
    ///
    /// - The committed note received from the network.
    /// - An optional note record that corresponds to the state of the note in the network (only if
    ///   the note is public).
    ///
    /// It returns an enum indicating the action to be taken for the received note update. Whether
    /// the note updated should be committed, new public note inserted, or ignored.
    async fn on_note_received(
        &self,
        committed_note: CommittedNote,
        public_note: Option<InputNoteRecord>,
    ) -> Result<NoteUpdateAction, ClientError>;
}

By default, on the client, we place a default implementation of this which detects which notes to keep based on some basic information (e.g., if we can tell that the note is a P2ID meant for an account we don't track, we discard it, otherwise we test consumptions with accounts, etc.). A user could already define an object that does a combination of these checks, but we could improve this in the following ways:

• This callback gets called when the note has already been fully reconstructed. For example, for a public note, this might mean that we received the note inclusion through SyncNotes and we later got the note details through GetNotesById. As explained here, there might be value in quickly screening the note attachments after SyncNotes, as this might incur in more quickly discarding or keeping notes (in a PSWAP scenario, we can derive all the details of a payback note with just an attachment if we know the original note for the order_id). For this, we can add a new on_note_included (a better name is required) that gets called before on_note_received (ie, as soon as the note inclusion arrives) and allows the user to decide these scenarios.
• We can extend the client/StateSync struct to take a list of these dyn OnNoteReceived objects, instead of just one. Then, the user can decide to sync with a list of screeners/filters of their own.
• In general we probably need to expose this better to the Client level: StateSync is completely separate from Client which means you'd need to create one struct, pass the correct filters, sync and then apply the sync to the client's store manually which is not bad but a bit cumbersome.

[VAIBHAVJINDAL3012]

I agree to it, that we already have some check on note received during the sync but I was talking more about the pre-sync. How we can just get those notes from the rpc which are required by us. (For example in the PSWAP case, we only require PSwap notes which are related to us, not all the notes.)

Unless we implement changes to the sync endpoints in the node, there is no way we can reduce the used bandwidth. I believe the intention in the original comment was to provide filters based exclusively on the client-side (but let me know if I'm wrong).

Yes, intention in Bobbin' comment was different, and more toward the client. My point is more on the node, if it possible to do the basic filtering there itself. Yes, change might be required for sync endpoints.

[igamigo]

Yes, intention in Bobbin' comment was different, and more toward the client. My point is more on the node, if it possible to do the basic filtering there itself. Yes, change might be required for sync endpoints.

I think for discussing such changes we might want to open an issue on the node repo itself. I'm not sure such a change is simple or something we want to do overall, but we can discuss requirements and usecases there.

[VAIBHAVJINDAL3012]

I think for discussing such changes we might want to open an issue on the node repo itself.

Yes, I should have raised it in node.

I'm not sure such a change is simple or something we want to do overall, but we can discuss requirements and usecases there.

Yes, agree.