This week, Habitat as a platform for organizational data is finally beginning to take shape. We've been working with other great atproto devs in the Community Standards working group and are excited about the current proposal for opensocial.community (still proponents for a more generic rename to groups or something similar though). In classic fashion, we were so excited about it that we went ahead and implemented (parts of) it.
Habitat's mission is to build data agency for organizations: we're focused on giving the affordances of atproto to entities that are organizations rather than individuals. We had previously prototyped our own system for managing an organization's members, but as the Community Standards WG developed their proposal, we realized much of what we had built could reuse these standards and thus be interoperable.
So, as of today Habitat implements a subset of the opensocial.community standards and one of our first features for managed organizations: admin app authorization. You can create organizations and invite members in the Habitat console. Chalk is the first app that's compatible with Habitat organizations so you can approve it for your app here.
Admin app authorization is one of the first organizational features we've developed: the ability for organization admins to allow or deny apps from interacting with spaces owned by the organization. The idea for this feature actually began months ago, when we noted that the spaces design allows for malicious AppViews to exfiltrate data from people that did not necessarily consent to giving those AppViews access to their data. One mitigation for this, we realized, is having some authority vet the apps that get access to a space, which fits neatly into our organization model in which apps typically go through a review process before they can be used. It's core to the Habitat and atproto ethos: rather than having your data stored in application backends, and getting that out via "third-party APIs", you own the source of truth to your data, and the "third parties" are instead apps that request you in order to get read/write access to a slice of that data.
Like our space proxy, this release is largely meant to be experimental: it's a building block towards our alpha release and a way to experiment with both the opensocial.community proposal and building on Habitat prior to our official launch. If you do try it out, we'd love to get your feedback (and any bugs you find) in our Discord! We're working closely with devs already building on Habitat to help shape our APIs as we build it out. Now let's get into it.
For protocol nerds: how we model organizations
We're matching the opensocial "community" proposal to model organizations. Each organization is an identity with the ability to write records and a space authority for hosting the organizations' permissioned spaces. To define the organization, it hosts a opensocial.community.members space that only members of the organization have access to.
For now, we each organization just defines "admin" and "member" roles so that we can control who has access to configure the organization and approve apps. Habitat will flesh out the customization of these roles and capabilities to allow organizations to enforce the policies they need.
Admin app authorization
For an app to request authorization, it initiates an OAuth flow with the organization's identity (the org DID). Habitat routes that request to a sign in page where only an admin can sign in. Once an admin signs in and approves the scopes of the app, two things are achieved:
Authorizes the app for the rest of the members of the organization by writing a
network.habitat.space.appAccessrecord in themembersspace.Grants the app an organization credential that it can use to write records on behalf of the organization
When an app requests a space credential on behalf of an identity, the app must also present a client attestation as per the spaces proposal. The space host looks up a space.appAccess record for that client to enforce access.
Organizational spaces
Members of a space can call opensocial.community.createSpace via service auth to create modality specific spaces that are only visible to other members of the organization. An opensocial.community.access record is seeded into the space which lets the space host know which roles have access to the space.
Organization credentials
With organization credentials, apps are granted admin-approved, scoped permissions for writing into the organization's repo in organizational spaces. This is a great way to organize shared data within the organization. Chalk uses this to write the merged, readable version of all the user's CRDT edits.
What's next
Over the next few weeks, we'll be releasing more core features of Habitat's organizational platform. To keep up to date, follow us and join us on Discord!
-Habitat team