NIP-XX Places #927
NIP-XX Places #927
Conversation
|
I didn't see any mention of dealing with place squatters, is that something that you foresee with events like these or is it possible to create two places events for the same physical location and allow the market to sort of coalesce around the "right" one? |
|
The NIP is well written and the examples are actually useful. One suggestion: You could further clarify (at least it was not apparent to me): How to handle osm and schema.org values that are objects? Also you should maybe elaborate (maybe here is enough don't know if it needs to be in the NIP) Why do you want to integrate vocabularies like OSM and schema.org/Place and namespaces you don't even know yet in the NIP and why can't the appropriate attributes be all defined in the NIP? |
|
Looks good. The only weird part is this I'd be careful with the references to pubkeys "owning" places. Many people can own the same place. I don't know how to identify the actual owner of the place. |
I imagined that the solution to this is about the same as the solution to multiple pubkeys claiming to be the same person. You need to discern the legit pubkey, and NIP-05 can help. If you follow the real pubkey, you'll see the real place on a map of your contacts/friends. In cases where there isn't a single owner, or the owner isn't on nostr, this discernment can be aided by reviews, proof-of-work, social graph reputation, likes, or any number of ways. So, yes coalesce, but using mechanisms of the nostr protocol. However, I'm open to the idea that a kind 1754 event could have a tag that says "this Place is a duplicate of this other Place". These kinds of reports could be made and clients could interpret this. Some clients could have a "related Place" section in the Place details and list the real Place for others to find it easier. Interpreting these reports could be up to the client. |
I've addressed this with 3404f89
I've received a lot of feedback privately and in the Yondar telegram group that OpenStreetMaps ought to be compatible with whatever geospatial solution we create for nostr. Indeed, OSM is a very large, very active, and very high quality data set that can be leveraged to bring high quality Place data to nostr, and perhaps even bring nostr data to OSM when appropriate. OSM uses a "folksonomy" approach to applying attributes to geospatial data. The result is something akin to "the wild west". There are conventions that everyone tends to follow with surprising consistency, but anything goes. From https://taginfo.openstreetmap.org If you take a moment to digest the wide variety of terms in use here, it's easy to see how things you didn't even think about could suddenly become much more important than you anticipated. Being that Places are so new, I am certainly not confident that I can anticipate how people will use them in the future. However, I'm not opposed to providing some basic defaults that people could utilize so that we have the fundamentals covered, ex. how do you give your place a name, how do you give it an address, how do you give it a phone number, etc. That would be useful. |
If you did this, it would be hard to get a list of tags from an event that were props and not-props. At least in this way the props are namespaced and don't pollute. I figured if each tag should have a purpose, then prop's purpose is to corral key=value properties.
I'd be happy to clarify in the NIP that I'm referring to ownership of the nostr event, not necessarily the physical place. Yes, identifying the owner of a real place based on a kind 37515 is at least as difficult as determining if the owner of Michael Saylor's pubkey is actually Michael Saylor. But as I mentioned above, there are ways to help with this and tame the global feed of places, and some of these techniques have yet to be tried. |
|
This NIP seems to have parts that are accepted ( What if we would separate concerns here: NIP-44 really just does the geo coordinate part, no ones seems to argue about, but the annotation part is removed. But we want annotation of places. So what about a way to synthesize the want for openness and the need for structure? We make another event kind that:
sth like {
kind: 424242,
content: "stringified data be it json, xml (🤢) , whatever",
tags: [
["a", "1234-referenced-event-id..."],
["s", "json-schema/xml-schema/whateverelse-schema", "https://uri-to-the-schema"]
],
...
}This enables to annotate arbitrary events with structured data. Clients could query for schemas they understand. The place to discuss about appropriate attributes would no longer be part of a NIP discussion for all kinds of "Other Stuff" people want to build on Nostr. This would reduce the burden of discussion from Nostr CEOs and put it outside. At the same time it would be evident for everyone, what kind of schema one is using for the data and the schema is at best well annotated or accompanied by a spec. Better schemas will find more reuse. So Yondar would go forward and define a schema, or reuse an existing one (don't know if OSM provides sth like that). The NIP could hold references to clients using schemas for specific objects types (e.g. Places). |
|
Why not always use the same schema and then everybody can read all events? |
|
I have naming concern.
|
@sroertgen I appreciate you cutting through the noise to the heart of the issue here. I think you're right. Funny enough, this NIP was originally a proposal for only annotation with key=value pairs (nothing to do with Places), and it was shot down immediately when I sent it to some nostr dads. It was shorter, simpler, but I was told that we shouldn't add a We could store all the key=value properties in the This NIP does specify the kind By the way, your 🤮 emoji made me laugh... everyone says we don't like stringified JSON/XML in the content, so putting stuff in tags is the alternative. JSON is key=value, so I am surprised that the non-indexed key=value tag I've proposed has been met with such resistance. We either stringify key=value and put it in the content, or we put it into a non-indexed tag. I vote for the tag approach.
@fiatjaf There are several different schemas used by mapping people, and I've been petitioned to support them. This allows conventions to come across to nostr, as well as the importing of select data from other sources. I thought that NIP-32's usage of namespaces was a model I could follow here to enable that flexibility. I think it would be a good idea to add some basic keys like Of course, if someone wants to put forth a schema I'm certainly open to it, but trying to manage that could be its own job and I don't think nostr needs to take on that work. Maybe the answer is to just define a basic set of properties that require client support, and allow for clients to support additional properties/schemas. @paulmillr Thank you Paul for the details. I don't care about the number, so I can change this to XX until we get to the merge stage. |
|
The kitchen schema example has been confusing so I'm going to remove it and replace it with something more applicable to Places. The point was to demonstrate how to translate a schema to nostr tags when the schema isn't flat. |
😆 The "generic triples" thing was discussed here. The argument against was summarized well by @vitorpamplona here — generic key/value data is a One Ring to confuse them all, and will tempt developers to think they're supporting interoperability by putting whatever garbage they want in triples. I think my point still stands that we need a way to invoke external nomenclatures. Maybe it could be done by specifying some special tag name per use case. So instead of |
Why not just take OpenStreetMaps's schema and use that as the Nostr schema then? If you say "we support all these 4 different schemas" that doesn't really mean we support all these 4 different schemas, it means some people implement some, others implement others, some implement 3/4 and most people get confused as hell and implement nothing and the idea dies. If you are expecting many people to write clients that implement more than one schema and you are ok with that why wouldn't it be more reasonable to force the people who are publishing the data to conform to one schema? It's much easier for the person publishing the data to crunch their data to a specific format then to condemn everybody else for saecula saeculorum to navigate a sea of mess. |
Because I assume the reason there are multiple schemas that do the same thing is that there are trade-offs between them. But maybe this is one of those content-type issues, where we should specify which schema should be used, and if someone wants a different schema, they can create a new kind. |
@fiatjaf the OpenStreetMaps schema is "any string as a key = any string as a value", so that won't really work 😁 |
|
Help us define the Place properties that nostr should use: https://docs.google.com/forms/d/e/1FAIpQLScF2LYr9RIYi4-YFKNFaaYH3YYTdUo09j6RRGVjf992wNC1EQ/viewform Results: https://docs.google.com/spreadsheets/d/1r7mYftFUgED1VTvTaIv790a2JKXnfVDt9T0_INxzgd8/edit?usp=sharing |
|
I look forward to having a consistent NIP for location based data on Nostr. I built mapstr.xyz and would start to use this if merged. There are multiple Nostr mapping apps around atm and it would be good to converge on a common NIP and build up Nostr geographic related data. I thought there was a great deal of thought that went into the structure of the NIP and dealing with geographic based data. Well done! One question, how would the current NIP deal with Notes from different clients? Would a tag (key/value pair) differentiate the client which produced it? |
|
@vinaylalco Thank you! If I am understanding your question correctly, you are wondering if you could discern which client produced a kind 37515 event. This NIP does not specify anything about that. I don't know if any clients try to leave their mark on the events produced by their users. I could see this potentially being undesirable to users. If you were to leave a distinguishing mark on a nostr event to indicate which client produced it, you would probably have to use a tag. I'm not aware of any standard tags to do this. |
|
@vinaylalco I would invite you to submit your recommended properties to the form linked in #927 (comment) so that this NIP can support the properties you desire for Places to have. Thank you, and nice work on mapstr.xyz! 👾💜 |
It is probably a |
A tag can probably handle it yeah and as you point out there is a tag for this already. My thinking on this one was that maps often have layers of data and it may be desirable to have a a layer for each client app so the user could toggle data from diff location related Nostr apps. It was one use case I'm considering over at mapstr anyhow but yeah a tag will be fine to handle it as you can filter on this basis. It could be an optional tag the user could add/remove as desired to alleviate any privacy user concerns. |
Well, Nostr also allows any key, but I bet OSM has a set of core properties that they actually use in the UI, no? |
This PR represents an evolution of the current implementation of Places on https://go.yondar.me. The goal of this PR is to bridge the gap between existing mapping standards (OpenStreetMaps, Schema, etc.) and nostr, enable crowdsourcing for Places, and give a foothold to the usage of geospatial data on nostr.
I'd like to get feedback on this PR and implement that feedback into Yondar; then we will have an implementation justifying a merge.