NIP-41: Add places -- geohash ladder addressable locations (kind - 37515) #2074
Conversation
|
LGTM
|
Wouldn't it be a different business if the license / business id changed? |
|
Are you a different person because you renewed your passport and got a new number? :) Companies frequently update their underlying registration. |
|
I'm more saying if a business id / permit is the underlying identifier, wouldn't it make sense to create another event if it changes / undergoes new management / etc? I'm not saying I'm right, I'm trying to reason out when it would make sense to create a new event as opposed to updating the old one. |
|
I would only use it if whatever you are attaching to it is attached to the registration (like other legal documents). Otherwise, you would have 5 Apples, 3 Teslas, 15 Oracles in your DB and people will need to figure out which one is the latest one. |
|
Right that makes sense. I guess, ultimately, the d tag is up to the creator. In clients, stressing the importance of the naddr seems like a priority. I use an example of displaying 30300 events on a map and then using the naddr to look at a specific place. |
|
I know that @arkin0x has done some work on geohashes, including location events, maybe you should look at that spec and see if it works for you? |
The only NIP I'm seeing for location events is the calendar related one -- NIP-52. The NIP I'm proposing is unique for the geohash ladder aspect, where relays without search functionality work by default with interactive maps. I show a working example in it. |
|
You might be able to reverse engineer this: https://go.yondar.me/dashboard |
|
He's doing the exact same thing with the geohash ladder... wish he had created a NIP for it. I wonder if it makes sense for me to keep this NIP but modify the kind to match his? |
|
It's probably not a big deal either way, but if you can make it compatible I'd do that. I just realized I never submitted some comments from my review the other day, so submitting those now. |
41.md
Outdated
| - `["image", "<absolute url>"]` — cover image | ||
| - `["phone", "<E.164 or human>"]` | ||
| - `["addr", "<street>", "<city>", "<region>", "<postal>", "<country>"]` | ||
| - `["t", "<type>", ...]` — freeform type tags (e.g., `business`, `rv_park`, `restaurant`, `accepts_btc`) used to reduce results for usecase |
There was a problem hiding this comment.
This is probably ok, but hashtags are semantically different from labels. NIP 32 l/L tags might be better here
There was a problem hiding this comment.
So my thought here is to be able to filter specific types because this nip is for general physical locations. It seems realistic to only want to see rv parks for example.
There was a problem hiding this comment.
Right, which is more what labels are for. Hashtags are more like #independencedayrvcampout, rather than categorization if you think about how people naturally use them. But it's fine if you prefer t.
There was a problem hiding this comment.
Is there a better indexable character for this usecase?
There was a problem hiding this comment.
c for "category" has been used once or twice. The problem with categories is they imply hierarchy, while labeling implies subjectivity and multiplicity. Is there something you don't like about l?
There was a problem hiding this comment.
Misunderstood what you said about 'l'. Seems the most appropriate so I'll switch it.
btcjt
changed the title
agreed
Is there a reason to make it an indexable field? I'm not sure. I'm using 'r' for the recommended relay now, which seems to be the popular consensus. I'm using a "website"tag for the website now. Same thing with "phone".
Okay I'll do this since you and Vitor seem to agree. |
|
Maybe I misunderstood the purpose of |
|
|
The kinds will need to change again. 37515 and others in that range have to do with geocaching. The https://go.yondar.me/ project @staab mentioned seems to be abandoned, so I'm not too worried about conforming to the existing physical location types. |
|
This one? https://nostrhub.io/naddr1qvzqqqrcvypzppscgyy746fhmrt0nq955z6xmf80pkvrat0yq0hpknqtd00z8z68qqgkwet0vdskx6rfdenj6etkv4h8guc6gs5y5 I only see 37516 there. But picking a new kind is also fine. |
|
I think this might be ready unless you guys think otherwise. What do I do now? |
You can just wait for adoption. Once we have a good number of clients using this as is we can merge. |
3 participants
No description provided.