Nostr Web Client

NIPS needed:

1) "select: ['id']" filter so you only get matching event ids and not the full event 10 times. You can then ask only 1 node for the full event, or skip if you already have it.

2) Bloom filter for "I already have these events, don't send them". Can be resource intensive on the relay side and not usable in all queries.

3) Follow distance filter for authors, so you don't get irrelevant spam. Iris discards stuff from unknown authors on the client side, but would be better if they weren't sent and processed in the first place. Shouldn't be difficult to implement with some SQL wizardry.

Mike Dilger ☑️ 2y ago

I like these ideas.

1. I think the 'select' filter isn't really a filter (selecting which events) it is requesting a different kind of result so it should probably be a new REQID message (IMHO).

2. Bloom filters are interesting. strfry is using merkle trees, presumably to see which branches need refreshing... but I'm not sure how applicable that is to a much smaller set of IDs or how it compares to bloom filters.

3. I'm not sure we can presume a relay has everybody's contact lists and can compute a follow distance. Maybe some relays could specialize in doing that though. Clients probably need to have a concept of which relays are "aggregators". All kinds of aggregations like this, reaction counts, how many followers someone has, it all depends on a relay having all that data which I suspect over time will be a less and less accurate assumption for general relays as people move off the central crowded relays.

Reply to this note

Please Login to reply.

Discussion

Sirius 2y ago

One option is a bloom filter of authors. It's not good for history queries, but for new events it would be useful. 10k authors from your social graph with 1% false positive rate would be around 12 KB. Would limit incoming spam nicely.

Mike Dilger ☑️ 2y ago

👍