I always imagined "source of truth" in a decentralized git solution would mean something like "top commit signed by known key". So you could pull from any repo that had that latest commit.
https://github.com/nostr-protocol/nips/blob/7db287c1b4dc309676271e90d46176f321bfc4e7/17.md is looking pretty good.
Please give feedback if you're interested in the git-on-Nostr stuff.
Discussion
Yeah I keep seeing things trying to use chains of Nostr events as distributed consensus. But what’s the point? Git already does that very well. I am trying to write up a proposal based on this presupposition.
This draft NIP doesn't do that but I had worked on a Public Groups NIP that did. I look forward to seeing what you come up with!
I’m very much in confluence with https://github.com/nostr-protocol/nips/pull/223
The commit id provides a hashed state which goes a long way in providing a source of truth but more information is needed.
How do you know whether the author of a PGP signed commit believes it is has had adequate review to be integrated into the
main branch? How do you know whether repository maintainers agree with this?
Where do you go to find the top commit?
The draft NIP proposes resolving these questions either via a centralised git repository, or by nostr events sent over relays signed by repository maintainers.
nostr events can provide this.
I’m thinking that a chain of commits signed by authors may only be merged into the “mainline” by maintainers, the merge commit will be signed by one (or more ?) maintainers. A list of maintainers and the repo/fork’s URI can be written into the git tree such that anyone can verify the repo state without looking at any nostr event.
To find the top commit, you verify the repo state communicated by the relay that you have decided to trust or that you are running.
What do you think? What am I missing?
*list of commits
To answer the first question more directly: Social consensus is adequate for deciding whether to merge a PR whether that happens over Nostr or elsewhere.
I really like this as a solution. Here are some thoughts:
1. Projects may be resistant to embedding repository metadata like this directly into the commit history. Perhaps this isn't a big issue issue. It would be interesting to gauge opinion on this.
2. All commits and merges that take over as the new tip must be PGP signed. This may be a barrier for some projects but potentially less so for projects that would be attracted to a more decentralized option.
3. The rules for transferring repository ownership must be resistant to a compromised PGP key but also a key loss by one maintainer.
4. It maybe hard to extract this information for other usages without the repo being cloned. For example a nostr client may want a list of maintainers for things such as issue and PR moderation.
We could write a git server that allows commits signed by maintainers to be written without authentication / user accounts.
Good points. I agree.
1. This is no worse than a .github folder
2. Yes. I think we should try to solve for bitcoin core project first.
3. Yes this is a concern
4. Yeah there are some “light client” use cases, I think these can be serviced by relays implementing our hypothetical protocol
PGP key management is bugging me. It’s the least clear bit. And I don’t think we can multisig commits in git without doing something hacky with ux knockon