For the last year, we have been working on Roomy with a clear integration to the ATProtocol. At the same time, we've also had a distinctly "off-protocol" strategy for data handling: we don't store Roomy's canonical data on the ATProto PDS. The reason for this is that the PDS because has shortcomings, such as a lack of private data, that make it unsuitable for Roomy's needs.

This is actually completely natural! Bluesky's needs, such as distributing individually authored content to the world where it can be aggregated on a global scale, is not at all similar to Roomy's needs. The ATProto PDS is designed in a way that is very effective for many different applications, but a richly collaborative, realtime community space, is not one of them. Neither is it designed as a media server or a git server.

It's unrealistic to assume that the PDS is going to be suitable for every kind of application, and that is no failure on the part of the PDS! It's just not possible for one kind of server to do everything.

The case I want to make today is that having different kinds of service providers other than the PDS should become a completely normal and well facilitated part of the ATProto ecosystem.

Two days ago we realized that with Roomy we were not merely making an "off-protocol" app, we were making a new kind of PDS.

When I think about what makes the PDS important to me, it's summed up in three major points:

The PDS can be self-hosted or hosted by a provider,

You can migrate your PDS hosting between providers,

And there is an API that I can use to access all the data on my PDS.

These three things are what give users freedom.

The Leaf server, which we use to power Roomy, provides all of these features just like the PDS does, and users will have just as much ownership of their data using Roomy as they will using Bluesky. The only difference is the API.

A crucial component of this is identity. We need you to be able to sign-up to Roomy, without ever having created a Bluesky / ATProto account.

We also want you to be able to take your Roomy account, and login to Bluesky with it.

But today this requires us to host a PDS for Roomy, and I'd argue that shouldn't be necessary.

Roomy's Leaf server implements all of the user storage features that it needs, and there's no functional reason for us to host a PDS other than for authentication purposes.

I don't think that an entire PDS should be necessary just to do authentication. Roomy can create a DID for our users, and allow them to manage their account, without needing a PDS.

We're imagining a scenario where we could have universal web login in a way that doesn't restrict you to using an ATProto PDS, and that still gives you the awesome, "login with your internet handle" experience in an inter-operable way.

For example, lets follow Alice's journey which starts by registering a new account with Roomy.

The first thing Roomy will do is create a new DID on the plc.directory. Just like when you create an account on a PDS, the Roomy server will create a rotation key to manage PLC records.

Instead of creating an AtprotoPersonalDataServer service, it will create two services:

A LeafServer that will be used by Roomy

A WebAuthServer that will be used to perform authentication handshakes.

Both of these will also have corresponding verification methods and keys:

The Leaf server will use its key to sign records stored on the server and to authenticate itself when it sends responses to clients.

The web auth server will use its key to authenticate the user, very similar to how the PDS authenticates users today.

By splitting the data storage service from the authentication service, we remove the unnecessary dependence on an entire PDS, when we are are already providing all those features with our Leaf server.

Now what happens when Alice wants to use her Roomy account to log into Bluesky?

Today you can't even begin because Bluesky asks you for a PDS host up front on the login page instead of looking it up from your web handle.

In our hypothetical scenario, though, Bluesky will allow Alice to put in her handle, alice.roomy.chat, and Bluesky will resolve that to her DID document to find that, while she has a WebAuthServer registered, she doesn't have a Bluesky PDS.

Bluesky will start by authenticating Alice using the WebAuthServer's API. Once they are authenticated, then Bluesky can tell Alice that she doesn't have any PDS hosting services registered for her account.

Because Bluesky offers PDS hosting, though, it can redirect to Alice's WebAuthServer with something like an OAuth scope request, to have Alice confirm that she would like to register Bluesky as her new PDS hosting provider. If alice confirms, the WebAuthServer can update Alice's DID to list Bluesky's PDS server as her PDS host.

Now she can continue to use Bluesky with Bluesky's hosting, even though she is using her Roomy account!

I think Roomy's need to make a custom "PDS" is not an isolated case. Already we have tangled.sh offering git hosting and needing to use a custom "Knot" server, and we've also got stream.place and community discussion around having a Media PDS / Service as a kind of PDS "sidecar".

Private data is another use-case where having a secondary PDS or service of some sort may be our best road forward.

I think this is good! We just need a way to make the ATProto PDS one among multiple kinds of services offered to "universal web ID" users.

Maybe we could even get to the point of logging into Bluesky with a Mastodon or other ActivityPub account, if it wasn't a requirement for Mastodon to literally run an entire PDS just for auth purposes.

Not being able to use the PDS for an app shouldn't have to give the impression that you "don't own your data". The PDS isn't the only server that can provide alternative hosting and data migration. I think we just need a way to make sure that authentication is still supported even for non-PDS servers.

While I firmly believe that having multiple services is essential, it's worth acknowledging that there are some disadvantages to multiple servies.

The biggest one is that different services have different APIs, so apps that want to inter-operate with those services will be required to use those different APIs.

This, though, is just a fact of life. If you have different needs, you may need a different API. Making everybody to use the same API isn't going to improve the situation when new APIs are actually needed.

I think the goal would be to have a relatively small number of core services that most apps could use, and only for special use-cases would new servers need to be created.

For example, Roomy's Leaf server is focused on creating realtime community spaces, and it is actually app agnostic. It could be used by other ATProto apps where it fits their needs.

It sounds like the media service discussed on the community forum would be another re-usable service that many different apps could use.

As a community I think we are going to need more than the PDS, and maybe there's a chance we could figure out how to make that happen in a seamless way where users can optionally self-host, yet still be able to login to all of our hosted apps with different needs easily.

I know there are a lot of details that would need to be figured out to make this work, and we'd need to get buy-in from Bluesky if we wanted you to be able to actually login to Bluesky from a DID that doesn't have a PDS service yet.

But I find this idea quite inspiring, and would love to get some community feedback on it. Feel free to reply to @zicklag.dev on Bluesky or join the discussion on the community forum.

This is all somewhat related to a recent interest in the ATProto community to figure out how to manage a cross-app profile.

If you log into Roomy with, for example, a Tangled account, there isn't a standard profile that Roomy can look for to get basic stuff like your name, profile, description, and links.

While we could just make a standard profile lexicon and stick it on the PDS, I think that it would be far better to put a URL to a profile JSON or something similar as a service in your PLC record. We could still define the format with a Lexicon.