Since the conference, Habitat has been undergoing some changes! We wanted to share an update with the broader community about some of these, since we've gone a bit radio silent since the conference (an ATmosphereConf recap post is still sitting in my drafts š).
Our guiding thesis has always been that the internet could be less exploitative and predatory, but also more usable and powerful, if data ownership was built into the internet at an infrastructural layer. The work around cliques, private data, and local-first that we pursued earlier this year was very much around a dream we had of "(all) your data in a box". To realize that dream, we believe there needs to be additional infrastructure that allows your data to be directly shared with other people's "boxes" without relying on third-parties and aggregation servers (AppViews in the system today), and more so that this must be done in a scalable, usable way.
However, as we began working on this problem space of data ownership with people actively interested in using Habitat to own their data, a more glaring gap we found for immediate use-cases was the lack of data ownership at the group / community / organization level.
Tell me more
The words group / community / organization mean different things to different people and have been used in so many contexts that at this point they could mean almost anything. Since there is some discussion already about this on Discourse and in many other threads, let me clarify specifically what Habitat is trying to achieve and solve for:
- 1.
Data portability at an organizational or group level: Today, 'organizational' data (in the enterprise-y sense of that word), has no portability. As a plain example, at my previous job, we had engineers dedicated to doing a data migration from one Docs provider to another which spanned years, since ultimately SaaS providers / vendors want to lock you (your data) into their experience and platform.
- 2.
Data that 'belongs' to an entity that is not the user writing the data themselves: In the organizational model, and even in many communities that don't consider themselves 'organizations', much of the data doesn't and can't really belong to the users themselves; it needs to outlive the members and become a part of the bigger entity's lifetime and context. At an implementation level this could be solved many ways, but the way we are going about it is to give each organizational member their own write space (repo) and identity within an organization.
- 3.
Authoritative administrative management over group level data: Designated admins of a community or organization should have control over "where data is allowed to flow", or which apps members of the groups can login to. i.e. Okta for the ATmosphere.
- 4.
Permissions & roles portability at an organizational and group level: One problem that anyone working at most companies has experienced goes like this: someone switches teams and you need to add them to your Google group so they get access to your team's weekly meetings. But oh wait, you also need to add them to your team's folder in [X] app so they get access to the team's meetings. And oh! Also, they need to have this special role so they can access your team's internal tools that no one else gets access to. These 'roles', or more broadly, the 'access layer for the organization' should be controlled by the organization; they are part of that organization's data. Ideally, this were true in the broader ecosystem as well, so I as a user could create a group called "friends" which designates some people who I decide are my friends to do things across apps, without needing to upload my contacts or re-building this list in every experience. (I believe) this is part of what the discussions around interoperable group permission-ing, particularly the Arbiter by roomy.space, are trying to achieve so we are very much looking to trade notes and even align on a shared solution here.
- 5.
A first-class platform for agentic workflows and guardrails: With the above primitives in place, we hope to support workflows / experiences / features where agents can be both more useful and trusted. Useful because they actually have access to adequate context to carry out tasks (as opposed to either having to connect all your data sources to Anthropic / OpenAI / whatever to make models more useful or alternately having to manually prompt in the missing context). Trusted because with the right guardrails around identities, authorization, and data ownership, it becomes possible to have concrete guarantees and boundaries on what agents can do.
- 6.
All of this together, bundled: We believe an adequate solution to "data ownership for organizations" means all of these things, together.
If none of that made sense, then a more concrete way of thinking about Habitat is that it is a backing data store for everything that is typically silo-ed into SaaS providers when working at a company, and then letting you do more with it.
"Doesn't [permissioned spaces | delegated accounts | x] solve this?"
Yes and no. We are excited about a lot of the work happening in the ecosystem and hope to collaborate and contribute to it, but in pulling together all the constrains laid out above, we've made choices in some cases to reuse and some cases to depart from the active work happening. We will dive deeper into some of the technical decisions we've been making here through ... future posts!
Call for collaboration
Finally, we believe being "on protocol" to use atprotospeak is a major benefit and advantage to Habitat. Previous attempts at doing something like this seem to have gone one of two ways:
- 1.
Creating an integration layer -- adding connectors to big SaaS providers and delivering some enhanced experience this way. To be frank, any migration story for organizations includes connecting to their existing services, but Habitat via AT protocol is approaching this from an "underneath" approach rather than "on top of".
- 2.
Creating a whole new way of doing things -- here I'm thinking of Proton, Nextcloud, Skiff, etc. There's been several attempts at "you should own your data! here's a platform that lets you do that!" which then becomes its own universe. Which is fine! But we think open protocols, standards, and a community (the AT proto ecosystem) around owning your data is actually the missing piece to make such a project succeed and go mainstream, rather than the cherry on top. Interoperability is the term here :)
With that being said, if any of this sounds interesting, relevant, or useful, please reach out to us! We are actively looking for more design partners (both teams building for the organizational use-case within AT protocol and teams who would like Habitat for themselves internally) and collaborators.
The team
The last piece of personally very exciting news is that it is not just me () working on Habitat full-time!!! (Many !s of excitement about this)! Sashank Gogula (even more offline than me ) left his previous full-time job at Glean no more than 9 days ago to become Habitat's CTO and Co-founder with myself.
With that rare SF sunshine & see you all at ATproto Bay Area meetup tomorrow,
-Arushi āļø