NIP 101 - Descriptor Note

[unostr]

Here's a NIP for the Descriptor Note (presented at Nostrasia)

The NIP can be read here

[fiatjaf]

Is there a link to the Nostrasia presentation? I want to understand the use cases.

Part of me that loves abstractions loves this, but I think we need more concreteness.

[unostr]

Yeah okay, so whenever you want to save information for yourself or others about what you stumble upon.

It could be notes on a note so that you can find it again later. Or more details about one of the 50 new npubs you got at the conference so you remember them afterwards.

The presentation is here

What I intend to use it for, especially, is documenting micro protocols built with Info Triples.

[vitorpamplona]

Why not put the first 3 lines in tags and the rest as the content of the JSON event?

[unostr]

While you could do that it would tie the Descriptor Note to the JSON Note.
Having everything in the content makes it like having a layer on top of NOSTR.
The notes may be handy to store locally on your device and then the extra JSON data + parsing could be a bit much.

[vitorpamplona]

While you could do that it would tie the Descriptor Note to the JSON Note.

I would argue they are already tied, but sure.

Having everything in the content makes it like having a layer on top of NOSTR.

You don't need to avoid tags to create a layer on top of Nostr.

The notes may be handy to store locally on your device and then the extra JSON data + parsing could be a bit much.

I am not sure what you mean here. Do you want to just store the .content field and through everything else out? You would have to parse the JSON anyway to get the .content field. So, if you already did the parse, then getting the tags that represent the first 3 lines is faster than parsing the content by new line to get the same info.

[fiatjaf]

I watched the talk and I see you have some use cases implemented there.

For example, there is a recipes list and a way to give ratings to recipes.

What I think about that is that you will need a schema and a sub-protocol on top of descriptor-notes and triples in order to know that some kinds of things are recipes anyway. In that case we are back into having to create NIPs (or in this case they would be TIPs -- triples implementation possibilities) so people would know what to do with and how to display this data.

In this case, why not just stick with Nostr and use Nostr events as a mix of descriptors and triples, and use NIPs as TIPs?

In other words, it looks like you're trying to create Nostr on top of Nostr.

[unostr]

While you could do that it would tie the Descriptor Note to the JSON Note.

I would argue they are already tied, but sure.

Having everything in the content makes it like having a layer on top of NOSTR.

You don't need to avoid tags to create a layer on top of Nostr.

The notes may be handy to store locally on your device and then the extra JSON data + parsing could be a bit much.

I am not sure what you mean here. Do you want to just store the .content field and through everything else out? You would have to parse the JSON anyway to get the .content field. So, if you already did the parse, then getting the tags that represent the first 3 lines is faster than parsing the content by new line to get the same info.

Maybe I were a bit hasty with the explanation.

I am thinking that splitting up into many fields will increase the chance of messing up the hash of the Descriptor Note itself (not the NOSTR Note ID)

When creating a Descriptor Note it may very well be done locally and saved in a file or record named with the hash of the note as filename/ID.

After publishing others can add it to their local storage. I'd say it would then be easier for app developers to just move the content field into a file or data record than having to concatenate the fields and remember to separate with new lines to get the hash right.

[unostr]

I watched the talk and I see you have some use cases implemented there.

For example, there is a recipes list and a way to give ratings to recipes.

What I think about that is that you will need a schema and a sub-protocol on top of descriptor-notes and triples in order to know that some kinds of things are recipes anyway. In that case we are back into having to create NIPs (or in this case they would be TIPs -- triples implementation possibilities) so people would know what to do with and how to display this data.

In this case, why not just stick with Nostr and use Nostr events as a mix of descriptors and triples, and use NIPs as TIPs?

In other words, it looks like you're trying to create Nostr on top of Nostr.

I saw the RDF/schema discussion the other day while preparing these NIPS :)

So for Info Triples creating a schema is a quite simple process.
You create your own micro protocol by selecting an ID for what you want to express, say 0x44b means a food recipe.
From there you can start tagging you NOSTR messages with the recipe tag in Info Triples and now you have something to build an app for.

To begin with we will have to make Descriptor Notes to explain what our IDs are to be used for, so that other devs can use our protocols as well.
In the long run, our micro protocol can be described in Info Triples to such great details that the app accommodating it can auto generate its functionality.
(Insert white bearded British man yelling "PREPOSTEROUS!" here)

Another difference from the BIPS, NIPS, TIPS approach is that no formal approval of a pull request needs to be given.
People just make micro protocols for what they want and then other people can choose to use their standard if they find it reasonable.

If a user makes something relevant for clients in general, or the NOSTR protocol itself, it would make sense to propose that in a NIP.

That's not the case for, as an example, food recipes. We wouldn't expect a protocol for transmitting notes and other stuff to actually know the semantics of a food recipe.
And you also wouldn't expect it to be normal for social media clients to be able parse data structures containing cooking recipes.

It's a fascinating idea to mix Descriptor Notes and Info Triples, I have to think more about that.

You can say for Descriptor Notes, which is what this NIP is about, it is a bit to make notes on top of notes and maybe @vitorpamplona is right that it's better to have the Descriptor Note fields as labels and do it the NOSTR way...
However it would still be nice if it had its own event type so we don't risk mixing 101 descriptions of micro protocols with our social media feed.

[vitorpamplona]

I think what you are trying to do is similar to NIP-95. You just want to dump another format, defined somewhere else, into the .content. NIP-95 takes any file. Here you want to use this Decriptor Note idea.

It's a good idea if the format is precisely defined somewhere else so that anyone can decode it correctly. In NIP-94/95, the m tag defines the mimeType of the file to tell the app how to decode the content. Apps that support those mime-types can make use of such events.

You could even use NIP-95 if you have a mime type for this Triplet Design.

But when you do so, you lose all Nostr facilities, like searching by the first and second lines on a relay. You would have to know either the event id or the pubkey to filter the information from the relay, or you will have to download all 101 events to filter them locally.

[unostr]

Thanks, as one of those who would like to have binary data on or with NOSTR somehow, I welcome NIP-95's idea having a general way to express binary data.
It seems though that they target larger files, and hence don't want generic searches.
Ironically enough it also looks like they lack a way to model meta-data.

So as much as I like the idea of having a NIP for binary data I think it need some work and maybe it would be better to have a NIP for embedding smaller pieces of binary data in a general way into a NOSTR Note and then find other approaches for large data.
I'm mostly fan of referring to large files elsewhere from a link in the NOSTR Note.

[unostr]

Question for @fiatjaf , @vitorpamplona and who ever is interested in the discussion.
Would it make sense if I proposed a new NIP for "other stuff"?

The rationale: As NOSTR takes off, there may be thousands of smaller projects being build on NOSTR.
Some of them private. Some experimental. Some just not mature enough yet to get their own NIP.
So to make it easier to get started, we could give "other stuff" its own event type.

To allow the "other stuff" projects to distinguish from each other, the new note could introduce one or two new fields.
I'm thinking a type and a sub type field.
Using two extra type fields rather than the existing label fields would keep the label area clean for tags that actually have to do with the data in the notes.

Thoughts?

[vitorpamplona]

No need for it. There is no shortage of numbers. They can just choose a full event kind for themselves. :)

[unostr]

Thanks that's nice - I'll hang onto my two event numbers then, and see what happens in the NIPS landscape as the project progresses.

[unostr]

Updated the specs. This Nip is in an ongoing draft-mode which is fine as it is to be perceived as such. Reference implementation is on its way.