nostr-protocol
NIP-41: Add places -- geohash ladder addressable locations (kind - 33000)
LGTM
d should be a UUID because the license/business id may change over time.
LGTM
dshould be a UUID because the license/business id may change over time.
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.
map individual place using naddr
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?
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.
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.
Looks pretty good, I still think:
* `l` > `t`
agreed
* `i` > `r`
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".
* `d` should be a random ID
Okay I'll do this since you and Vitor seem to agree.
Maybe I misunderstood the purpose of r, I was thinking you were referring to an external resource, but it looks like a relay hint for comments or something? That should probably be spelled out in the NIP, otherwise implementers will probably use the outbox model instead (which is probably fine, since location events are owned by the author, and should follow them around, while relays built in to the event will get stale). I would just remove r entirely.
I would just remove r entirely. Yeah I think I got confused with the website stuff and 'r'.
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?
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.