So, git-ssb is small-world-pushable at the moment. What does that mean? It means everyone who is close to the one who receives the updates (is in their small world) can push. Is that a problem? Classic IT security answer: it depends.
Github has (had) two major use cases: allow collaboration (git hosting, issue tracker, PRs and project management) and code hosting (as in: you can find my code on github/to install go to github).
SSB is also used for several jobs: To debate, publish events or collaborate on code. However, the idea of SSB is to choose your small world such that you trust the ones inside.
So if you assume that all people in your network are trusted, you can safely pull all their changes (from a security perspective). If someone pushes code to a branch even though you agreed on a core review process that's a social problem. Yes, you could solve that using technology, but don't forget that this takes agency from the peers, and in some cases it's important to break the protocol.
Now, assume that there are some rogue peers in your network. One of them pushes some commits that look like they come from a trusted peer (I believe that is possible, but not 100% sure). If you have a strict CR policy, you'd probably revert the commits and ask the person you think the commits were from to refrain from doing that in the future. At some point the misunderstanding might come to light and the rogue user is uncovered (by digging through
git-update messages to find who really pushed those commits.
My personal stance is that this should be made harder or impossible to do. Maybe it would be nice to use ssb to sign external messages, or
git pull on a git ssb repos tells you
Hey! @rogueUser (@WeiRdID.ed25519) pushed to this repo for the first time, make sure everything is okay!
In general it would be nice to be able to see in git interfaces which ssb user pushed the commits, but I'm not sure if or how that could be made to work.
Now, as I said above, Github also is used as a code distribution platform. I don't think git-ssb is very good at this job. You currently need to be in foaf range of all (or, with ooo, at least some active) contributors, and the code authors won't be able to see that someone attacks their users because the rogue messages may be outside their foaf range (but inside their users').
However, problems like these could be tackled with independent tooling: you could have a daemon that listens for
git-update messages authored by users on a whitelist and packages all tagged commits as .zip or .tar.gz files and makes these available through http. That way you can publish the team's version of the repo securely. That would be a new point of centralization though, but maybe that's okay? Idk. Maybe you could also make new
git-release messages that say "Repo %abc.sha256 has a new version x.y.z at commit def123 -- @author.ed25519" and provide good tooling for that ( #somebodycould ;).
In general I'm not sure I buy the "they can't handle the implications of decentralization" narrative. Firstly, it's implemented inconsequentially. Repos still "belong" to users, e.g.
keks/margaret. This implies ownership, and ownership implies some control.
Secondly, If we want code as commons, this obviously break the "clear boundaries" rule that Elinor Ostrom identified in successful commons projects. Of course this is not a hard requirement, but maybe we can learn from the experiences of past generations.
For the moment, for our situation, I don't see a problem. We can all trust each other to a reasonable degree, so we don't need to bake security into our tools. I think it would be wise to make possible attacks more visible by notifying users of new users that post
But what if people who abandon Github come here? Here, again, it depends. If it's something like dotfiles or small uni projects - go for it. Same with private repos - they are secure already. But if you are looking for a replacement that not only collaborating with a small or medium sized group of users but also want to distribute the resulting code, more tooling is needed. To collaborate with a huge group of users on a single project: That seems difficult with git-ssb (because you might not know some commiters), but that also doesn't sound very decentralized.
Well, these are my idea at this moment. I've used git-ssb for a while now and for the purposes I use it for it's decent. However, I often struggle with the distribution part because of the way Go package management works. There is no central registry like npm and you have to care about hosting the code yourself - and Github is super convenient here, but with git-ssb it's a pain, especially because the public mirrors have been unreliable in the past (maybe that changed though).