#[3]
I think the way this bounty is stated is put is not the ideal. I think most people will read this and think we need a big website that is just like GitHub but using Nostr somehow. I think that is not what we should see (and hopefully that's not what #[1] wants either).
What I would want to see are multiple apps that can interoperate and are able to perform separate functions:
- browse code
- comment on code (referenced by a commit)
- create issues and comment on issues
- send patches
- comment on patches
And how these should be done? I am not sure, but here's what I have in mind:
- most of the comment things should probably be kind:1 events, I don't know, with some extra tags (so they could be interacted with from the normal "social" Nostr clients? or not?)
- code should probably be hosted by standalone dedicated git servers -- and there could be centralized providers offering these services but they should interoperate seamlessly between themselves and with standalone personal servers
- sending patches should probably be done using something like this approach by #[0]: http://git.jb55.com/git-nostr-tools/file/README.txt.html
#[2] has opened a discussion on this topic on the NIPs repository that could possibly be used to coordinate the efforts: https://github.com/nostr-protocol/nips/pull/223
I think we could have multiple different smallish webapps, native apps and specially command-line tools that implement one or multiple of the separate functions described above, and with that we can achieve a much better result both in terms of quality and of decentralization than if someone or some big team decides to tackle the entire cake and come up with some centralizing architecture on their own.
Does the author of that bounty really know how git works and realize that git is already decentralized?
Emailing patches is one of the main features that Linus wanted when he wrote git. Replacing email with nostr is already being done with git-nostr.
The problem of who gets to decide what to merge into Bitcoin core is not going to be solved by putting it on nostr.
It’s the seamless experience that is capturing. Why do so many people use GitHub? I would argue it’s because of the friction it removes from the many git related tasks. Emailing patches is fine but not something everyone is comfortable with due to the “extra” steps needed to compare/diff, and discuss the patch. There’s user friction involved. GitHub and other git context providers have greatly reduced the friction for these processes as well as consolidated them into one place with other tooling. This value add cannot be understated. I can email you a patch, but that does not provide visibility into any CI/CD I’m running. Nor does it connect the patch to an outstanding issue.
Link to git-nostr?
Yeah this is just a hack though. I think to fulfill the bounty it would need a really good UX, pull request support, code review, etc. web UI for managing issues for users, cli clients for devs. Lots of work to do! I’m tempted to do it but want to give other people a shot first. If I’m not happy with the solutions I will consider it.
I think we need to define the desired outcome.
You could for example create a constraint that a branch is a pubkey, and only the private (or aggregate private, Schnorr, MuSig, etc) can merge to it (git already has signed commit hashes). That would allow replicating branch permissions.
^^ I think we should discuss and jack should settle on a design outcome like this.
Since git works with hashes, it's not hard to reference specific lines, commits, branches, etc and that's all that would be needed to add review notes.
Like you said, clients would then aggregate those notes into a concise view.
Thinking more about it, I think hash-chain branches are step 1 that is needed.
Extend git to support hash-chain branches, where the branch is a pubkey (can have a readable alias), every client can check every merge into the branch is signed by the privkey.
- where the privkey can be an aggregate key (schnorr, MuSig, etc)
- where the merge transaction can be signed and broadcast (on nostr) allowing every client that has all the commits in it's repo to reproduce a deterministic merge (same outcome everwhere)
👀
#[0]
💯
Yes I def know it’s already decentralized and how it works.
However, bitcoin core has a current dependency on GitHub collection of tools and interfaces. This seems fixable. I think fiatjaf lays out the most critical needs much better than I did.
When you just wake up, your client doesn’t pull the profile name and you type an answer referring to “the author” and then find out it’s Jack 😅
Anyways thinking about it further I think one interesting component would be hash-chained signed branches with multi-sig keys.
#[7]
