I'd really like to see a group of #Jabber champions take the #Riot source code and modify it to connect to servers using #XMPP, #MUC, and #OMEMO, instead of the #Matrix 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.
#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.
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 #XMPP core and different #XEP
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).
@jcbrand #Jabber might get more uptake if every team focused on a serving a particular use case well, as #fediverse apps have been doing more recently (eg #Mastodon for micro-blog, #PeerTube for video, #PixelFed 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 #Conversations and #Conversejs, but these seem to be the exception.
> #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 #OpenStandard 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
> 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.
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 #Disroot, #libremOne) 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.
Next time someone wants to create a web-based Jabber client, they would be better to make something different, eg a #Riot-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 #XMPP 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.