Roomy Devlog 2

Last Friday we finished a big data migration in Roomy!

View post on Bluesky

You can go ahead and read the last devlog for more details on the migration because it pretty much went exactly according to plan!

The data that was previously on our Leaf server is now stored in a separate SQLite database alongside the server index on our AppView.

This has already fixed a couple of bugs, including one causing excessive memory usage on our server and another one causing the Discord bridge to need to be restarted periodically because it got out of sync.

It's been running for a few days with no hosting issues which is a huge relief!

So the next big objective as far as getting Roomy fully ATProto-native is to make all of our Roomy spaces fully authentic ATProto accounts.

That means your Roomy space itself has its own DID and its own PDS account. Each roomy space will also be connected to our arbiter 1, a work-in-progress service that allows controlled access to ATProto XRPC APIs.

The Arbiter allows customizable Rego policies to control who can do what on an XRPC API and will be used by Roomy to control access to the Roomy space's PDS.

Once that is working it will let us do fun stuff like letting configured admins in the Roomy space write Bluesky posts and publish them under the Roomy space's own ATProto account!

You will be able to setup your org account, such as @npmx.dev or @atproto.com as your Roomy space, and then control the account through Roomy integrations. Roomy will also use ATProto handles as space handles so that you can go to a link like roomy.space/npmx.dev to get to the official Roomy space for that account, if one is setup.

We are also looking into integrating with blento.app so that each space can get its own web page.

The arbiter will serve as the backbone for authorization in Roomy, controlling access to the public ATProto repo, as well as the private data, once permissioned data lands on protocol.

Both the arbiter and permissioned data are very work-in-progress and Roomy's migration to it will be incremental.

The plan looks something like:

Setup an ATProto PDS server to use for all of our Roomy spaces and update their DIDs to use the new server: This will make all Romy spaces real ATProto accounts, but it will be mostly symbolic because there will be no way to actually use it for anything yet.

Setup the arbiter for all of the Roomy spaces, so that it can control access to the ATProto PDS: We will hook up the arbiter to run its authorization checks against the data from the Roomy AppView. If you're an admin on the Roomy space you'll be able to use the Arbiter to create, edit, and delete records on the space's PDS.

Setup cool integrations for the Roomy space: We can experiment with some integrations that might possibly include:

Let you configure a Blento site for your space.

Let you post to Bluesky under your space's account.

Let you create ATProto events that will show up in atmo.rsvp and smokesignal.events under your space's account.

We are also thinking about bringing back Roomy wiki pages and letting you publish them to a standard.site publication like Leaflet.

At this point we will have gotten the Arbiter more proved out, but we still need to move our data formats closer to being ATProto native and compatible with the permissioned data proposal.

While Roomy is already using DRISL / CBOR and Lexicons to describe our data format, data is organized as "events" in a stream, not records in a repo. Our lexicons aren't really suitable for the permissioned data proposal yet.

So we'll be looking into migrating the Roomy spaces to new lexicons and record-organized data instead of an event stream.

We'll be looking to unify with Colibri's lexicons if possible. We've been chatting with @lou.gg, the creator of Colibri, and they've already been building directly on ATProto and have chat lexicons already in use, so we want to align on something that works for both of us if possible.

At this stage I think we'll be running test migrations offline and testing out @happyview.dev along with the migrated data. HappyView has a prototype implementation of ATProto permissioned data, so it would be ideal if we could migrate Roomy's backing data store to that.

That would put us in a really good place as far as being almost ATProto-native, and mostly waiting for permissioned data to be officially deployed.

The details toward the end here are definitely kind of fuzzy and we'll be figuring out more details as we go. I'm super excited that our last migration went well and I'm looking forward to bringing Roomy closer to running fully on ATProto!

Unfortunately the latest design for the arbiter hasn't gotten a great blog post or explanation yet. I'll do that as soon as I get the chance!