Nostr Web Client

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.

arkinox 11mo ago

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!

Reply to this note

Please Login to reply.

Discussion

hodlbod 11mo ago

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.