draft optional author:melvincarvalho
- Reserves:
kind 17
Status: This NIP is an early draft and work in progress. Implementations are being developed which will incorporate what is learnt.
Git Commits over nostr enable uses cases similar to:
but without central points of failure. The aim is to create continuous distributed software development processes, without having to rely on complex or centralized services.
The git object data is not designed to be stored in nostr, but rather, the signaling, update, version and commit data.
A special event with kind 17, can be used to indicate git commit messages. This number was selected to be hopefully easy to remember : G-1-7.
A new tag "c" will be used to store commit hashes from git a new version of the repo
{
"id": "32-bytes lowercase hex-encoded sha256 of the the serialized event data",
"pubkey": "32-bytes lowercase hex-encoded public key of the repo",
"created_at": "git_author_date",
"kind": 17,
"tags": [
["c", "git hash", "recommended git URI"],
["e", "previous commit id"]
],
"content": "arbitrary string",
"sig": "64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field"
}Git events over nostr have the following attributes:
content SHOULD be equal to the hex-encoded git commit hash. Typically this will be a 40 character sha-1 hash, but git will soon be allowing sha-2 hashes too
created_at SHOULD be equal to git author date. This is the same number format as nostr.
tags MAY contain an entry identifying the previous commit, if one exists, in the form ["e", "<event_id>"]. Further tags can be developed to capture informative git information such as major/minor versioning. TBD: it will be possible to hint at a recommended git URL to download the repos (e.g. from github), but it is not yet decided whether this would be a tag itself or an additional entry in an existing tag.
pubkey SHOULD be associated with a given repo. This could be communicated out of band, or, for example MAY be included in a file in the root directory of the repo, nostr.json
It will also be possible signal a recommended repo, just like it is possible to recommended a relay. In this way, a codebase could start on github, move to gitlab, then to an own hosted instance, and finally back to github. All, without any breaks in service.
The design of this NIP is such that each repo will have a public key used to send updates to a relay. That key SHOULD appear in the top level directory of the repo in a file called nostr.json
{
"pubkey": "abcd123..."
}