I personally don’t have the technical knowledge, time, or energy to take on something like this — but I was curious:

Since Matrix, XMPP, etc. already support most (if not all) of the features that Discord offers — text, voice, video, threads, bots, roles, federation, etc. — would it theoretically be possible to just replicate Discord’s UI and UX and build it on top of the Matrix or XMPP protocol instead of starting from scratch?

I mean, sure, there’d be some challenges with existing third-party clients, like

Matrix:

Element X,

Nheko,

Cinny,

FluffyChat,

XMPP:

Aparté

AstraChat XMPP Client

aTalk

Beagle IM

Bruno

Chat-O-Matic

Chatty

Conversations

Cheogram Android

but if developers and users agreed to focus on a stack — say, Matrix, XMPP, or both — couldn’t there a “Discord-like” ecosystem of compatible apps and communities?

Basically: could an open-source “Discord alternative” be built using Matrix or XMPP as the backend rather than trying to reinvent the wheel?

What are the technical or social barriers to doing that?

  • ambitiousslab@lemmy.mlEnglish
    41·
    8 hours ago

    I say XMPP below as that’s what I’m most familiar with, but you can replace it with Matrix or any other open federated network :)

    would it theoretically be possible to just replicate Discord’s UI and UX and build it on top of the Matrix or XMPP protocol instead of starting from scratch?

    It’s complicated. I agree that copying the UX of the proprietary apps to provide a familiar experience would help get some adoption. That way we don’t have to convince someone to switch network and user experience at the same time.

    If we had an XMPP-based Discord clone, WhatsApp clone, Telegram clone etc., all interoperating with XMPP under the hood, I think it would be much easier to go to each friend and get them to switch to the clone of the service they like the most. And, everyone could still talk to each other no matter what UI they were using.

    I think the reason why Conversations is so successful, compared to other clients, is that it started essentially as a clone of Hangouts.

    but if developers and users agreed to focus on a stack

    There’s the problem, though. Developers are never going to agree on a single solution :)

    There are limited numbers of developers really familiar with the nuts and bolts of XMPP, and they are already swamped maintaining the existing software.

    I think this can be solved though by separating the UI from the backend as much as possible. If experienced XMPP devs work on libraries, and experienced UI devs work on replicating proprietary UIs, someone can then wire whatever frontend and backend together that they want.

    I think this can get you 80% of the way there. The last 20% will be challenging though, as you won’t be able to replicate the UX exactly: the experience you want to provide will clash with the way the existing network already works.

    examples of network differences

    For example, XMPP has the concept of anonymous public rooms, where you can’t see someone’s identifier. Most public rooms are set up like this. You can’t start an encrypted conversation with someone from a group without exchanging jids first.

    But, someone who’s used to WhatsApp will expect to just be able to click on someone in a group chat to start an encrypted conversation with them. That’s just not possible in XMPP, in the already existing rooms. So, although the UI will look the same, there will definitely still be confusion around the edges.

    Likewise, WhatsApp expects everyone to be contactable by phone number. But, if you have a friend who signed up to XMPP using a discord-like app, the phone number won’t be their primary identifier. So users could get confused why they cannot contact their friend when they thought that using this WhatsApp clone would work the same way.

    So, in some ways, it’s cleaner to just provide a completely different experience and say “this is what XMPP is”.

    What I’m not sure about, is how important that last 20% is. On one hand, a user might like that the app seems to function like one they’re used to. But then, I can see them having less patience and saying “this is broken” in the areas it doesn’t work like they expect. I feel they are likely to be less forgiving about the bits that aren’t the same, if everything else is a replica. And, they won’t understand the nuance that it’s more difficult to have a consistent experience across different clients and servers, they will just say “this app is broken and I’m going back to the proprietary one”.

    Meanwhile, the status quo, where we say “you have to switch networks and also learn how XMPP differs from everything else at the same time” has its own problems, because people just do not feel comfortable changing so many things at once. So long story short, it’s tricky :)