OK, I have some draft lexicons for the idea above now:
Docs site generated from the lexicons:
And the JSONs are on lexicon.garden:
The idea is that we define the basic structure of Arbiters with spaces with members, but we allow the arbiter, the spaces, and the members each to hold an arbitrary lexicon object by making it an open union.
The expectation is that different arbiter servers can implement custom lexicons to fill in those open unions, and that they will also implement custom mechanisms for authentication ( i.e. are you allowed to add that member or create that space? ).
Regardless of the authentication mechanism it uses, any client that supports these lexicons will be able to read the list of spaces, and see who is a member.
The abilty to add spaces as members of other spaces is considered important enough to be built-in. This allows us to represent subgroups and role trees in an interoperable way.
I think this achieves the separation of “who is who” from “what can you do” and now the question will be whether or not this API is suitable for both Habitat and our own arbiter.
I think if this works out, then it’d be a perfect candidate for lexicon.community. But we should probably make sure that can actually get two separate servers that can both use this API first.