From feedback such as %xFLWjn3... %EScsW7M... %tAMTiaq... %ud0UEgh..., I am thinking maybe to change the default behavior for git-remote-ssb and git-ssb-web to accept git updates to a repo only from the repo author (the original behavior), rather than from anyone you know (the current behavior). But what about people who have been making use of the current behavior for collaboration? Offer a choice to the fetching user for the different behaviors? This could be done as a config option and/or querystring parameter on the repo URL. Would that be an improvement over the current situation?

I will consider implementing proposals in this area that are clear and have substantial community support.

cc @cryptix @keks @mix

I don't think we should be hasty to conform to the github norms, I think it's interesting to explore this space.
I am totally fascinated by the idea that something could be fundamentally more our thing than my thing.

How about :

• the default is that people I follow can push to my repos
• if someone does push to my repo, the UI helps me understand
  • e.g shows their edits, but a big alert that this has happened
  • e.g. shows my master, but suggests there's another master based on some remote edits
    • this would be like a 'fork' of the repo with a different master in github.
• if I publish a message saying "Yeah Cel is totally LEGIT, let them edit any of my repos/ this repo" then there are no "forks" or alerts, and cel and I essentially share the repo
  • this begs the question then "Is cel then an owner .. i.e can they transitively extend this write permission out to other people"
  • this sort of "permission" system sounds like a standalone message type / system which could be really amazing in general. e.g. "cel can totally edit any gathering I make", "cel can edit anything I make"
    • THIS would be the foundation for a much richer definition of trust.
    • e.g. spectrum of trust from I'll replicate you ...... We share everything

cc @dominic re THE VILLAGE ^^

@cel A simple config option would work for me. trustAuthor: true or something like that.

The way git-ssb works right now works for me. But, in the off chance someone attempts to push malicious code to a repo, it'd be a good safety to be able to fall back to the repo author until the conflict can be sorted out at the community and/or protocol level.