Nostr Web Client

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?

DanConwayDev 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

hazeycode 2y ago

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

hazeycode 2y ago

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