Doesn't that just makes any maintainer a single point of failure? A malicious or careless actor can still cause damage, much like with regular centralized git servers. we just added more steps to verify that. isn't it?
Discussion
They were a point of failure anyway as they have permission to push to the git server.
I think the maim benefits of a remote helper are to make it easier to switch git server and make accessing propoals possible with native hit commands.
So what are we gaining by adding nostr to that flow beyond the ability to find the server?
My thinking has been going towards doing that server side, for the purpose of providing frontend functionalities, notifications, but that would have no bearing on the remote-helper transport for pushing/fetching.
Did you check out my concept? That outlines a few things. Eg submitting proposals via.`git push -u`
That is mixing git workflows and git service functionalities with core git commands, is that right? if I understand correctly, I don't know how I feel about that. my instinctive response is that pulling/pushing code should be all that the transport protocol should care about.
And I think there are more things we can do with nostr to improve UX working with git remotes hosted over nostr on that front, before thinking about adding overhead with what I consider is more a UI concern.
I'm not entirely sure how I feel about it either. I think there is a strong case for it.
Users can view open proposals using just the git tools they are used to using.
It is a nostr remote so expectations can be set as to what to expect.
Its quite easy to understand that branches starting origin/prs/* don't come from the maintainers and that pushing a branch will automatically create a proposal.
Its smoother than the github forking model and having to create PRs in the browser.
I'd be interested in hearing more opinions and trying it out in practice.
I might be on the conservative side regarding this. PRs are not first class citizens in git. so an integration of nostr+git doesn't need to have PRs.
I want to be able to work with git and nostr side by side. I see clear benefits in decentralization just by reducing friction for handling git server/service migration. And don't want to see nostr native repos become incompatible with regular git ones.
most of all, I like the idea that there are layers in the solutions we are exploring, and I'm hesitant to have protocol definitions across many layers. I don't think every good idea about how to do things in nostr need to be a protocol spec. it incentivizes gatekeeping and hinders flexibility. taking us closer to how centralized solutions work.
I am working on some ideas to improve the remote-helper I've made. Should have an update soon.