Since Habitat is building for organizations, we need permissioned data. That's why we're super excited about Daniel's published proposal: it lays the groundwork for building interoperable apps where organizations maintain ownership over their private data that has historically been cordoned off by SaaS apps, just like the protocol currently enables for individual users with their public data in a global social network.
We're so excited about spaces that we couldn't wait for the spec to be finalized nor a reference implementation to be out before getting our hands on it. So, we implemented a wrapper service that extends public PDSs with the proposed spaces API, including the simplespace implementation. This way, we could start experimenting with applications that use permissioned data as well as start developing additional infra that builds atop the spaces protocol.
However, we wanted to enable the rest of the ecosystem to get a feel for what it's like to develop with permissioned spaces as well. So, we decided to release our PDS wrapper to all AT Protocol developers!
We tried to make it as easy as possible to get started: to use our API from a web client, the only change needed is to replace the default identity resolver in the OAuth client with Habitat's custom identity resolver. This allows us to implement the spaces proposal as if we were the user's PDS, without affecting other PDS endpoints.
Example Typescript usage with Habitat's identity resolver:
import { BrowserOAuthClient } from "@atproto/oauth-client-browser";
import { HabitatIdentityResolver } from "@habitat-network/habitat";
const client = new BrowserOAuthClient({
clientMetadata,
identityResolver: new HabitatIdentityResolver(), // defaults to https://pear.habitat.network
});
const session = await client.signIn("alice.bsky.social");Example DID doc returned by the Habitat identity resolver:
$ curl "https://pear.habitat.network/xrpc/com.atproto.identity.resolveIdentity?identifier=sashankg.bsky.social" | jq
{
"did": "did:plc:v3amhno5wvyfams6aioqqj66",
"didDoc": {
"id": "did:plc:v3amhno5wvyfams6aioqqj66",
"alsoKnownAs": [
"at://sashankg.bsky.social"
],
"verificationMethod": [
{
"id": "did:plc:v3amhno5wvyfams6aioqqj66#atproto",
"type": "Multikey",
"controller": "did:plc:v3amhno5wvyfams6aioqqj66",
"publicKeyMultibase": "zQ3shtiVA46sMPwyJ546rDiSqELBaMbcuYAR2xr9avKoPNKHH"
}
],
"service": [
{
"id": "#atproto_pds",
"type": "AtprotoPersonalDataServer",
"serviceEndpoint": "https://pear.habitat.network"
}
]
},
"handle": "sashankg.bsky.social"
}The way this works is by overriding the #atproto_pds service with Habitat's endpoint in our identity resolver, and on the Habitat side, proxying through all requests besides the permissioned spaces ones to the actual PDS. For now, Habitat will host any space repos created through this API centrally. Optimistically, once the reference implementation has been shipped to PDS'es, we will move over spaces on Habitat to the real PDS, without any work required from the developer's side.
All of the relevant information and more details for how we're implementing spaces can be found on our API documentation page. And we invite you to join our Discord server here to connect with others building on Habitat and share feedback with our team directly!
As a disclaimer, this API is not meant to be used in production (yet!) and it is not fully battle tested. Rather, it's meant to serve as a way for AT Protocol developers to experiment with the proposed spaces implementation ahead of its official release by the Bluesky team and on the reference PDS implementation.
This is the first of many incremental releases that Habitat is doing over the next ~6 months as we build towards an alpha release of our platform. A sneak peak of things on their way 👀:
Relationship based access control APIs for spaces that give more fine-grained permissioning than
simplespaceRealtime topics for spaces to enable multiplayer apps authorized by space permissions
Interoperable group lexicons for shared permissions across apps
See you next week 😉!
- Sashank & Arushi