Starting work on NIP-17
NIP-17
======
Git Updates and Discovery Over Nostr
------------------------------------
`draft` `optional` `author:melvincarvalho`
- Reserves: `kind 17`
Do not merge until implemented, work in progress
------------------------------------------------
Introduction
------------
Git updates over nostr enable uses cases similar to [github actions](https://github.com/features/actions) / [continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) / [continuous deplyment](https://en.wikipedia.org/wiki/Continuous_deployment) / [travis](https://travis-ci.org/), 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.
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`.
Git events *could* be displayed as a text note (kind=1) too, but they are unlikley to mix well with human readable notes, so that motivates git events having its own kind, and even specialist relays.
The git object data is not designed to be stored in nostr, but rather, the signaling, update, version and commit data.
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.
This NIP is an early draft and work in progress. Implementations are being developed which will incorporate what is learnt.
Event Structure
===============
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 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`
```JSON
{
"pubkey": "abcd123..."
}
```
Related Work
============
- http://git.jb55.com/git-nostr-tools/file/README.txt.html
melvincarvalho / Melvin Carvalho
npub1me…t5c24
2023-01-19 20:46:32
Author Public Key
npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24Published at
2023-01-19 20:46:32Event JSON
{
"id": "3a256ace6b7a9fa82d6ee882f7fe00908cc45914ce6c540267e915fbca731b6d",
"pubkey": "de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645",
"created_at": 1674161192,
"kind": 1,
"tags": [],
"content": "Starting work on NIP-17\n\nNIP-17\n======\n\nGit Updates and Discovery Over Nostr\n------------------------------------\n\n`draft` `optional` `author:melvincarvalho`\n\n- Reserves: `kind 17`\n\nDo not merge until implemented, work in progress\n------------------------------------------------\n\n\nIntroduction\n------------\n\nGit updates over nostr enable uses cases similar to [github actions](https://github.com/features/actions) / [continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) / [continuous deplyment](https://en.wikipedia.org/wiki/Continuous_deployment) / [travis](https://travis-ci.org/), 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.\n\nA 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`. \n\nGit events *could* be displayed as a text note (kind=1) too, but they are unlikley to mix well with human readable notes, so that motivates git events having its own kind, and even specialist relays.\n\nThe git object data is not designed to be stored in nostr, but rather, the signaling, update, version and commit data.\n\nIt 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.\n\nThis NIP is an early draft and work in progress. Implementations are being developed which will incorporate what is learnt.\n\nEvent Structure\n===============\n\nGit events over nostr have the following attributes:\n\n**`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\n\n**`created_at`** SHOULD be equal to git *author date*. This is the same format as nostr.\n\n**`tags`** MAY contain an entry identifying the previous commit, if one exists, in the form `[\"e\", \"\u003cevent_id\u003e\"]`. 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.\n\n**`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`\n\n```JSON\n{\n \"pubkey\": \"abcd123...\"\n}\n```\n\nRelated Work\n============\n\n- http://git.jb55.com/git-nostr-tools/file/README.txt.html\n",
"sig": "9cc21d7efbb6f5ef721255c355ff85848a62dd531396c3a8e28192ef2adc1d8b25d658f24f85682ecbb678ec39a9374e2f7c61b005288168b33477d4fffa968b"
}