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.
#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!
(1/2)
@benpate
> youāre only signing in with your ActivityPub identity though?
The article is light on specifics, but it seems like Roomy is a client app, not a server+client app like Mastodon. So in ATProto jargon;
https://dustycloud.org/blog/how-decentralized-is-bluesky/
... Roomy is an AppView, using the PDS for a logged in ATProto account as a data store (not sure if or how it uses Relays).
(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.
@strypey @activitypods Roomy implements its own storage. #ATProto is only really used as an identity / sign-in layer.
@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.
@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.)
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.
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.
@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.
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.
(1/3)
@zicklag
> 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
Oh absolutely, please consider doing a PoC! @activitypods is an experimental project to see how Solid can work in combination with ActivityPub. But they're separate protocols, doing different things, and you can totally use one without the other.
(2/3)
I'm bullish on Solid though, because it's supported by TBL, and offers a standardised way for social web apps to store user data in a protocol-neutral way. I see a potential social web where apps can choose whatever server-to-server and client-to-server protocols best suit their use cases, but identity and data storage are unified and under the control of the people who identity and data it is.
(3/3)
So in theory, an app like Roomy could authenticate a person joining with an ATProto ID, store their posts in a Solid pod, and federate them over ActivityPub. Another app could authenticate them with their fediverse or matrix @handle, retrieve those same posts from the Solid pod, and relay them over Nostr.
I'm still learning about the nuts and bolts of these protocols, maybe this is impractical. But what projects like ActivityPods and Roomy are doing is a great way to explore this.
Ben Pate š¤š»
klu9
Strypey
Mike P
Zicklag