filter to not include ids #47

Open
opened 2025-02-13 09:02:35 +13:00 by mikedilger · 3 comments
mikedilger commented 2025-02-13 09:02:35 +13:00 (Migrated from github.com)

When a nostr filter has ids, that restricts to exactly only those events... the rest of the filter would just restrict further but it seems almost pointless in that case. So query by id should be different than query by filter, and filters should not have ids.

When a nostr filter has ids, that restricts to exactly only those events... the rest of the filter would just restrict further but it seems almost pointless in that case. So query by id should be different than query by filter, and filters should not have ids.
mikedilger commented 2025-02-20 13:55:31 +13:00 (Migrated from github.com)

Also we could have per-id results, like auth-required / redacted or not-found on a per-id basis.

Also we could have per-id results, like auth-required / redacted or not-found on a per-id basis.
dluvian commented 2025-06-02 14:14:35 +12:00 (Migrated from github.com)

the rest of the filter would just restrict further but it seems almost pointless in that case.

I disagree. When fetching a single page of a bookmark feed I will use the bookmarked event IDs in the filter and further restrict it with limit to only get the the number of events to fill the page. And if you want the feed ordered by createdAt instead of the order inside the bookmark event you would also use since and until to only get the right timeframe

> the rest of the filter would just restrict further but it seems almost pointless in that case. I disagree. When fetching a single page of a bookmark feed I will use the bookmarked event IDs in the filter and further restrict it with `limit` to only get the the number of events to fill the page. And if you want the feed ordered by `createdAt` instead of the order inside the bookmark event you would also use `since` and `until` to only get the right timeframe
mikedilger commented 2025-06-05 05:26:12 +12:00 (Migrated from github.com)

Thanks for that example.

If you are going to repeatedly query a subset of a larger set, uploading the list of IDs every time seems wasteful. Since relays already have state (AUTH) a connection could keep a set of IDs submitted via some command, and then refer to it in the filter.

Thanks for that example. If you are going to repeatedly query a subset of a larger set, uploading the list of IDs every time seems wasteful. Since relays already have state (AUTH) a connection could keep a set of IDs submitted via some command, and then refer to it in the filter.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mosaic/nostr-next#47
No description provided.