It's bee a while since my last arbiter progress report. At the time I had just started a pivot to a new, policy-based arbiter design, and soon after that I made the first successful test of the idea:
It diverged quite a bit from the previous, more specific design, which had a built-in access levels and "roles" system. Now all those things could be completely customized through "policies", eliminating a lot of the risk of getting locked into a sub-optimal design.
After the successful test I had to pivot my attention to helping ship a Roomy Discord bridge ( and more! ) and I hadn't had as much time for the arbiter again until last week. Now I've got a clean up prototype of the arbiter running live!
The New Arbiter Prototype
The prototype is running at manager.arbiter.muni.town, but it's mostly a demo right now and will probably not stay at that link. It's also very work-in-progress and not very friendly, so use at your own risk!
That said, it's working! I'm excited to get it out so we can start testing it out and figuring out what we can do with it.
What Does it Do?
Before I go through all the the technical details, lets just see what you can do with it!1
While there are other ways to leverage it, the most obvious thing that the arbiter lets you do right now setup community / organization accounts so that you can manage them from other accounts, while only granting the other accounts specific access to the org account.
You'll be able to create new "arbitrated" accounts later, but for now we assume you have an existing account already that you want to let others control, so we can go to the manager and click the button to setup an existing account:
Note: Please forgive the placeholder verbiage which is not all accurate and the UX rough edges. This is extremely early and unpolished. Y'all are getting a sneak peek of what will hopefully soon be possible.
This will bring you to a little setup wizard. Click "Get Started" and you'll be asked to login as your org account.
You'll also need to create an App Password for your org account so that the arbiter can act as your account. You can create an AppPassword in the Bluesky app if you're setting up a Bluesky account.
Then you'll be asked to choose an admin account:
This is just another user account that will be setup with full access to do anything under the org account in the default policy. You can change the policy later.
Once you complete the setup, the account is hooked up to the arbiter! To test it out, we can logout ( since we are logged in as the org account ), and then log in as the admin that we selected.
This time when we sign in we're just clicking the "Sign in with ATProto" button. Once we are logged in it will bring us to a page where we can select a community to manage.
Enter the handle of your org account and it should pull up the organization's policy:
The policy is written in the Rego policy language and is extremely flexible. The default one merely allows all requests sent to the PDS by the owner or the org account itself to go through unchanged.
As a minimal test there's a "Debug" tab that we can use to try and send a Bluesky post under the org account:
You can customize the JSON and, only if you have access according to the policy, it will let you create the record under your organization's account!
Technical Details & Future Plans
So that covers the very basic overview of what the arbiter is doing, but it only touches on the bigger problem that we are trying to solve generally with the arbiter:
There isn't a good, standardized way for applications to act on behalf of organization / community accounts while logged in as their own personal account.
If one single app wants to act under your org account, maybe it's not that big a deal to give it an app password so that it can do what it needs. But what if you want to allow other people to do only certain things under your org account? What if they want to use a different app to do it?
Giving out App Passwords to every app that needs to access your org account is not a good solution, and it destroys the nice property of the Atmosphere that we can chose the apps we use to access our data.
The Arbiter as an XRPC Proxy
The arbiter addresses these concerns by making an extremely simple lexicon town.muni.arbiter.proxy, that allows you to ask the arbiter to execute an XRPC request on behalf of an arbitrated account.
It doesn't matter how this is implemented to the app. It's just saying "I want to do this as this other account", and this is important because it means other people can implement totally custom arbiters.
When an app wants to act on behalf of an org account, it will check to see if the org has a town.muni.arbiter.service/self record. That record contains the DID of the arbiter server that we should send the proxy request to.
Significantly, we never need to log in as the org account to send proxy requests. So we can also manage multiple orgs from our single, personal login session.
Policies Are Stored on the PDS
One of the great things about the latest arbiter design is that all the policies are stored on the PDS! The only thing not stored on the PDS is the App Password that the arbiter uses to make requests under the org account.
This means that migrating to a new arbiter server, maybe one that you choose to self-host for extra security, is really easy. All you need to do is go through the account setup with a new App Password on the new server. It will load your policies from your PDS automatically.
Difference Between Tranquil's Account Delegation
The Tranquil PDS has an awesome feature where you can let other accounts login as an "org" account. This is very handy and awesome, but it's worth pointing out the difference it has from the arbiter.
The arbiter never lets another account get a login session for the org account. It's specifically designed to enforce policies that may be based on who you are in your personal account session, and it can be much more expressive than OAuth login scopes can, possibly investigating the particular values of the JSON of the request you are submitting, or even making HTTP requests to other endpoints before deciding whether you are allowed to take an action.
This has advantages and disadvantages.
The biggest disadvantage is that it only works for apps that specifically support acting under org account using the arbiter's proxy endpoint. Tranquil's delegation feature, on the other hand, would allow you to login to any ATProto app and use it without changes.
Comparison to the Old Arbiter Design
The older designs for the arbiter were much more specific to the permissioned spaces proposal and and centered around a novel group access inheritance mechanism that was supposed to be able to represent many different shapes of organizations.
After talking to other teams and thinking about how more fine-grained access control could work, though, I realized that we could represent practically anything by reducing everything to a policy on top of XRPC requests.
So the new arbiter design boils everything down to that one concept and has no knowledge of roles or groups or anything like that. It can all be expressed directly in the policy.
If you want to put your role membership lists in your org account's PDS, you can do that and make a policy that will fetch those records and check whether or not the requesting user is in a particular role before taking a particular action.
Integration with Roomy
Now that we a working prototype running, it's time to start experimenting with it! We are not 100% sure how things will look like in the end and we want to get hands on as soon as possible.
A huge motivation for creating the arbiter was allow each Roomy space to be a full-blown ATProto account that admins could manage, and delegate access to selectively.
As soon as you have an ATProto account with multiple people writing to it, you need permissions and policy of some sort. The arbiter will provide that in a way that can be easily experimented with because of the replaceable policy system.
This could allow us to do all kinds of fun ATProto integrations in your Roomy space:
Creating atmo.rsvp events.
Publishing Bluesky posts from Roomy announcements.
Adding links to a Semble.so collection.
And more!
In other words, the arbiter is crucial to making each Roomy space be able to participate as a fully-fledged account on the ATProto network, while allowing the admins and members to manage it seamlessly from their own accounts.
This is all bran new and experimental, but we hope to have more updates soon as we start trying things out and refining things.