When a "limit": 40 is specified, are relays supposed to return the most recent 40 events?

Reply to this note

Please Login to reply.

Discussion

Are you asking a question on NIP-01?

As far as I've seen, yes. But that's not conclusive.

That’s my understanding yeah. A side-effect of using limit

That's not what your code says, sir:

If I ask for results from 2 pubkeys both nostr-rs-relay and strfry return 40 events from just one of the pubkeys.

If both pubkeys were writing events interspersed in time than I'd consider that an implementation bug.

ah I see what you did there. thank you!!! that is one of the biggest unexpected behaviours!

they just return 40 events in total! not from each!

I think this was fixed in newer strfry's but I have not confirmed. Still running an older version myself.

Indeed, it is fixed on nostr.wine and broken on relay.damus.io

What is your relay?

When making a query with no "limit" set, then this is somewhat fixed for nostr-rs-relay:

But only because it apparently returns everything it has.

Nostream too.

I really don't know how you've been writing clients with these bugs in place. Aren't any of these clients using "limit" with more than one "author"? #[0] this might explain Coracle's problems with the feed showing just super old stuff + live posts that I've complained a lot a while ago.

I agree that would be a bug. The query should sort by time, and show the most recent 40 events taking into account both pubkeys and the age of their respective events. I will try and duplicate it myself.

I would expect most recent 40 results from both keys

Are you sure that one of those pubkeys doesn't have 40 events more recent than the other?

Sorry, this was fake news.

Good question

If there's no since/until then there's assorted ways to interpret ..

1. Find the 40 most recent and return just those (implied until now)

2. Yield the next 40 events received (implied since now)

As a user, seems 40 before now would be most appropriate. Any client needing more specificity should use better filters

Next 40 you could count and then close the channel though.

Ah, ok, according to nip the limit is for not overwhelming the client, so it would also apply to future events if they reach Twitter-like numbers (and beyond). But that should not happen on a single relay?!

No, the limits/since/until only apply to past events. New events should always be emitted (except maybe if they are backdated, but even then I personally would emit them).

How do you determine if something is backdated

That’s what the spec says… So yeah

I recently changed wss://powrelay.xyz to return the highest POW / byte events by default. should I change it back?

It depends, maybe, but I think more important is that you explain what are the rules for powrelay.xyz. I couldn't figure them out myself. I was looking at it the other day and assumed you would only accept events that met some POW threshold, but then since that wasn't written anywhere I just got confused.

🤔 good point. The pow threshold is: 2^target_difficulty / number_of_bytes

The current minimum can be queried with: curl https://powrelay.xyz/min

I'll add something to webpage and the relay metadata description

Gee, I hope so