Update 101.md

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.
This commit is contained in:
unostr 2024-07-06 22:38:50 +02:00 committed by GitHub
parent 6da0481b84
commit d72d91fc3e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

33
101.md
View File

@ -6,8 +6,8 @@ Descriptor Note
`draft` `optional`
A new event type "101" which is a note to describe "stuff" in a human readable way.
"Stuff" here, is represented by an identifier (descriptor if you will) which most likely would be the hash of a data object.
A new event type "1101" which is a note to describe "stuff" in a human readable way.
"Stuff" here, is represented by an identifier (a descriptor if you will) which most likely would be the hash of a data object.
Each line of this note type will have a specific purpose.
The first line is dedicated for the point we want to describe (as mentioned above)
@ -28,13 +28,32 @@ Ordered from the webshop (order number 12345)
Remember to pack sticker freebies.
```
The Descriptor Note can be ported to a Nostr note using the existing tags.
For kind 1101 tag p,n,l stands for point, name and label.
The multi-line description is kept in the content field.
Example:
```json
{"id":"905e339571caaabb57455fa33791a65d945d7371e2da81ff6aae923db8042ea0",
"pubkey":"84468de1424085f127ebd262b1d25df0c8196077ebfe76bb02c9deaf09687dee",
"created_at":1695458067,
"kind":1101,
"sig":"56ff6161bf2df122d1fe1c2c1576e8c355202e1e80db07c1168aca006ad7188562a7e89394cadf5c7f123007c7ce81ae72e9688fa19a365e2d66866157425b95",
"content":"This is awesome T-shirt in size L.
Ordered from the webshop (order number 12345)
Remember to pack sticker freebies.",
"tags":[
["p", ”1234567890abcdef1234567890abcdef],
["n", "order-number_12345"],
["l", "webshop order of a T-shirt"],
]}
```
It is mandatory to fill out the point field; the three other fields are optional.
Making the describing fields optional on protocol level should make the descriptor note format useful for a broader set of applications.
On application level the user/developer can use and constraint the fields as it fits in that particular application.
All semantics regarding the descriptor note is in the note itself (by dedicating specific line numbers to specific fields).
Thereby we do not pollute the Nostr JSON document with extra meta data.
Hence we get more advanced functionality while keeping the Nostr note format itself clean and simple.
On application level the user/developer can use and constraint the three fields as it fits in that particular application.
For more info the Descriptor Note has its own website over here:
https://descriptor-note.surge.sh