Hey, that's really cool. Have you considered submitting it for a Show HN?

Is there, at least theoretically, a way to prevent other people from pushing to my repo? That seems like it would suck re griefing for any project that might become even mildly politically sensitive for whatever reason.

Everything is key based, so only key holders push to your repo. It's all based on the SSB protocol.

I'd suggest reading https://github.com/noffle/git-ssb-intro to get an idea.

That states: "git-ssb's permissionless model has an interesting consequence: anybody can push to anybody else's git repository." The guide doesn't show any key-sharing in order to do that. Are you saying that's incorrect?

I don't want to give you the wrong answer so I've forward this question to the SSBC network for one of the core developers to answer better.

I'd be surprised if there was no security for pushes. The repos I've worked on did require an invite from the creator.

Marak It sounds like you are working with private repos. With git-ssb currently a repo is either public or private. Private repos are encrypted to a fixed set of recipients so only those keyholders can access it. Public repos are unencrypted.

Yes, so basically in a centralized permission model some authority (the database) decides if any write is authorized or not, but in decentralized, any peer just writes anything, and then the readers decide whether they interpret that as valid or not.

Here is a description of a model that embraces both any-one-can-edit with degrees of consensus on who is allowed to edit. http://viewer.scuttlebot.io/%25GKmZNjjB3voORbvg8Jm4Jy2r0tvJj... but if you decide that someone cannot edit it, from there perspective they still can, but they are just excluded from your perspective.

Your comment is entirely nonsensical in this context. I want a way to be able to publish a repo and have the people subscribing to the repo be able to only pay attention to my changes in an automated way. This software currently doesn't implement that, as far as the guide that was linked suggests. It is therefore utterly useless - every time someone decides to grief my repo, it requires manual intervention to resolve.

Once you have that very, very basic ability to replicate what people expect when they subscribe to a person's git repository, you can start playing with automatically merging together people's changes - but in practice, merge conflicts are a thing and there's no good way to resolve them. If you can come up with a way to automatically resolve merge conflicts, you'd be rich, frankly speaking.

you said > Is there, at least theoretically, a way to prevent other people from pushing to my repo?

so I answered, _yes, theoretically_ we have ideas for how to implement that. you can also unfollow and block griefers, but so far pretty much everyone has been nice and we just havn't needed to implement that yet.

How do you intend to automatically resolve merge conflicts, which is what your document suggests you want to do?

Why is this not resolved by a good permissions model and the ability to fork? Why should my users have to care about blocking griefers when they just want to pull from repo?