Nostr devs: Wouldn't it be very useful for caching if relays sent their timestamp next to events? How are you calculating since in REQs otherwise? #asknostr
Discussion
What timestamp do you need? Current time? 🤔
Yes, time in which the relay responded with an event
Take current time and in 99.99999999999999% of cases it’s the same as the server. Servers don’t usually drift unless something is very broken, at which point it doesn’t really matter
Since = Timestamp (not the created at) of the last event downloaded after the EOSE (in the live section of the subscription).
This is interesting. Timestamp as in local timestamp when that post-EOSE event arrived? Aren't there discrepancies/timezone issues between client and event signing times?
Clarification: I'm sending a REQ with a `#d` set of app IDs to check for updates.
But I can't include one `since` for each app ID in one query, so I have two options:
- use the oldest `created_at` of the app ID set - but if one of the apps is quite old, I reap almost no caching benefit
- send one filter per app - this would work well, but I could have potentially 100s of apps to check which translates into 100s of backend requests for one check
If the relay sent a timestamp, I could use that as the `since` for the next request. The only drawback is it wouldn't catch any back-dated apps, but that is uncommon.
There is no discrepancy. Most apps need to be in sync with NTP just to use the regular web. It works quite well for amethyst.
Nice. Are all created_at supposed to be in UTC?
No need to convert timezones. Your unix Timestamp and the servers Timestamp are the same regardless where you are.