I like (2)

I don't think (1) is needed so much once we implement good indexes.

I think that (1) could be a good pattern. I was thinking about this with Ferment too.

scope and related attributes would allow us to decouple the sbot feeds used for git vs social.

It means the two apps could be served from different sbots and simplify integrating and coordinating all of the different opinions about what plugins should be installed. I am really not a fan of global sbot.

(2) feels like a general permissions problem not specific to git-ssb, so i'd rather we handle that with a more general fractal indentity permission / capability solution. might be as simple as a new about message property like owners.

@customdesigned You could probably accomplish (1) easily, but I'm not sure if I'd use it myself. You'd need to modify git-ssb and ssb-keys to use a different secret when you're writing git commits. I'm not interested in this, because I think it's cool that my commits are under my own identity.

2) has been long on my list of things to figure out how to implement, but no one has made a stab at it yet. I've at least once accidentally pushed to master on someone else's repo when I was meaning to push to a branch. I'm not sure if a list of names of allowed people is quite the pattern we want to use here though? Part of the issue is we haven't quite decided how to solve this problem, and also give us the most distributed freedom.

@Matt

I am really not a fan of global sbot.

You can always use a different network key for Ferment. I did this for Decent for awhile.

Yeah, but then you have to run your own pubs. That was what got me into trouble last time and what I'm trying to avoid.

@matt makes sense. I just stumbled onto the thread on scoped feeds and I'm trying to wrap my head around how it'd work right now.