nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 16:35:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update 211.md

Browse Source
This commit is contained in:
unostr 2024-07-06 22:44:30 +02:00 committed by GitHub
parent 96aad02723
commit dc8c8594fa
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 58 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
211.md
View File

@ -6,13 +6,17 @@ Info Triple Note
`draft` `optional`
TLDR: Info Triples can be used when creating micro apps as an alternative to adding new meta data to the NOSTR Note's JSON document.
Because of that we will no longer have to write a new NIP for each type of micro app created and thus the JSON structure can be kept simpler.
Info Triples can be used when creating micro apps as a way to define data structures and as a way to tag data.
Info Triples can make up an Info Graph, which can be seen as both a graph-like data structure and a methodology.
Using this methodology we can embed cross client user settings into notes and we can even introduce new feature standards without the somewhat tedious process of writing NIPs for everything.
This can in turn help keeping the NIP base smaller and therefore easier to oversee, while client builders can collaborate on making micro protocols for smaller cross-client agreements.
I propose a new event type "211" which is a note meant to describe relationships between "stuff" in a machine friendly way using Info Triples.
"Stuff" here are represented by large numbers, as identifiers, and would most likely be SHA256 hashes of data objects.
An Info Triple consists of three of those large number.
Think of it as a Merkle root of a Merkle tree that only has two elements, and where the Merkleroot is written first and then the two sub nodes' hashes.
##data structure
I propose a new event type "1211" which is a note meant to describe relationships between "stuff" in a machine friendly way using Info Triples.
"Stuff" here are represented by large numbers, as identifiers, and will most often be SHA256 hashes of data objects.
An Info Triple consists of three of those large numbers.
Think of it as a Merkle written first and then the two sub nodes' hashes.
In text form the Info Triple can be represented as a single line where the fields are separated by white spaces.
Example:
@ -20,8 +24,9 @@ Example:
19730e47c02bd3f2e0ed081517e221c7328e34d1a409853f02097e36bcdfc697 3fe57df7ba94682aa83e213cf886ca8ee65b39c5ae666ee6ef8d5019094327fe db764b29ba1abf49bee760832facbd2a96ba8f79a6959951dbe923ea463733ba
```
##Tag data
An Info Triple represents an atomic bit of information namely that a relationship exists between two object.
As an example object one could represent a NOSTR Note and the second object could represent the concept of being a food recipe, meaning that a relationship between the two objects tags the NOSTR message as being a food recipe.
As an example, object one could be a Nostr Note ID and the second object could be a hash representing the concept of being a food recipe, meaning that a relationship between these two objects would effectively tag the Nostr message as being a food recipe.
The Info Triples can be stacked as rows in a table called an Info Table.
In text format we simply let each line be a row comprising a table as seen below.
@ -32,37 +37,63 @@ Example:
1917a232a8db4d34a9289f4c56d198801fba5e71e8895f34a8523327f677b67b 101cee343ac388560f87e704a3026a66e89ea3e710cae9c41f2a3ff3c84907bc fe91d6a74e0cd5beb1dd3b8b786afc27758a31dc979b9527cb0ef70021a162da
```
I propose using the content field for the Info Triple/Info Table to not pollute the JSON structure of the NOSTR Note itself.
To make it as simple as possible for client and relay builders to parse the data, the standard Nostr tag fields can be used for embedding the data into Nostr notes.
This means that Info Triple/Info Table does not make changes to the existing Nostr note JSON structure.
Example:
Nostr tag based example:
```json
{"id":"905e339571caaabb57455fa33791a65d945d7371e2da81ff6aae923db8042ea0",
"pubkey":"84468de1424085f127ebd262b1d25df0c8196077ebfe76bb02c9deaf09687dee",
"created_at":1695458067,
"kind":211,
"kind":1211,
"sig":"56ff6161bf2df122d1fe1c2c1576e8c355202e1e80db07c1168aca006ad7188562a7e89394cadf5c7f123007c7ce81ae72e9688fa19a365e2d66866157425b95",
"content":"",
"tags":[
["a", ”19730e47c02bd3f2e0ed081517e221c7328e34d1a409853f02097e36bcdfc697"],
["b", "3fe57df7ba94682aa83e213cf886ca8ee65b39c5ae666ee6ef8d5019094327fe"],
["c", "db764b29ba1abf49bee760832facbd2a96ba8f79a6959951dbe923ea463733ba"],
]}
```
For kind 1211 we define tag a,b and c as ID1, ID2 and ID3 of the info triple.
Note that tag c is ID3 which is also called the triple ID and is written first in Info Tables because it is the unique and therefore identifying ID.
This ID is enumerated ID3 because it does not come into existence before a relationship has been made between ID1 and ID2.
Alternative example based on the context field:
```json
{"id":"905e339571caaabb57455fa33791a65d945d7371e2da81ff6aae923db8042ea0",
"pubkey":"84468de1424085f127ebd262b1d25df0c8196077ebfe76bb02c9deaf09687dee",
"created_at":1695458067,
"kind":1211,
"sig":"56ff6161bf2df122d1fe1c2c1576e8c355202e1e80db07c1168aca006ad7188562a7e89394cadf5c7f123007c7ce81ae72e9688fa19a365e2d66866157425b95",
"content":”19730e47c02bd3f2e0ed081517e221c7328e34d1a409853f02097e36bcdfc697 3fe57df7ba94682aa83e213cf886ca8ee65b39c5ae666ee6ef8d5019094327fe db764b29ba1abf49bee760832facbd2a96ba8f79a6959951dbe923ea463733ba",
"tags":[]}
```
Encoding
--------
Simple hex values works, as they do for other fields in the NOSTR note.
However there are some size benefits to gain from using, for example, Base64 or Base58 encoding.
To tell clients and relays what form of encoding is used self-reporting, as described in Nip 32, can be used.
Nip 32 Labeling (and NIP 56 Reporting)
Clients and relays implementations
----------------------------------
Nostr have another way of classifying content already in the form defined in Nip 32 and Nip 56.
Some differences between NIP 211 Info Triples and NIP32 Labeling:
- Info Triples are meant to model complex data as well and are therefore more comparable to Knowledge Graphs.
- Info Triples are meant for modeling information in general (not just NOSTR notes) and hence the NOSTR note can seen as a carrier/envelope. In comparison the NIP32 are specifically targeting everything NOSTR: events, people, relays, topics...
- NIP 32 is meant to create human readable tags, Info Triples are meant for machine readable meta data, which can then be augmented with human readble Descriptor Notes (NIP101)
- NIP 32 is meant to keep everything within the scope of NOSTR. Info Triples let the developer abstract from the NOSTR layer and build new micro protocols on top of NOSTR.
- It is not a priority for Info Triple data to be recognizable by relays (or everybody). For the NIP 32 labeling namespaces "should" be well-defined.
Since this NIP require zero changes to the current Nostr note JSON structure and hence no change to existing client and relay software it is fair to call the NIP fully optional.
With that it should be clear that the Nip 32 and Nip 211 are quite different and that they should be able to coexist having each their own usecases.
Furthermore the Info Triple may even use the "self-reporting" feature of Nip 32 to tag its own encoding format.
To participate in this NIP all a client (or relay) need to do is to implement compatibility with an existing Info Triple based protocol.
Another way to get started is for a client to create its own little Info Triple based micro protocol.
The protocol can be shared to give other actors the ability to opt-in to the new standard.
Conflicts with existing NIPs
----------------------------
When creating micro protocols is should be considered that micro protocols can overlap with existing NIPs.
In those cases it's most often best to implement the existing NIPs for better compatibility with the rest of the Nostr network.
The micro protocols shines when we want to standardize a feature that may be too insignificant to get its own NIP.
For example, it could be that a client app wants to allow its users to create their own like-button.
Such feature is extra useful if other clients also implements it and in such way that the like-button created in one client, can be used seamlessly in another client.
Where one could argue that such feature is so useful that it could acquire its own NIP, congestion occurs, when other client developers start invent their own similar features, which then in turn also ought to have a NIP per feature.
Alternatively it may be that our example like-button standard does not get its own NIP simply because the Nostr community deems it not general or widely used enough. Still there may be a client builder somewhere out there who would like to know about it.
Finally once our users start making their own like-buttons they may want to share those buttons to collaborate with other users on categorizing Nostr notes.
It could be that a user make a button for tagging a note as being a food recipe. Sharing such button would be a good idea, but making a NIP for that particular button would be complete over-kill.
With Info Triples independent, optional, smaller standards can be made and shared.
More info on Info Triples can be found at https://www.infotriple.org