NIP-62: Signed and Versioned Third-Party Objects

[buttercat1791]

I am proposing a new NIP that defines a means of authenticating objects hosted outside of Nostr relays, and of managing multiple versions of such objects.

This NIP is written with Git workflows in mind. Git already supports distributed workflows, so there is no need to try to rebuild core Git functionality on Nostr. Instead, we can use Nostr to verify Git objects and make them discoverable.

This NIP is also intended to be broad enough to support a variety of other solutions. Clients can use it to implement SharePoint- or Google Drive-like functionality, with simple, linear file versioning and distributed hosting. Developers or testers can use it to verify software releases. Journalists can use it to verify articles or photos. This proposal allows anyone to put the weight of their Nostr identity behind objects anywhere on the web.

[AsaiToshiya]

I think many requests are required to get latest versioned object, is this understanding correct?

[fiatjaf]

Looks interesting. I don't know enough to have an opinion on this though.

[buttercat1791]

I think many requests are required to get latest versioned object, is this understanding correct?

It should be the opposite, actually. Each version links back to the previous one, so if you find the latest version, you can make multiple requests as needed to work your way back to the first version.

In thinking about this over the past few days, though, I realized that this event kind needs another tag to identify objects independently of their unique ID. Perhaps a context tag that contains human-readable aliases for an event. That way, all versions can have the same alias, making it easy to query for all of them at once, and the client doesn't have to know the unique ID of each version ahead of time.

@AsaiToshiya thoughts?

[AsaiToshiya]

I think many requests are required to get latest versioned object, is this understanding correct?

It should be the opposite, actually. Each version links back to the previous one, so if you find the latest version, you can make multiple requests as needed to work your way back to the first version.

Yes, if you know the latest version. But you should be sure it is not referenced to know if it is the latest version.

In thinking about this over the past few days, though, I realized that this event kind needs another tag to identify objects independently of their unique ID. Perhaps a context tag that contains human-readable aliases for an event. That way, all versions can have the same alias, making it easy to query for all of them at once, and the client doesn't have to know the unique ID of each version ahead of time.

This is a good idea. I don't know if human-readable aliases are needed, but I suggest to include the a tag for a reference to kind: 32000 in tags within kind: 32001 events.

{
  ...,
  "kind": 32001,
  "tags": [
    ["a", "32000:<pubkey>:<kind: 32000 identifier>", <relay hint>],
    ...
  ],
  ...
}

[buttercat1791]

In thinking about this over the past few days, though, I realized that this event kind needs another tag to identify objects independently of their unique ID. Perhaps a context tag that contains human-readable aliases for an event. That way, all versions can have the same alias, making it easy to query for all of them at once, and the client doesn't have to know the unique ID of each version ahead of time.

This is a good idea. I don't know if human-readable aliases are needed, but I suggest to include the a tag for a reference to kind: 32000 in tags within kind: 32001 events.

I just pushed a couple of changes along these lines. All kind 32001 events require an a tag referencing the "root" kind 32000 event. If there are previous kind 32001 events in the version chain, each new event must also reference the immediately previous version with a second a tag. So the end of a version chain should reference both the previous version and the root. That should make it easier for clients to navigate the note hierarchy of this schema.