(2/2)

If Roomy enabled signing in with a fediverse account as an identity, there's no PDS to use for data. So I'm guessing the plan is to implement the Mastodon API, enabling Roomy to act as a fediverse client, and use a logged in account's home service as the data store?

What would be really intriguing is if Roomy borrowed from the @activitypods approach, allowing a fediverse account to be used as identity, with a Solid pod as the data store.

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

@strypey suggested that I put this out there to anyone who's thinking about it. We could probably rebuild most of Discord's features as an #Emissary inbox without doing a lot of back end code.

I'm too swamped to start on this right now. But if you're a great HTML+CSS designer, I'm able to give some time to a team who wants to take this on.

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

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

@benpate @strypey@mastodon.nzoss.nz I'm building Shoot, a discord-like federated instant messenger with activitypub! I would always appreciate any help with development, my pins has any more info as well

GitHub - MaddyUnderStars/shoot: ActivityPub federated instant messaging server

ActivityPub federated instant messaging server. Contribute to MaddyUnderStars/shoot development by creating an account on GitHub.

GitHub (github.com)

@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

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!

Leaf 0.3 - The Server Behind Roomy

For the last couple months we've been iterating on Roomy with its brand-new architecture, and we're finally ready to talk in more detail about the not-so-secret sauce that will power Roomy moving forward.

Muni Blog (blog.muni.town)

@benpate @klu9 @strypey

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

@erlend @zicklag

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

Zicklag (@zicklag@mastodon.social)

@benpate @klu9@ohai.social @strypey@mastodon.nzoss.nz 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.

Mastodon (mastodon.social)

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

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

@strypey suggested that I put this out there to anyone who's thinking about it. We could probably rebuild most of Discord's features as an #Emissary inbox without doing a lot of back end code.

I'm too swamped to start on this right now. But if you're a great HTML+CSS designer, I'm able to give some time to a team who wants to take this on.

@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! ; )

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)