https://github.blog/news-insights/company-news/an-update-on-github-availability/
git is a remarkable piece of technology that was designed to be decentralized out of an understanding that centralized systems are brittle and represent single points of failure
github effectively undoes the benefits of decentralization. we can do better, the future does not look like this.
@nasser I just wish git had more standard tools for code review via email chains
@mauve yeah it's the main missing piece. email chains aren't the answer. I'm prototyping something based on automerge that runs locally that I think has some promise.
@nasser I think email chains would be fine if there were more standard views over top of them TBH.
Why not use https://radicle.dev/ instead of making another standard? 😅
@mauve I'm working on something I think is different and simpler. bottoms out in a crdt file per issue/merge request/ticket that gets stored into the repo and reuses existing hosted repository infrastructure for distribution. ie you should be able to use codeberg while I use source hut and we should be able to collaborate. the tool opens a local server that presents a web interface. it's more like git bug than anything.
radicle as far as I understand had a more involved bespoke p2p protocols with seeder nodes, which isn't what I'm getting at.
@nasser I like that! Whatcha gonna do for access control? are you gonna add a hook to automatically fix confflicts in the crdt file when someone does a pull/merge? Are the forge crdts going to be in their own branch? I'm guessing p2p nuts can just add a p2p remote to pull/push to if they want to sync with others.
@mauve access control is similar to what I've been experimenting with in SAWA which effectively bottoms out in a kind of namespacing, in this case the remotes are the namespaces. locally you can track whatever remotes you want, some of which may be your own, some of which may be collaborators. the issue branch referring to the crdt file lives on every remote. git fetch will pull them all in but we don't have to proactively merge and update your local state. just having access to everyone's file is enough the present a merged view in the local web UI. if you take action like editing or commenting on the issue then you'll build on that merged view and you can commit that locally and push it out to your remotes.
no signaling planned but I think periodic git fetch might be enough? and yeah if people want to build something more elaborate and p2p they can, it's not foreclosed on, just orthogonal
@nasser That's awesome.
> git fetch will pull them all in but we don't have to proactively merge and update your local state
I like this bit!
So multiple devs pushing to the same remote will fetch it, and will use your tool to add changes over top before committing and pushing back.
Seems easier to reason about that the "git as object store" stuff radicle and gitbug do. Also you skip some of the perf issues of oplogs.
I'd love to beta test /review it when ready if you'd like 😮
@mauve that's exactly the idea 🙏 discovering force push with lease in git was the real game changer. the storage overhead shouldn't be more than the crdt file which is compressed (it's automerge) and old objects can safely be deleted by git gc. and yeah would absolutely love feedback once I have a prototype esp from someone principled and versed in decentralized computing!