Screw it, i'll jump on the train. Noting down my thoughts here as I go down the doc.

By not standardizing them, we leave the freedom of implementation up to community stewards.

Ugh. That'll make things difficult between apps. I'd much rather have this figured out as a standard right away, instead of everyone tinkering away, then having to consolidate all that. I think it's one of the cases where restrictions might inspire creativity.

I do get now why @erlend.sh said that "community" would be a bad descriptor, too. Just thought of that randomly.

Roles are the interesting part for me. @essentialrandom.bsky.social I don't know if you got around to my roles question from yesterday, so here it is again:

What happens when I have a role which one app wishes to use, and another does not? Imagine, for example, a steamplace/colibri community. There's a moderator role which is applied to users who are mods, but there are also more roles for normal users in the Colibri community. How would those two apps agree that the one role does X?

My best guess is that the role is just a "this member has role Y" declaration, then every app does with that what it wants? Also, how would different apps identify roles with the same purpose? This feels like a "we're falling back on Bluesky's convention" thing again.

they do so by holding an OAuth credential for the community DID

What would this look like in practice? Do I oauth to the space host, get a service auth token or something? I'm yet to read @zicklag.dev 's comment, so that I don't get spoilered, but yeah this is pretty confusing still. I'm assuming the "community service" isn't the space host, so in that case, the active atproto session would request a service auth token, then the app checks the roles, deems whether that's fine, then issues the token?

Instead, each user who is interested in receiving invites to communities hosts an invites space under their own DID, and a community writes an invite record into that space.

Yeah that line is very confusing. I'm assuming they mean they host the space themselves, then the community writes to its own space host internal space (or pds space or whatever)?

In other words, the inviting community writes the record and can’t read it back

Interesting, so you wouldn't be able to tell that record was ever there? Wouldn't that mean you could accidentally spam invites if the record key isn't stable? Is the key always stable?

A community may implement arbitrarily complex governance, including things like voting and holding periods for certain actions. This is all considered out of scope for the community standard.

I imagine in those cases, the application would enforce this governance? Or would the space host need to support it?

community.opensocial.permissions Binds roles to actions

Actions related to the space host? Not to apps, right? The apps decide that themselves based on the role, the ID, plus their own config? I keep coming back to how apps negotiate what roles mean the same, otherwise you end up with multiple moderator roles for different services, which may not be what you want. But I imagine it's common that your streamplace mods are your colibri/roomy mods.

Opinion time!

A note on naming

Phew, tough one. Random idea, we keep calling it communities for the spec, but offer people to label it something else? Maybe you can be a "community", "group", "gathering", whatever, then that gets displayed on the OAuth screen? Localization will be hell, sure. But I get the point of wanting a pretty oauth screen.

Can we think of ways to smooth over the UX of needing to go through an OAuth flow in order to create records on behalf of a community DID?

The space host should have endpoints to compute permissions, the active user just requests a service token based on what the space host or app deems correct. OAuth flows suck, service tokens issued silently in the background work better here imo.

alternatives to the above that are secure and legible to users

I think in most cases users don't even expect to see them? When I'm an Admin for a community, and I want to make a post as the community, I already expect to have that permission because I am an admin. If I have to auth again, what's the point of a role that apps can work with?

Some of the methods could probably be ditched and instead just captured as normal record writes (for instance updateProfile). What’s the right line to draw that at?

Anything that requires more than one write is a method, single writes are exactly that?

The invite space requires anyone to be able to write into it but only the user to read from it. This isn’t configurable in the current alpha implementation. It also opens up an inbound spam vector. Do we like this model? Is there another way to model this?

Called it. Lol. Uhm, yeah, tough as well. I think maybe these should be readable by people with the permission to create invitations, so they can retract them as well. Then each invite is also keyed deterministically, so you can't get spam-invited from a single community. The only case I don't see here yet is "public invites", but I guess those could be posted to the community's own invite space? Or something? Open to suggestions.