Nostr Web Client

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

Reply to this note

Please Login to reply.

Discussion

Terry Yiu 11mo ago

You’re right. We missed it. Thanks for iterating on the spec.

hodlbod 11mo ago

It only took me two implementations of my own to notice. Maybe it's because there are so few events out there that clients can afford to just download them all? It never occurred to me before.

Terry Yiu 11mo ago

Yeah, I just downloaded everything and filtered locally on Comingle. But that won’t scale. It’s also interesting that we’re forced to use hashes because we can’t make relays query with greater than / less than filters.

hodlbod 11mo ago

Yeah, that was my first impulse, but no. Which I think is ok, it's interesting to see how far we can get with data format design instead of database features.

arkinox 11mo ago

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.

hodlbod 11mo ago

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!

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.

fiatjaf 11mo ago

Good catch, and the timehashes are very nice and a great solution. I'm very happy that this time no one has decided to fix the issue by attempting to turn relays into MongoDB.

arkinox 11mo ago

Why are you like this 😂