There's a lot of energy on the #Fediverse right now to discuss/find a #Federated alternative to #Discord using #ActivityPub.
-
@benpate
> We could probably rebuild most of Discord's features as an Emissary inbox without doing a lot of back end codeOne 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).
(1/2)
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)
-
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 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 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 accessKnock yourself out. Let a thousand flowers bloom! ; )
-
@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 accessKnock yourself out. Let a thousand flowers bloom! ; )
@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.
-
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
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 -
@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?
Strypey (@strypey@mastodon.nzoss.nz)
(1/2) @benpate@mastodon.social > 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). @klu9@ohai.social
Mastodon - NZOSS (mastodon.nzoss.nz)
> 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?
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.
-
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.
> 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 @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.
-
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.
-
> 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.
@zicklag
> chat spaces [can] use domains like handles for discovery, but it's possible to change the handle and the hosting serverAh, 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;
-
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 soonThe 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.
-
@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.
@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.
-
@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(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 knowOoh, 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.
-
(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 knowOoh, 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.
(2/2)
But the devil is in the details. Specifically, what kind of plumbing is the most efficient, most maintainable way to connect all the bits together?
Up until 2020, when it died without warning, I had the #Disintermedia blog and wiki on CoActivate.org. A site based on OpenPlans, a Free Code project creates by welding together WordPress and a bunch of other software with a Python framework (Django, I think?). The UX was pretty good for the time, but performance and maintenance were hell.
-
@zicklag
> we don't have backups yet, but probably will have them soonThe 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.
-
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.
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.
-
(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 podOh 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.
-
(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 podOh 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.
-
(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.
