Support attachment-based filtering in SyncNotes (tag + attachment subscriptions)

[VAIBHAVJINDAL3012]

Summary

Today a client can only subscribe to note tags. The node returns every note in a
block range matching a subscribed tag, and the client filters locally — discarding notes
it doesn't need. This wastes bandwidth: the node ships notes the client immediately
throws away.

Proposal: let a client subscribe to a tag plus an attachment filter. The node
matches by tag (as today), then applies the attachment filter, and forwards only what
passes both. Tag stays the coarse category; attachment becomes an indexed, filterable
topic.

Based on rust-sdk#2209

Background

Tags are coarse and collision-prone (a truncated prefix), so many unrelated notes share
one. A particular client has to download all the notes for the particular tag and filter it out itself.

Motivating case: PSWAP

A PSWAP chain shares one constant tag across all descendants. Under tag-only
subscription, a creator receives everyone's partial fills for that asset pair, then
keeps only the serials matching their own chain. But the discriminating data is already
in the attachment (P2ID fill_amount at slot 0), and the creator can derive exactly
which note ids / attachment words are theirs. An attachment filter lets the node drop
everyone else's traffic before it leaves the server. Pairs naturally with
#2157 (plain-word attachments the node can
filter on directly).

Analogy: EVM logs

tag ≈ contract address · attachment ≈ indexed topics · {tag, attachment_filter} ≈
{address, topics}. A filtered event stream instead of "everything from this contract".

Open questions

• Node vs. sidecar — node owns cheap exact-match; a dedicated indexer owns richer
  queries and scaling. Where's the line?

[Mirko-von-Leipzig]

There is a reason tags are coarse - privacy. If we go with this proposal privacy gets diluted iiuc.

That said, the tag approach predates attachments so perhaps this is now.. different somehow?

cc @bobbinth @PhilippGackstatter

[VAIBHAVJINDAL3012]

There is a reason tags are coarse - privacy. If we go with this proposal privacy gets diluted iiuc.

But attachment is already public for both private and public notes. Giving the filter over it, doesn't have any affect on privacy if I am getting your point correct.

[Mirko-von-Leipzig]

There is a reason tags are coarse - privacy. If we go with this proposal privacy gets diluted iiuc.

But attachment is already public for both private and public notes. Giving the filter over it, doesn't have any affect on privacy if I am getting your point correct.

afaiu the privacy is more that the node operator shouldn't actually know what data your client is directly interested in. As in, its not chain privacy but rather finderprinting your client, but maybe I've always misunderstood.

[VAIBHAVJINDAL3012]

I might have different opinion on it. The data which is available to node operator is already public. If we see from other angle too, we can have see this filtering service as subgraph. Subgraph operator would listen to all the notes from the node operator, then index them and users can query it as per their convenience.

[Mirko-von-Leipzig]

I might have different opinion on it. The data which is available to node operator is already public.

Only the chain data itself is public. What is hidden is which account these notes are being consumed which is why tag filtering is reduced to 16 bits instead of just specifying the exact tag precisely. The operator can deduce this by fingerprinting the client's account(s) and the notes they download.

The idea is that clients can hide which specific tag/notes they are interested in by only specifying 16 bits of the tag, thus obscuring the precise tag. In the future, clients can specify more (or less) than 16 bits depending on the level of privacy they are interested in versus data consumption.

This proposal adds another layer of filtering, and thus must be considered on the same privacy axis. e.g. this is equivalent to increasing the precision of the tag filter. In this light, we could consider this another optional decision by the client. Less privacy by opting into these filters.

To me the question is whether we should include this at all, because clients may not consider this fingerprinting aspect.

[VAIBHAVJINDAL3012]

The idea is that clients can hide which specific tag/notes they are interested in by only specifying 16 bits of the tag, thus obscuring the precise tag. In the future, clients can specify more (or less) than 16 bits depending on the level of privacy they are interested in versus data consumption.

Got your point, so you mean IP level privacy.