From c86a8c06342bd8ec1917988fbf9a27d7b279fefb Mon Sep 17 00:00:00 2001 From: Michael Jurkoic Date: Wed, 10 Jan 2024 21:00:17 -0600 Subject: [PATCH] Add NIP for signed and versioned 3rd-party objects --- 62.md | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 62.md diff --git a/62.md b/62.md new file mode 100644 index 00000000..556b8de0 --- /dev/null +++ b/62.md @@ -0,0 +1,75 @@ +NIP-62 +====== + +Signed and Versioned Third-Party Objects +---------------------------------------- + +`draft` `optional` + +This specification defines a protocol by which Nostr events may be used to authenticate third-party objects, which may be versioned. With Nostr, the cryptographic identity afforded by an npub/nsec keypair can be used to attest to the authenticity of an object outside of the Nostr network. Thus, the level of trust a user gives to a specific npub may be assigned to third-party objects that npub is willing to attest to. Such objects may include, but certainly are not limited to, Git commits, documents, and images. + +## Kind `32000`: Simple Third-Party Object + +An event of kind `32000` SHALL serve to authenticate an unversioned object hosted by a third-party service (i.e., not a Nostr client or relay). The `content` field MAY contain a description of the object or its contents. The following tags SHALL be used: + +- The `d` tag MUST contain a unique identifier for the object. This identifier SHOULD be a hash of the object itself to provide an additional means of validating its authenticity. +- The `r` tag MUST indicate one or more URLs at which the object can be found. +- The `m` tag MAY be included to indicate the MIME type of the object. +- The `client` tag, as defined in [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md), MAY be included to indicate a preferred client for handling the Nostr event and its associated object. +- The `hash` tag MUST be used when the object's unique identifier is a hash to indicate the hash method used. + +### Event Format + +```json +{ + ..., + "kind": 32000, + "tags": [ + ["d", ], + ["r", ], + ["m", ], + ["client", ,
, ], + ["hash", ] + ], + "content": , + ... +} +``` + +## Kind `32001`: Versioned Third-Party Object + +An event of kind `32001` SHALL serve to authenticate a versioned object hosted by a third-party service (i.e., not a Nostr client or relay). Events of this kind MUST implement the specification for kind `32000`, along with the following rules: + +- The `a` tag MUST reference the kind `32000` or `32001` event that represents the immediately previous version of the object. +- The `d` tag MUST use as an identifier a hash of the versioned object, so that each version is uniquely identified. +- The `hash` tag MUST be included to specify the hash method used to produce the object's unique identifier. +- The initial version of an object SHOULD be represented by a kind `32000` event, and all subsequent versions MUST by represented by events of kind `32001`. + +### Event Format + +```json +{ + ..., + "kind": 32001, + "tags": [ + ["d", ], + ["r", ], + ["a", , ], + ["m", ], + ["client", ,
, ], + ["hash", ] + ], + "content": , + ... +} +``` + +## Usage Notes + +This specification is designed to provide the foundations by which file hosting and version control, akin to GitHub or SharePoint, may be implemented on Nostr. + +The first instance of any third-party object authenticated with Nostr should be a kind `32000` event, since that kind has no `a` tag antecedent. If the third-party object or its host location is changed, the changes may be versioned or unversioned. + +When the host location of an object changes, the event can simply be replaced with a new event with the same `d` tag, but updated `r` tags. Likewise, when an object with a simple ID (i.e., not a hash) is updated in-place, the change may be indicated by replacing the kind `32000` event with a new one that has the same `d` tag but a different `content`. + +Version control, such as Git or SVN, may be represented on Nostr using kinds `32000` and `32001`. In such cases, the `d` tag may be the commit or change ID, and commit details may be included in the `content`, though other schemes are certainly conceivable. For a fully versioned object, the start of that objects history would be represented by a kind `32000` event, and subsequent changes by a series of kind `32001` events, each referring to the previous change. A complete file history may be constructed from such a sequence.