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.

Reply to this note

Please Login to reply.

Discussion

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

https://github.com/nostr-protocol/nips/pull/1752/files#diff-4907ffede99f12eecbdfdc7f6815d38fa44d8bdf6a13eee2bd161bbf6097a70cR32

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.