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)
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.
@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! ; )
@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.
(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 know
Ooh, 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 (EDIT: Plone/Zope). The UX was pretty good for the time, but performance and maintenance were hell.
@crft
> It might be helpful to be mindful that some users disable all JavaScript
I 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.
Ben Pate 🤘🏻
Strypey
fluffy 💜
Mick Collins
Wizards Anonymous