nips/211.md

Nip 211
=======

Info Triple Note
----------------

`draft` `optional` 

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.


##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:
```
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 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.
Example:
```
19730e47c02bd3f2e0ed081517e221c7328e34d1a409853f02097e36bcdfc697 3fe57df7ba94682aa83e213cf886ca8ee65b39c5ae666ee6ef8d5019094327fe db764b29ba1abf49bee760832facbd2a96ba8f79a6959951dbe923ea463733ba
101cee343ac388560f87e704a3026a66e89ea3e710cae9c41f2a3ff3c84907bc 3fe57df7ba94682aa83e213cf886ca8ee65b39c5ae666ee6ef8d5019094327fe 84fc4c4e86cbbff530e17d285781dc9f43586957713abc83a8f09b7fba9f6311
1917a232a8db4d34a9289f4c56d198801fba5e71e8895f34a8523327f677b67b 101cee343ac388560f87e704a3026a66e89ea3e710cae9c41f2a3ff3c84907bc fe91d6a74e0cd5beb1dd3b8b786afc27758a31dc979b9527cb0ef70021a162da
```

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.

Nostr tag based example:
```json
{"id":"905e339571caaabb57455fa33791a65d945d7371e2da81ff6aae923db8042ea0",
"pubkey":"84468de1424085f127ebd262b1d25df0c8196077ebfe76bb02c9deaf09687dee",
"created_at":1695458067,
"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":[]}
```

Clients and relays implementations
----------------------------------
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.

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