This is a similar discussion to the one we're having about avatars on ssb: %m2QMChU... %7FSY+a3...

It's not so much about who is allowed to fork the repo, it's more about whether you should clone from the latest commit pushed to the network or the latest repo pushed by the repo author.

Right now git-ssb clones from the latest push from anyone within your friend of a friend gossip network. However, it'd probably be just as easy to only clone from the repo author.

Then we wouldn't be worried about random strangers pushing commits to core repos.

I don't know which approach is best, but we should offer people a choice about whether they want to trust repo authors or everyone in their network.

--

And yes, I have accidentally pushed to master when I meant to push to a branch on %patchbay at least once back in the day. It's fairly easy to fix that issue -- just get in touch with the primary developer and have them push a new commit that doesn't include your code.

@bobhaugen

Creating a tag with a message id in it could be useful if you want to mirror the repo externally, so that a person who gets the repo from outside SSB can locate the repo update messages on SSB.

@alanz

And it is up to a user of the repo to merge in any changes anyone else may have done, in any of the other trees referring to the same repo, and then put a new message/hash out to show that it is approved

This is not the case in the current git-ssb implementation. Currently, pushing to git-ssb is like replying to a thread, and fetching from git-ssb is like fetching new messages in the thread since you last fetched.

@joeyh

A sha1 preimage attrack would be necessary for any stronger attack.
[...]
No idea what you mean with the message ids and dags and stuff.

Each push to git-ssb publishes a git-update message. A git-update message links to previous git-update messages, forming a DAG. Including a message id with a git sha1 increases the hashspace to make infeasible the preimage attack. To link to a git commit on ssb, abstractly, use the tuple (commit id, message id) where the message id is of a git-update ssb message that pushed that commit.

@ev

we should offer people a choice about whether they want to trust repo authors or everyone in their network.

Noted.

@bobhaugen you can quote me. I wish I had better things to say. I see that thread. Best way to do it I think would be to make servers bridge between the spaces. Otherwise I think it is fine to manually quote & relay messages; we have done this for email ↔ ssb conversations. I recommend to include a link to quoted messages/threads. So for quoting a ssb message, if you include the message id (or a ssb-viewer link) then readers can find the original message on SSB to find the conversation here too, if they want to.

@bobhaugen yes, #activitypub federation https://www.w3.org/TR/activitypub/#server-to-server-interactions

I'm with @arcfide, it's hard to grasp. I currently feel a tension between following someone out of some (yet) small interest and once they follow me back they get write access to all my repos? That's begging for a Whoops or will make me really reluctant to follow new people...

White-listing write access or some kind of PR-only mechanism for more crucial once should help us a long way, I guess. Or making more project specific keys i.e. fractal identities where following is more specific.

@alanz I wonder if an evil actor could publish a poisoned blob though.

Since blobs are addressed by the hash of their content, this should also be pretty hard to pull off (for the foreseeable future)

Nice analysis. There could be intermediate solutions @keks - e.g. use gitlab to do www hosting of your final team solution.

I particularly like the idea of signing git commits with you private key, though not sure how to do that.

Part of me also thinks that nothing is going to change that much unless there are 3-4 people who really want to have a go at this community commons problem. It's massive, and I don't think it's just a thing for dabbling. I wonder about first step of having a call and mapping out the parts of this "Village" and then seeing if there are bite sized pieces we can get through in the next year

Good analysis @keks, specially from the security and social aspect.

I think a person clearly taking initiative right now to build something is @noffle, so let's follow his work and see if we can detect and discuss on early design decisions.

Part of the work is philosophical: deciding what is the meaning of names and conventions that we use, then how that affects social dynamics. I wrote a bit about this in a blog post https://staltz.com/open-source-without-maintainers.html and I plan to write another blog post about convergence versus divergence in open source and git. Roughly, convergence is merge commits, divergence is forks or branches. Convergence is agreement, divergence is extension. The GitHub social dynamics so far because it emphasizes convergence, it's "diverge a little bit so that soon you can agree", and it leads to several problems because it conflates the author role with the maintainer role (the person who initiated the project is now expected to do convergence work forever). I'm getting ahead of myself because there are lots of ideas to unwrap, but I mean that we shouldn't just copy GitHub over to git-ssb, we need to actually think how to make open source social dynamics more reasonable than GitHub.

The other part of the work is practical and looking for the right databases (SSB? Hyperdb?), looking for loopholes, solving code distribution versus solving code collaboration, looking for features that may alter the social dynamics in unexpected ways, etc.