Add values to NIP 32

[staab]

This PR adds values back in to NIP 32 (@fiatjaf is going to hate me for it).

The problems with the old version of label values were:

• Not indexable
• Value object keys were not well defined
• Gross json in tag position 4

The approach used here supports indexing values (if relays want to support it), without losing the ability to assign values to individual labels or use multiple namespaces in a single event.

@s3x-jay @sroertgen @rodant

Keeping this a draft until it's implemented as per the usual process.

[fiatjaf]

If you want to give relays the option of becoming generic databases, why not use a tag with more than one character? This PR essentially forces them to be that.

There will be hordes of people abusing this to build all sorts of proprietary key-value stores "on Nostr" with arbitrary structured data that will benefit no one -- but they will tell themselves: "hey, I'm just following the NIP!"

This is already happening with L/l tags, by the way, but at least we can spot misbehavior somewhat easily now.

Eventually relays will have to hardcode blocks for this kind of stuff, which is fine, but if you want to be a good citizen why not make the thing off by default?

[staab]

@fiatjaf just pushed a new version which puts this in its own NIP to make sure the difference between labels and values is clear. I agree value should be the default rather than v, take a look at the wording in the new version and let me know if you're satisfied with it. Otherwise, I can remove v until there's more demand for it. The use case is something like "find all negative reviews" or "find triples where x is the object". But you're right this is easily abused.

[fiatjaf]

Well, now that you mentioned, yes, would be nice to see the use cases you have in mind in a more concrete shape.

I have the impression that each use case would be better served by a separate NIP than trying to make this generic database thing.

The generic database has no utility by itself because clients won't be able to interoperate if they don't know the schema the other clients are using, so you'll end up having to create more standards on top of this anyway. Why not skip the middle-standard?

[staab]

You might be right. The concrete use case I see everywhere is reviews. I will draft a review NIP and we can go from there.

[fiatjaf]

NIP-32 was conceived as a very generic "way to label things". Turns out people have very different use cases for all this labeling and the NIP is useless.

There are people using the label tags for report reasons, other people using them for tagging other events and resources and making curated collections. These two are already two different standards that could be each in its own NIP. I don't know what else people are using this for -- and the fact that I don't know is a symptom of the problem too.

[rodant]

Hello everyone, this PR is already closed, but I'd like to share my thoughts.

Firstly thanks for being eager to include more generic use cases, but well now the new NIP-85 has a strict scope, doing reviews, which is somehow neat, it makes things clearer and simpler.

Nevertheless, @sroertgen, @erskingardner, and I have other use cases in mind, https://labelmachine.org and https://ontolo.social are applications for categorizing content, which can be used in other apps like https://bitcoin-library.org. I'm elaborating on an app for a delivery service that would store its data as RDF triples in Nostr relays.

I think the support for RDF would be powerful and add a huge amount of standard schemas to Nostr almost for free. I don't know exactly whether this idea will catch up, and whether it is better to define small and precise NIPs for different use cases, but this is a field I'd like to explore.

For the generic RDF use case, I would start over. The RDF model is as simple as powerful. We have:

• resources with a unique URI,
• there are ontologies with defined semantics, also having a URI/URL,
• and we describe resources formulating RDF triples/sentences (subject, property, object (literal | resource)).

For example:

<https://example.com/profile/#bob123> <https://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person>,
<https://example.com/profile/#bob123> <http://schema.org/name> <"Bob">

A possible direct integration in the Nostr protocol could look like:

{
...
kind: "xxxx",
tags: [
   ["N", "https://example.com/profile/#bob123", "bob" (optional alias)],
   ["N", "https://www.w3.org/1999/02/22-rdf-syntax-ns#", "rdf"],
   ["N", "http://schema.org/", "sch"],
   ["r", "bob", "rdf:type", "sch:Person"],
   ["r", "bob", "sch:name", "Bob"]],
...
}

Here I've replaced the L tag with N (Namespace), in the first alias definition the namespace is a singleton, a special case. Note also that the r tag was extended with one more element to express a triple.

With this approach, relays will build indexes for namespaces, and the subjects in the RDF-triples. It makes sense to additionally define reverse triples as well, to let indexing resources at the third place: ["r", "Person", "sch:isTypeOf", "bob"], in this example to query for persons. By now I wouldn't try to build indexes for properties like type or literals.

You probably noticed that this general scheme includes support for any use case including review with rating, and categorization/labeling of content. Nevertheless, it can make sense to implement these simpler use cases with NIP-32.

For my use case concerning the delivery service, I need a way to map the specific business models to RDF. I would use an already-known ontology and define a new one where something is missing.

[staab]

Sounds great, RDF is a very nice data format. Feel free to open a new PR and rip off anything from this PR you like.

[fiatjaf]

@rodant why do you think that having a "huge amount of schemas" is a good thing? Isn't that literally just adding an exponentially huger amount of combinations between classes and attributes and then an infinite amount of code that has to be written to do anything with that and a huge amount of incompatibility cases between different implementations of whatever people want to do, and then a huge amount of error cases that have to be handled and a huge amount of fallbacks?

[staab]

The thing is that semantic web's problems notwithstanding, these nomenclatures are already defined, and there are many external data sources that work with schema.org. So RDF would just be a hook into those external systems.

[erskingardner]

I'm strongly against the idea of using RDF triples. On the surface, they look very logical. BUT, they are overly complex and would be an absolute nightmare to parse from a client point of view. The fact that almost no one uses this format and no one has ever heard of the applications that did use it should tell us something. Also, I doubt you'd be able to convince all relays to update their indexes to support this.

[vitorpamplona]

Since I worked with this in the past, I can say that just having an RDF-based schema format is fine as an engineering option, but terrible for interoperability. The issue is that every app then creates a new schema for themselves and never really tries to interoperate with one another, even if they are in the same context.

Proof: Covid QR codes we worked on are W3C verifiable credentials over RDF-based schemas. Instead of getting one payload structure for all COVID vaccine credentials, we got a different payload for every country/state that implemented it. Even though these solutions were all implemented from scratch, virtually at the same time, with similar technical guidance and huge desire for interoperability from everyone, all we got were systems that can verify one another but can't really understand each other. It didn't matter that we were using W3C or RDF.

Having a similar/generalizable syntax does not mean being interoperable. What Nostr NIPs do is quite literally the opposite.

RDF is just syntax. It's a fine choice, but it REQUIRES the semantics of each term to be defined somewhere else and then broadly adopted. NIPs define the syntax AND the semantics of our terms. So, if we do an RDF-based structure, let's make sure to create a NIP to label and semantically describe each schema we want to use.

Syntax generalization without tightly coupled semantics is a corporate engineering excuse to claim interoperability without actually being interoperable.

[sroertgen]

@erskingardner

I'm strongly against the idea of using RDF triples. On the surface, they look very logical. BUT, they are overly complex and would be an absolute nightmare to parse from a client point of view. The fact that almost no one uses this format and no one has ever heard of the applications that did use it should tell us something. Also, I doubt you'd be able to convince all relays to update their indexes to support this.

While I understand your objections regarding complexity it is just not true, that no one uses it. Go for example to https://udemy.com, look at the pages source code and search for "application/ld+json". They describe all their courses using RDF. Same applies to a lot of recipe websites and a lot of other websites.

Reason for this is google recommends it for embedding structured data, e.g. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

I'm still not sure about how it should be best implemented. But the use is widespread and for good reasons.

[rodant]

@rodant why do you think that having a "huge amount of schemas" is a good thing? Isn't that literally just adding an exponentially huger amount of combinations between classes and attributes and then an infinite amount of code that has to be written to do anything with that and a huge amount of incompatibility cases between different implementations of whatever people want to do, and then a huge amount of error cases that have to be handled and a huge amount of fallbacks?

This sounds like the worst case, but the reality can be better. Because of the "other stuff" in Nostr people will do whatever they want to do and the question is how Nostr can guide and standardize different developments. Complexity and incompatible implementations will arise also without RDF. At the end of the day, the users decide and can opt for apps with high compatibility with standards, defacto standards emerge, so I hope.

[s3x-jay]

Having a similar/generalizable syntax does not mean being interoperable. What Nostr NIPs do is quite literally the opposite.

Syntax generalization without tightly coupled semantics is a corporate engineering excuse to claim interoperability without actually being interoperable.

^^^ that ^^^ sums up the problem really well, IMHO.

[rodant]

Since I worked with this in the past, I can say that just having an RDF-based schema format is fine as an engineering option, but terrible for interoperability. The issue is that every app then creates a new schema for themselves and never really tries to interoperate with one another, even if they are in the same context.

Proof: Covid QR codes we worked on are W3C verifiable credentials over RDF-based schemas. Instead of getting one payload structure for all COVID vaccine credentials, we got a different payload for every country/state that implemented it. Even though these solutions were all implemented from scratch, virtually at the same time, with similar technical guidance and huge desire for interoperability from everyone. All we got were systems that can verify one another but can't really understand each other. It didn't matter that we were using W3C or RDF.

Having a similar/generalizable syntax does not mean being interoperable. What Nostr NIPs do is quite literally the opposite.

RDF is just syntax. It's a fine choice, but it REQUIRES the semantics of each term to be defined somewhere else and then broadly adopted. NIPs define the syntax AND the semantics of our terms. So, if we do an RDF-based structure, let's make sure to create a NIP to label and semantically describe each schema we want to use.

Syntax generalization without tightly coupled semantics is a corporate engineering excuse to claim interoperability without actually being interoperable.

I agree in principle, the semantics must be clear and Nostr could do this better. But I'm not sure with the Covid example, the different states were in a monopole situation without free competition. I think in the Nostr context it is a different game, but difficult to say. On the other hand, apps will need special things and will extend the standard in incompatible ways, resilience will be key.

[fiatjaf]

@sroertgen

While I understand your objections regarding complexity it is just not true, that no one uses it. Go for example to udemy.com, look at the pages source code and search for "application/ld+json". They describe all their courses using RDF. Same applies to a lot of recipe websites and a lot of other websites.

This is completely meaningless. The way they expose their data could be some JSON arbitrary schema, XML, CSV, HTML or RDF. You can argue over these, but they would all be arbitrary. In the end if you want to read that data you'll have to figure out their arbitrary schema and write specific code for that. That's not interoperability -- at least not more than any service that claims to have an open API is.

[fiatjaf]

@rodant

This sounds like the worst case, but the reality can be better. Because of the "other stuff" in Nostr people will do whatever they want to do and the question is how Nostr can guide and standardize different developments. Complexity and incompatible implementations will arise also without RDF. At the end of the day, the users decide and can opt for apps with high compatibility with standards, defacto standards emerge, so I hope.

It gives us no better chances of achieving interoperability if you start with RDF and schema.org than if we started with some rudimentary simple schema defined by ourselves in a NIP. In fact the NIP one would have absurdly more chances of achieving interoperability as it would be simple and straightforward.

If you start by saying "we support RDF and any schema you want!" and "we have huge amounts of schemas!" that's a recipe for complete arbitrary design disaster. We have already seen this happen in small scale even in NIP-32.

[sroertgen]

@sroertgen

While I understand your objections regarding complexity it is just not true, that no one uses it. Go for example to udemy.com, look at the pages source code and search for "application/ld+json". They describe all their courses using RDF. Same applies to a lot of recipe websites and a lot of other websites.

This is completely meaningless. The way they expose their data could be some JSON arbitrary schema, XML, CSV, HTML or RDF. You can argue over these, but they would all be arbitrary. In the end if you want to read that data you'll have to figure out their arbitrary schema and write specific code for that. That's not interoperability -- at least not more than any service that claims to have an open API is.

That was not the point of the comment. It was about usage of RDF (which is at least more than no usage). I totally agree with the rest.

[sroertgen]

To sum this dark discussion up and maybe add a bit of light:

• RDF per se will solve nothing.
• RDF without schema is not more useful than anything else

Nonetheless, there are use cases, like decentral annotation of resources, where sth like RDF might make sense. @pablof7z started it with highlighting parts of a page. Adding arbitrary comments and maybe labels is nice. If I want to annotate with more structured data, RDF might be a useful tool for this.

I strongly agree with @vitorpamplona and @fiatjaf that we need well defined schemas and according NIPs to achieve interoperability.
But all of this does not speak against RDF. It speaks against empty promises regarding interoperability.

[fiatjaf]

If I want to annotate with more structured data, RDF might be a useful tool for this.

You're reducing the problem to the very minimal, but I will insist this is still a problem. What is this "structured data"? You are already able to publish anything you want as Nostr events, but for interoperability's sake we should have a simple schema that everybody likes (or at least that most people tolerate), so we kinda have to come up with our own schema regardless -- we can take inspiration on schema.org or these things, but if we say we "use schema.org" then we die.

But yes, once we have a useful schema we all agree on, we can use triples.

[rodant]

I'd like to thank everyone for the discussion, which I wouldn't call "dark". My intention was to share some ideas about a possibility between many, nothing more. I do recognize the objections concerning full support for RDF, but for me, they aren't absolute truths.

I think NIP-32 has improved notably, and the new NIP-85 adds one more required use case to the standard, kudos to @staab and all the others involved. I'm very curious to see how Nostr will evolve and embrace more different applications.

[arkin0x]

the new NIP-85

@rodant I can't find this anywhere. Can you kindly link it for me?

None of these seem to be it: https://github.com/nostr-protocol/nips/pulls?q=85

85 does not exist: https://github.com/nostr-protocol/nips/blob/master/85.md

[rodant]

Hi, there you go #879.

…

-- E-Mail: ***@***.*** Am Di., 5. Dez. 2023 um 18:36 Uhr schrieb arkinox ***@***.***

: the new NIP-85 I can't find this anywhere. Can you kindly link it for me? None of these seem to be it: https://github.com/nostr-protocol/nips/pulls?q=85 85 does not exist: https://github.com/nostr-protocol/nips/blob/master/85.md — Reply to this email directly, view it on GitHub <#878 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWQFYLSHRILN2MXJC3IP3YH5LSTAVCNFSM6AAAAAA7JRWZJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGI4TIOJSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>