nostr-protocol
Add timehashes to nip 52
This does the same thing for timestamps as geohashes does for locations. There's likely a better way to accomplish the task, so feel suggestions on the code snippets and algorithm are welcome.
Thinking through this more (thank you @arkin0x), there are degenerate scenarios in which long-duration events require many high-granularity hashes. This case can't be solved by only using lower-granularity hashes, because clients using high-granularity hashes in requests will no longer be able to find those events, and lower-granularity hashes force them to download and filter everything.
So I decided that the simplest thing to do is just pick a granularity and use it. As it happens one day is probably a pretty good balance for most use cases. Date-only events already have that information (and are timezone-agnostic anyway), so I only had to add the tag to datetime events.
@tyiu @arkin0x
So if you want all events happening this Friday, you can look them up with the "D" tag and it will include week-long events including Friday. Sounds good to me.
So if I wanted to get all the events for the next month, I would have to include ~30 D-tags in the subscription filter?
How about this
// Start timehashes
["T", "dy"],
["T", "dyj"],
["T", "dyju"],
// End timehashes
["D", "dy"],
["D", "dyj"],
["D", "dyju"],
So if I wanted to get all the events for the next month, I would have to include ~30 D-tags in the subscription filter?
Yes. Not that bad if you compare it to the authors field.
How about this
This isn't terrible, but it doesn't allow targeting hashes during but not at the end or start of the event. You'd still have to scan backwards and forwards to get a complete list of events.
I feels like a W with the timestamp / seconds in a week should also be added.
I'd say the same for a month (given that it is one of the main calendar views), but the varying number of days in a month breaks this scheme :(
But with W you can probably get all the events in 5 filter tags.
Adding week/month would be ok. A simple way to handle it is to call a month 30 days and just do floor(now() / 30 * DAYS) to calculate it.
Chiming in to say that I implemented this solution here
It really helps when making calendar apps! Happy I found this while perusing the code for Flotilla, +1 for merging
