nips/211.md

Nip 211

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 simple.

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.

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

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.

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

I propose using the content field for the Info Triple/Info Table to not pollute the JSON structure of the NOSTR Note itself.

Example:

{"id":"905e339571caaabb57455fa33791a65d945d7371e2da81ff6aae923db8042ea0",
"pubkey":"84468de1424085f127ebd262b1d25df0c8196077ebfe76bb02c9deaf09687dee",
"created_at":1695458067,
"kind":211,
"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 and 56, can be used.

Nip 32 Labeling (and NIP 56 Reporting)

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.

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.

More info on Info Triples can be found at https://www.infotriple.org