It's crazy, but there's currently no way to query NIP 52 calendar events by time. I don't know how that slipped past review (and implementation), but I aim to fix it: https://github.com/nostr-protocol/nips/pull/1752
nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpr3mhxue69uhkx7tzv4e8xurpvdjjumn0wd68yvfwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0dehhxarjv4kxjar9wvhx7un89uq3uamnwvaz7tmxv4jkguewdehhxarj9e3xzmny9acx7ur4d3shyqpqarkn0xxxll4llgy9qxkrncn3vc4l69s0dz8ef3zadykcwe7ax3dq5wf4wq nostr:nprofile1qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxthwden5te0wajkccm0d4jjumn0wd68ytnhd9hx2tcqyqnhnu7e7sk8mmsh7rnteh8cn28e6kfdr83mrw7j0mcullg607vdzzvau3h
So the purpose here is the enable querying events by duration?
I must say that geohashes are elegant but using them in nostr is super ugly. I wouldn't consider that pattern something worthy of direct emulation in this nip. But I will also say it might be the only way to do this. Not sure.
Not by duration exactly, but by timeframe. But I think that's what you meant.
The alternative would be potentially to just list the dates the event falls on in YYYY-MM-DD format, but that's basically just a time hash, and introduces the question of timezones. Another alternative would be to have queries like since/until on tags, but that seems unlikely to get adopted at a meaningful rate.
The language about duration here made it confusing
I suggest you mention that timehash is a timeframe and provide an external reference like you did for geohashes. I wasn't familiar with timehashes until this so I had no context for the NIP.
The part I don't like about it is on the client side it's super clunky to query for this stuff since you need to publish a lot of timehash tags and query a lot of timehash tags. It just feels like a hack. But it will probably be a better UX than geohash stuff since it is only 1D and I can't think of a better way to do it! So nice work!
You're right, the duration language is my fault, I'll change that. You haven't heard of timehashes because I invented them 😉
It's actually not too bad to either publish or query these, since if all three recommended levels of granularity exist as tags you can choose which to target with a filter depending on how wide your window is. The degenerate edge case is of course events that last for a long time, since you have to enumerate approximately every hour. I'm not quite sure what to do in that situation.
