NIP-17: Tracking Git Commits with Nostr by melvincarvalho · Pull Request #324 · nostr-protocol/nips

melvincarvalho · 2023-03-05T16:39:51Z

This NIP has been redone with a new title and new scope, as the previous was confusing.

The aim is to use nostr to track commits in open source code. It is not git over nostr, or github over nostr.

Work in progress. It will only be apparent what it does after an implementation is ready.

Constructive comments only please, until there is an implementation in place, which will appear at : https://nip17.com/

spearson78 · 2023-03-09T19:31:09Z

I created a proof of concept git integration for nostr.

You can use it to create a git repo server that takes its config from nostr.

By issuing commands to a relay you can trigger the creation of git repositories and manage the permissions of these repositories. Authentication is handled by associating your nostr profile with an SSH key.

A quick demo video is here https://www.youtube.com/watch?v=G-WzlC8XfW4

The source code and documentation is here. https://github.com/spearson78/gitnostr

DanConwayDev

I'm super please that you are working on this. Multiple clients, different approaches and many contributors are much better for code collaboration over nostr that a single team working on one approach. That being said, I'd be keen to discuss what you are working on further and see if there are opportunities to work together on the goal of getting people us nostr for code collaboration if you are interested?

DanConwayDev · 2023-05-24T12:52:00Z

17.md

+Status: This NIP is an early draft and work in progress.  Implementations are being developed which will incorporate what is learnt.
+
+
+Introduction


You have put a lot of context in the introduction of the NIP, which is great for understanding where you are coming from, but perhaps will need to be paired down for the final NIP.

DanConwayDev · 2023-05-24T12:52:50Z

17.md

+New Kind
+========
+
+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`.  


Love this, its is so 1337!

DanConwayDev · 2023-05-24T12:53:42Z

17.md

+A new tag "c" will be used to store commit hashes from git a new version of the repo 
+
+
+Bech32


Personally I like the idea of Bech32 for repos but there is a balance to be struck. Should there be a bech32 for a whole variety of kinds? Why not have one for commits too? I imagine there has been discussion on this already that I haven't read and perhaps a consensus was already reached? If this is the right approach it should be referenced in NIP-19.

DanConwayDev · 2023-05-24T12:57:57Z

17.md

+  "kind": 17,
+  "tags": [
+    ["c", "git hash", "recommended git URI"],
+    ["e", "previous commit id"]


Do you mean the event id rather than the commit id? Should we include a hastag of the commit id?. Its not beyond the realms of possibility there two people could issue different events for the same commit.

DanConwayDev · 2023-05-24T13:00:57Z

17.md

+
+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`


Isn't it limiting that a repository can only be written to by one pubkey? Either there can just be a single maintainer or this pubkey would need to shared across multiple users. Have you considered #245?

Yes. I think there should be a list of maintainers pub-keys written into the git tree along with an identifier simply derived from the relay url and repo name

DanConwayDev · 2023-05-24T13:16:16Z

17.md

+  "created_at": "git_author_date",
+  "kind": 17,
+  "tags": [
+    ["c", "git hash", "recommended git URI"],


A NIP should enable interoperability for a variety of models for code collaboration over nostr.
Here is a non-exhaustive list of options could be enabled via a single NIP:

content of the commit could be retrieved by one or more git servers via a URI

the patch for the commit could be included in the event content

the content of patch could accessed via a NIP-94 (file metadata) event

The "recommended git URI" could be replaced with an array which would allow multiple options to be used to create redundancy and for improved compatibility across clients. A marker could be used as used in NIP-10.

Only option 2 is needed. The protocol can defer to the relay what to do with signed patches. So long as a client can verify it's copy of a git repo matches what the relay reports.

DanConwayDev · 2023-05-24T13:20:43Z

17.md

+
+Git events over nostr have the following attributes:
+
+**`created_at`** SHOULD be equal to git *author date*.  This is the same number format as nostr.


I don't think is like is needed as it is implied. It's often not referenced in other NIPs.

DanConwayDev · 2023-05-24T13:22:57Z

17.md

+
+**`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>"]`.  


the ngit implementation https://github.com/DanConwayDev/ngit-cli uses a initial-commit hashtag to avoid any doubt whether there is a parent id but it has just been omitted.

DanConwayDev · 2023-05-24T13:25:19Z

17.md

+**`content`** empty, reserved for future use
+
+
+nostr.json


This is an implementation detail and doesn't need to be included in the NIP. For example The ngit prototype stores an actual repo event in /.ngit/repo.json. Additionally, the standard is to store event ids in hex and present them to the user using bech32 when required.

The location of repo meta data is important if it's used for consensus

hazeycode · 2023-05-25T18:48:37Z

Why can't we just put patches in event content and add a repo id tag?

Could we use 'relay-url:repo-name' as the repo id? It can be committed to the git tree signed by user. Why do we need to generate an id?

staab · 2025-05-22T00:03:57Z

Closing due to inactivity and because I assume this is covered by the ngit stuff.

Melvin Carvalho added 2 commits March 5, 2023 17:34

Tracking Git Commits with Nostr

7b86bba

Add nostrgit to Related Work

e7a66a2

DanConwayDev reviewed May 24, 2023

View reviewed changes

DanConwayDev mentioned this pull request May 26, 2023

NIP-17 Code Collaboration #561

Closed

AsaiToshiya mentioned this pull request Jun 17, 2023

NIP-17 - Event Metadata #605

Draft

staab closed this May 22, 2025

		Status: This NIP is an early draft and work in progress. Implementations are being developed which will incorporate what is learnt.


		Introduction

		A new tag "c" will be used to store commit hashes from git a new version of the repo


		Bech32


		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`


		Git events over nostr have the following attributes:

		`created_at` SHOULD be equal to git author date. This is the same number format as nostr.


		`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>"]`.

Conversation

melvincarvalho commented Mar 5, 2023

Uh oh!

spearson78 commented Mar 9, 2023

Uh oh!

DanConwayDev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hazeycode May 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hazeycode May 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hazeycode commented May 25, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

staab commented May 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

hazeycode May 26, 2023 •

edited

Loading

hazeycode May 26, 2023 •

edited

Loading

hazeycode commented May 25, 2023 •

edited

Loading