hoytech/strfry

Feature request: NIP-45 Event Count

arthurfranca opened this issue · 7 comments

arthurfranca commented

NIP-45 Event Count would be great to reduce relay/client bandwidth usage when counting reactions and replies (instead of, for each thread, client having to request and download many events just to count them client-side). Specially considering the inter-relay sync capabilities of strfry that could enable more accurate counts.

I've never used lmdb so don't know how hard it would be to add event count support. If there is speed problems, maybe doing a regular db event fetch up to a limit such as 200 events and counting relay-side would already be great. Even if it effectively caps counts to 200, currently most threads don't have that much engagement.

hoytech commented

This is on my TODO list, I'm hoping to do it for next release. Thanks for making the ticket so I can track this.

Counting is not a problem -- it needs to be able to work with arbitrary queries so I'll just have it run them. The implicit limit can probably be higher than a regular REQ (500) too, since counting is cheaper than actually forming and sending a response.

As you probably know, using this for counting reactions is not necessarily reliable. If you query 2 relays and they both report 100 reactions, then the actual number of reactions could be anywhere between 100 (event sets are identical) or 200 (event sets are entirely disjoint).

  • 👍1
arthurfranca commented

Nice!

As you probably know, using this for counting reactions is not necessarily reliable.

Yes. It may not be a big problem if using NIP-65 becomes widespread as clients are supposed to use original event author's read relays to publish reactions. So I would expect these relays to have a good percentage of all reactions to an specific event.

Also I think users don't care much about exact numbers and may just want to know if the event has enough engagement to be considered potentially interesting enough to click on.

jb55 commented

looks like nip45 is getting removed nostr-protocol/nips#842

  • 😕1
arthurfranca commented

I think (and hope) it won't get removed cause COUNT is useful.

The proposed DVM alternative is a bad idea imo cause it is the same as a client downloading all events of interest just to count them client-side, but it would be the DVM doing it instead of the client.

  • 👍1
hoytech commented

Yeah, I saw that. Now I don't know what to do :)

Negentropy is actually somewhat useful for this: You can sync the set of IDs across many relays, without downloading the full events (or even duplicated version of the IDs in many cases). This can actually be useful for a "cross-relay" count. I'm going to write more on this shortly.

  • 👍1
dskvr commented

Why not have a more generalized NIP for relay-ops so that relay operators can do w/e they want to do and just expose available ops via NIP-11 or a different document.

['OP', 'COUNT', '{...params}']

nip11 { ...
  supported_ops: {
     'COUNT': {
        auth_required: false,
        params: {
          filter: "a REQ filter"
        },
        returns: {
          type: "number" //json types only ofc 
        }
     }
  }
}

people would complain, but it's only a possibility, nobody is forced to use it, nor is anyone forced to implement it

antonioconselheiro commented

Can please include to reply COUNT with CLOSED instead NOTICE while it's not supported?
soapbox-pub/nostrify#3

  • 👍1