nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-10 06:09:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

rename: Tracking Git Commits with Nostr, simplify

Browse Source
This commit is contained in:
Melvin Carvalho 2023-03-05 10:38:45 +01:00 committed by GitHub
parent 5f619246ab
commit fded2189f7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
17.md
View File

@ -1,8 +1,8 @@
NIP-17
======
Git Commits and Discovery Over Nostr
------------------------------------
Tracking Git Commits with Nostr
-------------------------------
`draft` `optional` `author:melvincarvalho`
@ -17,18 +17,18 @@ Status: This NIP is an early draft and work in progress. Implementations are be
Introduction
------------
Git Commits over nostr enable **use cases** similar to:
Tracking Git Commits with Nostr enables **use 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.
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 first implementations will be designed to illustrate these use cases in more detail.
**You need only know the nostr ID or bech32 form of a repo you will be able to discover all versions, its origins and its history.**
You need only know the **nostr ID or bech32 form of a repo** and you will be able to discover all versions, its origins and its history.
The git object data is not designed to be stored in nostr, but rather, the signaling, update, version and commit data. Git data will live in existing git repositories, github, gitlab, gitea, gogs, ssh, file system etc.
Git object data is not designed to be stored in nostr, instead, nostr will store the signaling, update, version or commit data. Git object data will live in existing git repositories, github, gitlab, gitea, gogs, ssh, file system etc.
New Kind
@ -46,7 +46,7 @@ A new tag "c" will be used to store commit hashes from git a new version of the
Bech32
======
The prefix `nrepo` can be used in front ends that support it, to allow easier copy and paste
The prefix `nrepo` can be used in front ends that support it, to allow easier copy and paste. An example would be similar to the popular npub system e.g. `nrepo1ris1683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24`
Event Structure
@ -73,22 +73,21 @@ Git events over nostr have the following attributes:
**`tags`** MUST contain tag "c" which is 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
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.
MAY contain an entry identifying the previous commit, if one exists, in the form `["e", "<event_id>"]`.
Further tags can be developed in future to capture informative git information such as major/minor versioning.
**`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`
**`content`** empty, reserved for future use
Repo Discovery
===============
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. TODO: flesh out this section, perhaps include relay discovery, and bech32 encoding
nostr.json
==========
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`
The design of this NIP is such that each repo will have a public key used to send updates to a relay. The repos itself will be able to interact with nostr.
That key SHOUL appear in the top level directory of the repo in a file called `nostr.json`
```JSON
{
@ -96,6 +95,8 @@ The design of this NIP is such that each repo will have a public key used to sen
}
```
Optionally a bech32 "nrepo" field can be added for convenience of copy and paste
Extensions
==========