There's a lot of energy on the #Fediverse right now to discuss/find a #Federated alternative to #Discord using #ActivityPub.

@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

@benpate Thanks! Your e1ee library will be helpful! Is it public right now? I had started playing with libsignal after seeing @HolosSocial use it

Edit: Ah I see your comments on GitHub, thanks!

@zicklag
> I'm always open to questions!

How far off the mark was I in this pair of posts, about how Roomy uses ATProto and what that suggests for how it might use ActivityPub?

https://mastodon.nzoss.nz/@strypey/116066950694720465

> we don't need to replicate the chats to different servers

So "channels" and "servers" (as Discord uses these terms) would be tied to the originating server, like MUC in XMPP? Not replicated using the data storage of the participating accounts, as Matrix does?

@benpate @klu9

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

@zicklag's reply to @benpate suggests it's both/and;

https://mastodon.social/@zicklag/116069496831677674

The Roomy server has a copy of the data, and backs it up to PDS for people logged in with ATProto accounts. Not sure what implications this has for people logging in with ActivityPub accounts. But Solid pods could, in theory, be used like PDS a la @activitypods.

@erlend

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

@benpate
> We could probably rebuild most of Discord's features as an Emissary inbox without doing a lot of back end code

One way to rapid prototype this would be to cheat. Copy as much as Discord's HTML/CSS/JS as you can get hold of. Chuck it in a private repo, accessible only to you/ your team.

Then you only need to build a layer of scripting glue and gaffer tape between that and an existing AP back-end (#Emissary, @Bonfire, dealer's choice). Published under a free license.

(1/2)

#Discord

After a few days/ weeks of furious hacking, you'll either give up in disgust and tombstone your repo, or a get a PoC working. If you do, celebrate and announce the fact.

Then you can recruit web/app designers who've never had access to the private repo (with the Discord layout code). They can then build Free Code interfaces on top of your glue and gaffer tape layer. Voila, a fully libre service with all the key features of Discord

Rinse, repeat for other DataFarms we'd like to replace.

(2/2)

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

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

Knock yourself out. Let a thousand flowers bloom! ; )