mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-12 23:19:08 -05:00
53 lines
2.6 KiB
Markdown
53 lines
2.6 KiB
Markdown
|
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
|