There's a lot of energy on the #Fediverse right now to discuss/find a #Federated alternative to #Discord using #ActivityPub.
-
@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.
-
@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!
Sorry I missed your note until now. My work is still very much "in progress" but it's all public. For now, you can see it here: https://github.com/EmissarySocial/emissary/tree/dev-e2ee/_embed/templates/user-conversations/resources/app
... but it will likely me moving to a better home later this week
-
@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)
@strypey just commenting about copying JS. It might be helpful to be mindful that some users disable all JavaScript, like in Tor Browser.
-
@strypey just commenting about copying JS. It might be helpful to be mindful that some users disable all JavaScript, like in Tor Browser.
@crft
> It might be helpful to be mindful that some users disable all JavaScriptI use NoScript, so I'm aware. But I doubt there's a big overlap between people blocking JS and people depending on Discord and needing a replacement ; )
Also these 2 posts were proposing a rapid prototyping experiment. A proper long term Discord replacement for the fediverse would need native apps etc.
