Even if you didn't login to Roomy directly with solid / ActivityPub, we could still have a backup service that replicates to a Solid pod.

Or even just an app you run on your computer that backs up your data.

@strypey @FenTiger @benpate @erlend

Yeah, it looks like it's possible that ATProto might get private data this year, which we could use for private backups, but until then they'll have to stay public.

It's also quite easy to make small tools / services that replicate a Roomy space to any other kind of backup target.

I made a proof-of-concept that could replicate our wiki pages to markdown files in a git repo.

@strypey @FenTiger @benpate @erlend

The RDF / JSON-LD approach of Solid could possibly be bypassed reasonably by just storing blobs with some metadata, but I'm not very familiar with Solid.

For backups we'd mostly be storing bundled archives of events anyway, so it isn't super important that thhose archives be semantically indexed as long as we can just store our serialized archive blobs.

@FenTiger @strypey @benpate @activitypods @erlend

Yeah, we don't have backups yet, but probably will have them soon.

Those will be optional though. It's just to give the user more data security, while many ATProto users will trust their PDS more than our server.

There actually is pretty good chances we could do a similar integration with Solid pods, but we've only got so much we can take on as a small team and I'm not sure what we'll be able to get to when.

@FenTiger @strypey @benpate @activitypods @erlend

> So "channels" and "servers" (as Discord uses these terms) would be tied to the originating server, like MUC in XMPP?

Yes.

If I understand XMPP right, we have an advantage also in that we can have chat spaces use domains like handles for discovery, but it's possible to change the handle and the hosting server without everybody having to re-join.

@strypey @benpate @klu9

Roomy does have a client and a server. The server has it's own protcol that isn't Roomy specific.

If we let you login with Mastodon it would just be for login still keep all of the data hosted on our server and wouldn't need to implement any Mastodon / AP APIs.

We do use the PDS for some storage / integrations, but once we get a tiny new feature in our server those can all be optional, and all the we need can be hosted on our server.

@strypey @benpate @klu9

We figure we don't need to replicate the chats to different servers, we just need to forward requests to the servers hosting the chat spaces that you've joined.

There's more technical details in this blog post and I'm always open to questions!

https://blog.muni.town/leaf-0-3-the-server-behind-roomy/

@benpate @klu9 @strypey

@benpate @klu9 @strypey ATProto is used only for authentication, optional integrations, and optional backups.

We have our own somewhat generic event streaming server that we use for chat spaces, where each chat space could be migrated to another server without the permission of the current host.

It's "federated" in that each chat space will be able to be hosted on a different server and the client will still be able to join them all from the same app.

@gray17 Awesome, thanks!!

One more question. Do you know if you can launch the game fine offline?

The device I want to put it on usually doesn't have internet access, and I've not used Steam for anything else yet, so not exactly sure if I'll be able to make it work or not.