Subnostr

Added support for "not" filter to Iris. It adds filter { not: { ids: alreadyHave }} to all queries in order to avoid downloading events that you already have locally. It's only sent to relays that support nip 113 (which I haven't written yet).

https://github.com/irislib/iris-snort/blob/d359f3123abb4a1ff08b41e70501a8c985df9775/packages/system/src/query-manager.ts#L130

Also implemented it in nostr-rs-relay, although haven't tested with a real database yet: https://github.com/mmalmi/nostr-rs-relay/commit/55eb916123006f1ca9ca7b4bb107e69deac3579d

If you're connected to 10 relays and query them sequentially, adding alreadyHave to each request you might save up to 90% in bandwidth by not getting the same events 10 times.

However, I started thinking if it would make more sense to just implement negentropy in the browser and nostr-rs-relay. It's more efficient sync, but more difficult to implement.

I think { not: { ids: alreadyHave }} might be the main use case for the not filter. One consideration is that the "not" part might be so large that you need to discard it on the relay after eose.

Any other use cases for not filter? Maybe excluding muted authors from a global query, but not sure if worth it.

nobody 2y ago

It’s brilliant to have a PoC implementation before writing a spec.

Have you measured the average size of these “not” messages vs a standard query? They’re bound to be smaller than pulling the messages (obviously) but one thing to consider is data transfer speeds tend to be highly asymmetric, with uploads being 10x slower or more. Something to consider.

It also means running hundreds or thousands of comparison operations on the server per user - it’ll be interesting to see how server CPU usage on relays is affected. Ngentropy does seem more efficient in that regard since it’s binary search.

I look forward to seeing developments. I volunteer to run a public test relay with your fork if that would help at any point.

Reply to this note

Please Login to reply.

Discussion

No replies yet.