A global state, which is embedded into a git commit id, is antithetical to nostr
Yeah. A git repo was never the right vehicle for a set of 50+ specifications which are usually only dependant on one or two others.
This was one of the main things that drew me to development on nostr
Isn't that sort of the point of nostr? Permissionless development. You don't need a NIP merged by some centralised set of maintainers.
Apk's pgp signed by the developers and verified by obtanium would be nice. I has thought about adding a 'releases' section to https://gitworkshop.dev where maintainers could link to binaries signed with nostr keys vis nip93
Not sure what happened, just learned about it. According to nostr:npub1san22nhe59ct8pstcehav4dtkf94lkn46ltl7d30g3zzl00tg7ussgqjdd nostr:npub1mp49j02f5qmtx3svdk7kyg5dqalc9aqlqgt0f7rayx7sj3mkyl2s0y7fzr is a good page to follow on this. The developer is nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
I'm working on https://gitworkshop.dev
Dev here. The collaboration surrounding the repository is done using nostr events. Proposed changes are also stored in nostr events. This way, maintainers can change the underlying got server they are using without losing the history of the collaboration.
Git is already decentralized. All we need is a decentralized communication platform around the code.
This is what I'm trying to achieve with https://gitworkshop.dev
I can see how you could or interpret it that way. I like to think that nostr devs like to have fun and get excited about things. We sometimes get hyperbolic.
Some small projects, don't really use much of github. So i guess its somewhat true for them.
Yes, clearly a ridiculous notion at this point. Do sense that some people have that idea?
Well that is the plan eventually for ngit and gitworkshop.dev but 1) there are ongoing conversations about the spec, 2) the products are not mature enough for production use with breaking changes coming and 3) the problem space that github covers is large.
We are looking at the high impact problems first. Sensorship resistant contribution to freedom orientated projects and mitigating the disruption a project ban would have by moving the collaboration off around PRs and Issues.
I havn't heard any talk yet about using ci tools via DVMs or alternative solutions for many other aspects of githubs offering.
Git does lots of clever things behind the scenes to reduce space usage and makes pull, push and clone low bandwidth. You lose that somewhat if you are storing each commit as a file.
My original ngit prototype operated on a event per commit basis. I considered nip94 for storing large commits. Storing files is less easy with nostr. HORNET seems interesting. For file storage on nostr, paid for through micro payments.
Did you post the link using a standard social nostr client? Rather than a ngit or a gitstr with their special event type inviting patches?
Its trivial to move from one git server to another as they all do the sane thing and speak the same language. Github acts as a git server but its main value proposition is a collaboration layer on top.
Contributors propose changes (PRs), there is discussion and comments on code, further changes are proposed, etc. It also widely used for tracking issued which is heavily integrated to the PR system.
Many contributors get band and can no longer participate. Projects also sometimes get band.
Its much harder for a project to move the collaboration and issue tracking to another system than the git server.
Yes. There are a few problems to solve related to publicity. Perhaps we can carve out a niche for freedom tech projects and create a network effect for that.
Nice. Which client did you use?
The merkle DAGs approach is interesting. It will be interesting how they apply it to git.
Its good that many of us are coming to similar conclusions.