@benpate @strypey

#Roomy currently based on AT Proto but looking to add #ActivityPub soon
https://itsfoss.com/roomy-discord-alternative/

Hey, this is pretty interesting. Thanks for sharing!

That would be really cool if they can support Bluesky and ActivityPub at the same time.

The article on the website makes it seem like you’re only signing in with your ActivityPub identity though?

Otherwise, “Fediverse” client support is limited to the Mastodon API, or oft-unimplememted C2S API.

I’ll definitely keep my eyes on this one!

@klu9 @strypey

@strypey @activitypods Roomy implements its own storage. #ATProto is only really used as an identity / sign-in layer.

@erlend @zicklag

@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.

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

@maddyunderstars Looks cool! I'm starring and following your work.

It looks like you're using Typescript. All of my E2EE work is in Typescript, so there's a good chance you could use the library I'm making when you want to do encrypted groups.

Let me know when I can help

@strypey @zicklag @benpate @activitypods @erlend As far as I know, the "backup to PDS" thing is seen as "something we could do in principle, but haven't implemented yet".

As I understand it, Solid uses a strictly "RDF / JSON-LD" approach, and I doubt that Roomy's current data model would fit into this very well.

(I'm not directly involved in Roomy development, but I've been hanging out in their internal chats, and following their evolution really quite closely.)

@strypey Personally I'd be much more interested in seeing what could be done using a more IndieWeb approach. atom or mf2 for publishing, WebSub+WebMention for push, bearer tokens exchanged via TicketAuth for private access.

I'm not sure it would be *better* than ActivityPub but I do like the idea of building protocols on top of the web and which don't rely on .well-known paths to function.

@strypey I'm not sure it would be *better* than ActivityPub but it'd be a fun thing to experiment with, at least.

@strypey Yeah, the problem I run into with that is that developing things for the sake of trying them out ends up eating into my limited energy and pain budget which is hard to feel worthwhile when nobody else wants to do the same thing.

I have so many projects that I built because they felt like they served a need but then nobody else wanted to actually use them, and it ends up feeling not worth it given my disabilities.

@strypey
I Am Not A Coder, but @laurenshof pointed out that all the pieces that make up a Discord replacement are already in the Fediverse (article here: https://connectedplaces.online/reports/fr153-what-does-a-discord-replacement-look-like/), just not in one app. It occurs to me that someone could write a front-end that calls those apps as if they were the same app, and the end user wouldn't need to know

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

> 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

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

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

@zicklag
> chat spaces [can] use domains like handles for discovery, but it's possible to change the handle and the hosting server

Ah, so the answer to my question above is more like yes *and* no. Your spaces aren't distributed across participating servers like @matrix spaces. But they can move servers, unlike in @xmpp. I had a skim through both the MUC and spaces specs and can't see anything about portability;

https://xmpp.org/extensions/xep-0045.html

https://xmpp.org/extensions/inbox/spaces.html

@benpate @klu9

@zicklag
> we don't have backups yet, but probably will have them soon

The blog post I just read and posted a quote from says you'll only be able to backup public data in PDS (for now, at least). That's a pretty serious limitation.

I wonder if Solid pods could be used as PDS? Maybe by creating a fenced off area within a pod, containing only public data, readable and writable via the PDS API?

I'd love to get some comment from @activitypods team on all this.

@FenTiger @benpate @erlend

@fluffy I feel ya. Having some sense of buy-in and collaboration helps to sustain motivation when the terrain gets boggy. This is why I like the idea of a formalised competition/ hackathon approach.

(1/2)

@mick_collins
> someone could write a front-end that calls those apps as if they were the same app, and the end user wouldn't need to know

Ooh, you're wading into murky waters here Mick ; ) Here be (komodo) dragons!

Putting aside the messy details, you're right that one app could present a unified interface on top of a bunch of different components. In fact, most apps do that, we're just so used to seeing certain features bundled together that we don't notice.

@laurenshof