The idea is to use the git project's git server implementation with a nostr authentication layer. I think the is consiatant with the 'let git be git and nostr be nostr' philosophy. The on-boarding should be better but you are right that I'll be be debugging it for decades.

Replies (4)

Trying to build 2 nostr clients on different tech stacks simultaneously has meant I haven't been able to make the progress I would have liked quickly enough. Maybe maintaining a third would slow down progress too much.
Vitor Pamplona's avatar Vitor Pamplona
Was I wrong? I always assumed that specialty clients should be able to easily outperform Amethyst on the quality of the features related to their specialty. Users would gradually move away from Amethyst as more and more specialty clients move forward. This culminates with a slow death of Amethyst, but towards a more exciting and decentralized future for Nostr. I have accepted this fate since the early days of the super app project. This assumption was based on the fact that our development team would simply not have the resources to dedicate the same level of attention and support to every single specialty within Amethyst. It has been one year and I am sad to report that I have been proven wrong over and over again. For some reason, developing specialty clients is harder than developing the same features inside of Amethyst. And that is a loss for decentralization.
View quoted note →
A good way would have been to add #pubky which is git native identity and signatures, using ED25519 keys, tied to nostr identity. Another good system would be NIP-98 to log in to say gitea/gogs/gitlab. You also get free SSH, and commits, out of the box, for free. Key is to let each tool do its thing and expand the network effects. Then with a few tweaks you get enormous new functionalities. Git does come with a very basic server, yes, I've used it a few times, but it'll require a lot of support, and lacks alot of features. We were discussing this problem and using ngit for resilience with the Agentic folks today. I think in future there will be a an offering for humans (high support) and one for agents (low support).
When you mentioned pubky before as a native git identity before I looked into it but couldn't find any information about how to use it for git. Can you link to a getting started guide?
The alternative git server implementations all have social collaboration layers (PRs, issues, comments, etc) built in which makes for a confusing UX for on boarding maintainers and for users stumble upon them via these git services repository pages.