what is the argument to reduce git servers role? I am being conservative about replacing things that work natively with git to reduce friction when migrating between solutions
I've been thinking about how to improve #GitViaNostr
* make it more git native experience
* reduce the role of the git server
* integrate releases
Here is a concept ngit quick start guide: https://gitworkshop.dev/concept
I'd love your feedback
I've already started to build out some of the new features
nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn nostr:npub1uplxcy63up7gx7cladkrvfqh834n7ylyp46l3e8t660l7peec8rsd2sfek nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Discussion
I have been reluctant to replace core aspects of the git protocol as it is so battle tested.
Having a single git server that everyone pulls from isn't part of the protocol.
Its a point of centralisation and failure.
You have to trust that the operator is passing you the correct refs (as these are not signed although he commits maybe). Whats stopping them from pushing different commits to specific users or user from a specific country?
There is friction if you want change operator (as you need to coordinate with all the repo users to ge them to pull from a new url)
We also are trying to circumvent gitservers. That's an unnecessary centralizing factor that wasn't part of the original git vision.
We have a solution for getting around them.
I'm keen to understand it.
Are you planning on hanging comments off an event that points to a remote branch for proposals/PRs?
Are you planning to track refs on nostr or leave that to the git server?
it shouldn't be hard to integrate git shell with anything, including a relay
what i want to see, though, is ephemeral events that contain the pack message normally sent over SSH or via HTTP, so it needs a new nostr:// protocol handler
I'm not sure you what benefits you can from sending the pack over nostr. It could be quite large. If its signed by the relay then you are trusting the relay rather than the maintainers.