Thank you for writing this, Daniel! I spent today (and some of yesterday) going through it on stream, and I overall really enjoy the ideas there. The meeting is soon, but I thought I’d leave my questions anyway.
Also, here’s a few diagrams:
Some points of confusion pt.1: Terminology
-
Space Host vs Community Service Are these the same? Spotted the second one in the “Writing as the Community DID” section says:
If a user (for instance a community admin) wishes to write as the community DID, they do so by holding an OAuth credential for the community DID and writing that record to the community service. The community service will support all com.atproto.space.* CRUD methods.**
-
“ejecting a member”: does this mean removing a member’s role?
Two actions - assigning a role to a member and ejecting a member - are parameterized by the roles that they apply to.
-
community.lexicon.calendar.events:If a community wants to enable event applications, it might create a
community.lexicon.calendar.eventsspace. Allcommunity.lexicon.*records will then be published into this modality-specific space rather than into a universal “community” space.I’m assuming this meant
community.lexicon.calendar.*records? (Also, on stream we ended up calling the events spacecommunity.lexicon.calendar.happeningsto make it more clearly separate fromcommunity.lexicon.calendar.event.)
Some points of confusion pt.2: Tech stuff
Community DID Delegation
- When you act as a community DID, that means any written record is added to the Community’s PDS, correct?
- Is this type of “OAuth delegation” already in a spec? or is this something we need to special case?
- Can a single OAuth flow grant both User and Community DID permissions?
Declaration Record:
- Do we have any existing implementation of this? any suggestion on how it may look?
Broader concern #1: “Special” Roles
If “the Bluesky app will likely special case the roles admin and moderator”, could we use NSIDs/namespaces there?
I could be convinced that community.opensocial.roles.admin could be a standard role. But I do believe that only pain lies in giving a generic ability to special case a “moderator” role, and even more pain letting people starting to ““take”” names from a non-namespaced set.
Also, if the goal of special-casing admin /moderator is “special UI affordances/badges”, could we decouple those from roles? Less of a concern if we are namespacing the roles, but I’d love to be able to reach out to a “badged member” concept without needing to hardcode it.
Broader concern #2: Roles & Profile
(Also feeds into the next)
Each community has a profile that it publishes in its about space […] and includes records describing the rules of the community.
- Could we make rules Lexicon be just a textual field, with a pointer to another record to learn more?
Broader concern #3: Moderation
This spec adds a moderation layer I have quite a few questions about. Most “pressing”:
- “Each community is also a moderation service” is a statement I’m not sure how to parse. What does th is mean, specifically?
- Labels are published as records by the community DID in the same space as the content. Why same space? I haven’t thought too long, but it does make me want to experiment with having them be in a different space
Overall… I really, really think moderation should be its own (sub)working group. This has the risk of becoming a whole other spec all on its own, and I’m sure we could get folks together who specifically care about this. We probably have enough!
Your questions:
A bit late, so I’ll answer more tomorrow, but re: the “do we like the invite model” question… yes! I love it, personally. It’s one of those things you think it’s very weird, until you see it in action and then it makes perfect sense! I will do weird stuff with that model though 
Thank you for your hard work! Excited to build on this.