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
I feel like any use of UNTIL that is past current system time should be considered backdated and future events not broadcasted.
How do we determine current system time
NTP? Idk
Certain users in my timeline reliably make posts that my client perceives as “future” by just a few seconds.
Nostr is absolutely not a synchronized protocol, nor does it need to be. I believe the docs encourage for clients to stay within ~10 minutes or something like that.
That said, I think it’s perfectly reasonable not to relay newly created events in real time to my client if I’m filtering UNTIL some date that’s clearly not present time.
Let me wrap my head around this so I'm on the same page..
As the client you're stipulating an until value based on what you perceive to be current time.
The relay may have a different current time, and may interpret your request to be a few seconds into the future.
Id assume (possibly wrongly) that a relay is either going to have a future tolerance for time drift if it has a rule about not yielding events it perceives to be in the future... Or, it's agnostic and keeps the channel open and keeps returning any new events it receives that are dated before the until value the client provided.
My experience calling relays is limited. I was using fiatjaf nostr client written in go and it's relay pool model was keeping connections open pretty much indefinitely. Without rewriting the relay pool to be more relay friendly, I was using it to listen for new events, and then periodically killing the process and reinitializing a new one with an updated since value. In this scenario I got events since that time, and new ones created in the future after my request was started.
