@imacrea @strypey For the end user, it is not really important, both protocols are open standards. It probably depends on your friends...

@bortzmeyer @imacrea
in theory, either protocol can be used for any kind of chat. But while the client is great for team chat, I haven't seen a client with an instant messenger UI I would recommend for friends and family use. () is the opposite. Apps like (Android) and (desktop) are fine for one-to-one IM but I have yet to see a Jabber client that does group chat as well as Riot. This piece explains the differences well:


I'd really like to see a group of champions take the source code and modify it to connect to servers using , , and , instead of the protocol. This would conclusively prove their constant claims that their preferred protocols can do everything Matrix can do. I would be curious to know what proportion of existing Jabber servers such a modified client could connect to without losing any functionality.
@bortzmeyer @imacrea

@strypey it would be better to go for a Electron #ConverseJS version but I agree with @debacle here

you could just use a seperate browser or designated Firefox profile for Webchat, basically the same but even without #Electron

@Muto @strypey @debacle

#conversejs has some unique characteristics which no other chat app which I'm aware of has.

It has view modes, so you can have separate chat boxes overlayed over an existing website, a fullscreen app or an embedded "widget".

It's pluggable and you can remove core plugins to shape it into the form you need. E.g. you can remove groupchats entirely, or the roster view or OMEMO etc.

Almost anything is changeable or overridable and it has lots of configuration settings.

@Muto @strypey @debacle

It's not meant just as a standalone chat app... it's built to be as versatile, customizable and configurable as possible.

In a way, it's a lot like XMPP. Everybody laments the proliferation of XEPs and the lack of a unified experience.

I agree when seen from a certain perspective, this is a big drawback.

But the advantage of this approach is that you can use XMPP as a framework within which you can build unlimited functionality.

@jcbrand flexibility is great, but what it means in practice is that while all sorts of things can be built with core and different
combinations, those things don't automatically exist. They have to be defined as meta-standards, sets of XEPs that are compulsory to properly serve Use Case X (eg personal IM, team chat, social media).
@Muto @debacle

@jcbrand might get more uptake if every team focused on a serving a particular use case well, as apps have been doing more recently (eg for micro-blog, for video, for images). Rather than a confusing foam of mostly identical, outdated IM interfaces, most of which get developed for a few years and then die. There are great apps with solid development teams, like and , but these seem to be the exception.
@Muto @debacle

@strypey @Muto @debacle

> #Jabber might get more uptake if every team focused on a serving a particular use case well

"Uptake", while desired, is less important to me than being able to earn a living off my work on Converse. Being able to do that makes this project sustainable and viable long-term.

Slack is a 16 Billion dollar company, the only way I can "compete" is to do what they cannot do, which is to make the project as open, customizable and configurable as possible.

It's a true dilemma indeed. If a company tries to compete with Slack, their primary concern is to be as reactive to user demand as Slack is, because that's what Slack users expect. So there is little incentive for them to adopt open standards that might slow their development process down.
@strypey @Muto @debacle

@stevenroose unless your project is an itch-scratching hobby and you don't care if you're the only person that uses it, being responsive to user feedback ought to be standard practice. So my questions here would be; why would implementing an make a developer's that harder, instead of easier, and what can be done to reverse that? Off-the-shelf federation libraries in a range of languages? Community forums where implementers can support each other?
@jcbrand @Muto @debacle

@strypey @stevenroose @Muto @debacle

> why would implementing an #OpenStandard make a developer's that harder?

In some ways it's easier, in others harder. It's easier because difficult problems (like federation) have been solved.

It's harder because you can make fewer time- and complexity-saving assumptions.

For example, if your eco-system supports only one chat client or one server, then you don't have to deal with feature discovery at all. That's a lot of complexity avoided.

@strypey @stevenroose @Muto @debacle

I've noticed something similar with open source code in general.

When writing FOSS, you often have to write more generic code and take more edge-cases into consideration than when writing closed-source code where you can make all kinds of time-saving assumptions on how the code will be used or executed.

Writing more abstract or generic code is often harder, but if done well it results in much better code quality IMO.

@jcbrand sure, like I said Converse is an example of how to do Jabber dev right. It does one thing (web-based personal IM) and does it well. A network of Converse instances on community-hosting groups running a Jabber server (eg , ) would be sufficient to create a user-friendly federated IM network. Especially if the instances were configured to warn users before accepting connections from client/servers that can't fulfill the promises made by the Converse UI.
@Muto @debacle

Next time someone wants to create a web-based Jabber client, they would be better to make something different, eg a -like team chat UI, and again, have it warn users when they're connecting to a client/server that can't fulfill all its UI promises. That way the flexibility of actually serves an asset, not a liability (user confusion), and the existence of multiple clients serves a useful purpose, rather than just reinventing the wheel and then dying.
@Muto @debacle

@strypey @jcbrand @Muto @debacle That's exactly what we're planning to do with @kosmos chat. Originally even on IRC, but we'll base most of it on XMPP now.

Sign in to participate in the conversation
Mastodon - NZOSS

This Mastodon instance is provided gratis by the NZ Open Source Society for the benefit of everyone interested in their own freedom and sharing with others. Hosting is generously provided by Catalyst Cloud right here in Aotearoa New Zealand.