In a previous leaflet we have a deep dive on how the arbiter works.1
Bluesky's permissioned data proposal has the concept of membership, but leaves it to the app to orchestrate it. The arbiter is our idea for a general-purpose, interoperable ATProto group membership service.
In this leaflet I'll give a much shorter overview, as well as a progress report on our spec & implementation work.2
Overall Idea
The goal is to provide an interoperable standard service for group membership management. It is a relatively unopinionated layer on top of permissioned spaces.
Permissioned spaces defines the least common denominator for groups on protocol: a flat membership list. The arbiter is a space host providing a more opinionated, but still generic way to calculate and manage the member lists for multiple permissioned spaces within a community boundary.
The arbiter’s DID acts as the community boundary and provides a standard API for creating spaces and managing their members. The goal is to be an interoperable API for managing the membership of public or private communities and groups on ATProto.
It is spiritually quite similar to @brittanyellich.com’s opensocial.community, but built on the permissioned data proposal, and with a more sophisticated role-based membership system. We're coordinating with Brittany for our two tracks to culminate in a joint effort.
Roles & Membership Summary
In every space, the arbiter keeps track of a member list and an access level. The access level controls what you can do in the space and there are levels such as Member, AddMembers, and RemoveMembers.
The arbiter has a built-in $admin space, where the members of it are automatically added to every space that is created on the arbiter.
It also allows you to create spaces that act as roles. To use a chat-room as an example, it lets you create roles like Moderators, Devs, and Members.
These roles can delegate to each other saying things like "Everyone in Moderators should also be added to Members with up to RemoveMember access."
This allows you to easily create channels such as #general and #off-topic that, with one delegation, automatically inherit all the normal members of your space, and the moderators.
You can also delegate to spaces on remote arbiters. This allows for federated spaces.
Below is a hypothetical example of what this might look like in a group chat scenario.
I think I'm going to try to make an arbiter simulator web page soon so that you'll be able to interactively explore how the arbiter processes access levels and allows you to compose groups and communities.
Separation of Membership from Other Semantics
I think the arbiter, inspired by the permissioned spaces proposal, makes a useful separation between membership and other semantic details.
For example, while read access is governed by the arbiter and its member lists, write access and other access control is managed by the AppViews which have an understanding of the lexicons of records in the space. These AppViews can also attach their own app-specific permissions to roles on the arbiter to create ACLs.
The arbiter itself though, is application agnostic. This allows us to develop semantic standards around groups, in the vein of standard.site, like @dholms.xyz mentioned here, independently of the core group membership API.
If you need more sophisticated control over membership, it’s always possible to just grant your app, or maybe a separate invite service, permission to add or remove members in all spaces, or just in specific ones. This lets you manage membership with your own custom logic, while still benefiting from the role inheritance and federation features.
Similar to how the arbiter expands on permissioned spaces, we are planning on adding an invite service extension to the arbiter later, so that apps don’t have to implement invite codes, etc. by themselves. By making this a separate API, we keep the arbiter simpler and less opinionated.
Implementation Progress
I have an almost completely finished Quint specification of the arbiter. This is an executable specification that is essentially a full implementation of the core logic, but without an actual HTTP server.
I have also started on a Rust server implementation.
The Rust implementation will include a sans-io state machine core, which can feasibly be compiled to WASM and used from JS, or have C bindings written so that it could be included into any other programming language. The extreme portability means it should be easy to embed into other AppViews or PDSes if they want to include the arbiter functionality directly.3
Getting Community Feedback
We want the arbiter to be able to satisfy as many different apps' group management needs as possible, so that different apps will be able to edit and create groups in a community, if the user has access to it.
The hope is that you can create or join a community space in one app and be able to join the same community in another app, sharing all the roles, groups, and members between the two of them. Essentially getting the same kinds of interoperability for private data and communities that we have in ATProto for public user data already.
I know that a lot of people are already making their own group solutions, but this is the first attempt we know of that is aiming to be fully compatible with the permissioned spaces proposal.
We have been looking at existing options and talking to different people to try and get a good understanding of what is needed.
We evaluated stratos.zone and chatted with .4 We had a call with and got some valuable perspective about opensocial.community's use cases. We also chatted with and got a better idea of how they are managing communities in Acorn.5
Permissioned Data Preview Implementations
We've been having conversations with from happyview.dev and who is making Contrail. HappyView and Contrail are services that make it easier to make an AppView, and they are both including a "preview version" of permissioned data.
We're all trying to figure out the closest, interoperable thing that we can do with the permissioned data proposal, while storing the data on the AppView instead of the PDS. That way it's usable from existing PDSes that don't support permissioned data.
Roomy will be taking the same approach for permissioned data as soon as we can.
We also hope to have the arbiter be compatible with both Contrail and HappyView once I get the implementation finished.
Looking Forward to Collaboration
Last Friday I got some draft lexicons for the arbiter's XRPC API up. We want to get ready to publish the API as a community standard soon so people can start building experiments around it.
A couple of days ago I chatted with who is doing interviews around the ecosystem to prepare a summary of many of the different private data solutions that are shaping up right now.6
Yesterday we had a meeting with the folks from who are working to provide services to enterprises who could benefit from ATProto for their internal company workspaces. It looks like they might be able to use the arbiter and integrate it with their enterprise account system.7
Finally it's been heartening to see the comments from who wrote the permissioned data proposal and who has been a huge force in the ecosystem and is now protoyping a PDS8 that implements permissioned data in its draft form.
I *really* enjoyed reading @zicklag.dev's post. It aligns nicely with some work that @kobi.bsky.social was exploring regarding multi-party signatures, and the broader direction of using sub-spaces for management data.
have you seen @zicklag.dev's arbiter proposal? zicklag.leaflet.pub/3mjrvb5pul224 i like that direction of thinking. & i think governance handled by an arbiter or something similar will suffice in most cases. if you need to go one level deeper, maybe shamir secrets for rotation key?
Summary
In short, we've been talking to lots of people and things are looking promising!
We're closing in on having a working arbiter server, and all of our discussion so far has seemed to indicate that the design makes sense for most of the scenarios we can find.
We're thinking about ways to let people get hands on with the arbiter soon, in either a simulation or a live server with an experimental UI for creating real groups & spaces. We want to be able to play with so we can find issues and make it easier to explain what we're going for.
Hopefully more on that soon!
Update: Interactive Arbiter Simulator!
We now have an interactive arbiter simulator that runs the actual Arbiter server core logic to let you test different permission setups in the browser!
The demo runs the actual arbiter core state machine that we are developing for the server, compiled to WASM, and with network messages simulated by the web app. This means it performs all the real access & permissions checks just like the server will.
You can create as many users and arbiters as you like. Every time you try to resolve the member lists or change someones permissions, it does it as your currently selected user. If that user doesn't have permission to do what you are trying to do, you will get an access denied error.
You can even create configurations and then share the link so other people can check it out! Here is one similar to the setup in the diagram above.
Having the simulator has also made me realize that it's still a lot to take in, so I'll probably try to make a video tutorial for it soon, too!
Having the simulator has also been good for security already, because it helped me realize a weakness in the spec that would allow you to leak member lists that you shouldn't have read access to. There might be other strange scenarios, so feel free to try and find pathological edge cases!
Feel free to ping / DM me here, in the atmosphere community forum, or in our Discord server if you have questions or find issues!