Nostr Web Client

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.

DanConwayDev 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

Guga Figueiredo 1y ago

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.