Another status update on the arbiter work!
After talking to the folks from habitat.network, we realized that, even though it would be cool if we could converge on the same access control mechanism, it might not be realistic.
But if Habitat couldn't use the arbiter for their access control needs, then it would still be good if we could still have some level of interoperability.
After doing a lot of thinking about it, I realized that the arbiter wasn't making a clear distinction between "who is who" and "who can do what".
In this case, the "who is who" includes, "who is in what role / space / group" and "what groups are considered members of other groups". These
I think this distinction actually turns out extremely useful and has led to the next iteration of our arbiter design plan.
Generic Group Lexicons
The first component is a draft of a generic arbiter lexicon, one that intentionally doesn't specify details of how access control works:
Similar to standard.site using an open union for the content of documents, we use open unions for 3 kinds of configuration:
The arbiter ( community / organization ) configuration
The space ( role / group ) configuration
The member access
Different arbiter server implementations may support different lexicons in those open unions, and can return an ErrUnsupportedConfigLexicon, if they do not support a particular config type.
Regardless of how the server chooses whether you are allowed to add a member, or configure a space, etc., it will give you a standard API for listing those spaces and members in the community.
This is very important for credible exit, and means that you have good chances of being able to migrate the community to another server, even if they are different types of servers with different config lexicons.
Note on naming & stewardship: Now that it's generic, I'm not sure whether "arbiter" is the name of Roomy's group server, or the generic group lexicon itself. I'm leaning towards arbiter being the Roomy server, but overall I'm open to input on this and I'm pretty neutral.
I think that this generic lexicon, though, would make a lot of sense to be move to a lexicon.community lexicon, if it shows promise and we can get at least a couple server implementations using it.Policy-Based Arbiter Implementation Prototype
On top of these lexicons I have a prototype of a new arbiter implementation that uses Rego policies to define the specifics of the config types and authorization.
I have a policy that implements the 8-access-level authorization system that we had in the previous arbiter. The difference now is that the server is completely generic over the policy. That means that, without needing to create a new server, communities can upload a custom policy reflecting their unique access control needs.
This can hypothetically be used to implement advanced features such as needing a majority vote in order to remove owners, or being able to vote to promote admins. This would be implemented by adding the voting state to the member config lexicon, and having a policy that strictly controls who can change the voting flags, and makes sure that the required votes are obtained before access can be changed.
Policy-Based Community Repos
Beyond this I am also going to be looking into leveraging the same policy mechanism for controlling write access to community-owned repositories.
This could be used for advanced community consensus mechanisms on top of either public or permissioned ATProto records.
This can also make it easier to implement ATProto apps that need application or community owned data.
Because you can handle write authorization in a policy on a repo, your AppView can stick to indexing data on protocol, instead of having to mix off-protocol data into your AppView database.
We're thinking that this, when combined with the arbiter, can be a more generic alternative to what opensocial.community is providing for community groups.
I'm also considering merging this repo functionality into the arbiter at this point, because of the large overlap between a policy around repo records and a policy around the arbiter config lexicons.
That said, you could still deploy these separately, or have multiple community repos for different apps that all share the same arbiter.
Implementation Status
I have a quick and dirty implementation of the new policy-based arbiter. It's actually simpler now that it's offloading the enforcement logic to the Rego policy, is a nice benefit.
I've also got the arbiter simulator updated locally to use the new system1.
I want to have an actual server working pretty soon. I think this direction is looking very promising.
If anybody is interested in trying this out, critiquing the lexicons, discussing different scenarios, or evaluating whether or it works for a particular use case, please do reach out!