Standard Idea: Delegation for Community Subgroups

[zicklag.dev]

@brittanyellich.com This idea is pretty raw and hasn’t baked long enough, but I was just reading your post here:

@brittanyellich.com

I don’t think that the group management layer should be required. Applications can very likely allow the creation of groups without requiring any integration with a group management layer. For example, Bluesky communities could be created just within Bluesky with a basic group management setup just managed within Bluesky that allow folks to handle the moderation of a basic public group. However, if a group grows to the point where they need more structure, then I’d also like Bluesky to be compatible with whatever contract we come up with for atmospheric groups so that those could also be surfaced as Bluesky communities.

This makes a lot of sense to me, but then I had a thought:

If you create a community on Bluesky and then you go to another app and you want to create a subgroup in the same community, for that other app, it would be nice to be able to do so, even if Bluesky doesn’t know how that other app would want to manage the new subgroup.

It’s hypothetically possible that in many cases, you might want to create subgroups ( i.e. permissioned spaces ), from a specific app, that are managed by that app, just like we’re talking about creating a community inside of Bluesky.

What if we had a standard for creating a subgroup under an existing community, and delegating the responsibility of creating the space credentials for that subgroup to another app’s endpoint?

The motivation is to avoid having to either:

1. Migrate your community from Bluesky to a fully-fledged management app like Roomy just because you want to create a new subgroup that is incompatible with the basic membership model, or
2. Create another community in the new app, even though it’s logically the same community, because the new app needs to keep the membership list private and Bluesky doesn’t support that or something like that

Hypothetically, the new app that needs more control over a specific group, could ask that Bluesky create a new group, and forward all space credential requests for that group to an endpoint controlled by the app.

Basically delegating control over that subgrup in the community.

---

I think this could possibly simplify things sometimes, but at the same time, it might just complicate things more at times, and be hard to surface to users in an understandable way.

Not totally sure, but figured I’d throw the idea out there even though I haven’t thought completely through the implications.

It’s worth noting that this pattern is something automatically possible and “built-in” to the Arbiter, but maybe this simple delegation pattern makes sense as an alternative “mode” in the simple group management API that Bluesky might support.

[brittanyellich.com]

Repeating this back with a concrete example to check my understanding.

Setup: I’m a member of ATProto Folks, which right now exists only as a community on Bluesky. Walking through what happens when I try to use it elsewhere:

1. I go to Roomy and want to spin up a Roomy chat for the group and set up a few channels. Roomy needs a permissioned space created under the DID on the ATProto Folks repo, as well as details like what channels it has, which means I need the authority to create those on behalf of the group. I think that this is the delegation you’re talking about? Some sort of way to ask generically “hey can this user do a new thing?” to the managingApp

2. If ATProto Folks is surfaceable from another app (publicly, or through a private record I can read from my own repo), then all the data I’d write into this space for my messages already lives in my repo.

3. Zicklag shows up to Roomy from ATProto Folks. Roomy would check the membership list again from the managingApp to know that a) Zicklag has access and b) the membership list is [Brittany, Zicklag], so those are the repos to reach out to for data other than the group repo. So it shows Zicklag the channels and details I set up and whatever I wrote already.

[zicklag.dev]

@brittanyellich.com

I go to Roomy and want to spin up a Roomy chat for the group and set up a few channels. Roomy needs a permissioned space created under the DID on the ATProto Folks repo, as well as details like what channels it has, which means I need the authority to create those on behalf of the group.

No, not quite, I mean:

1. I’m an admin of a community created on Bluesky

   • The “admin” functionality is built-in to Bluesky’s space host so that I can create spaces, etc.
   • “Normal” spaces created on Bluesky have simple member lists to determine access.

2. I go to a nifty app called gh-access.at and I use it to create a “delegated” space.

3. Instead of Bluesky using a member list to determine who has access to this space, because it is a delegated space, all requests for space credentials will be proxied, in the background, to gh-access.at.

4. I configure gh-access.at to grant access to any user who has a keytrace showing that they have a GitHub account that is in a specific team in my GitHub organization.

5. Now anybody with an ATProto account that is mapped to a member of my GitHub team is automatically allowed to access any data in this community space.

6. This works even though the community is hosted by Bluesky’s space host, which doesn’t natively support that kind of access customization.

Conceptually, it’s kind of similar to setting different DNS nameservers for a particular sub-domain.

---

PS: this kind of scenario walkthough has made me realize how useful these might be for building consensus and helping make things understandable.

Like it could be good to somehow collect / curate a bunch of these kinds of scenario walkthoughs to serve as grounding for conversation somehow.