Last time I checked around, XMPP didn't have a client that I could recommend to business clients that looked easy/simple to use, has no gotchas and looks native.
Currently I use Mattermost, which does basic things fine and things are stable but the formatting is just getting in the way making texts unnecessary big and bold when people never intend to (there is a per user setting to disable formatting but I can't tell everyone to turn it off), and reply and quoting interface is just wrong and I never use it, so most of the other people use another vendor service which is easy and does things in a saner way.
And video/voice is apparently not in their integrated goal and is thrown to some external paid service, so pretty much only simple text and file uploads.
I'm not looking for anything too special in my opinion but I find it there's no self hosted solution that has,
- Simple interface so I don't have to lecture people 10 minutes on how to use it.
- WYSIWYG formatting instead of automatically parsing symbols into bold texts etc
- File uploads
- Decent reply/quote feature
- Multiple people voice call
- Optionally multiple people video calls
- Native clients for desktop and clients and web Interface
WhatsApp is the most popular chat app among non-technical users in the world, and it explicitly uses symbols instead of WYSIWIG for formatting.
I'm pretty sure you're making up these requirements without actually researching your target audience.
I'm barely mentioning the features which people would generally expect out of chat apps.
Regarding the WYSIWYG, I always hear complaints, including myself that texts get weirdly formatted when they paste from somewhere else and it does more harm than good when symbols are automatically parsed, so the other option would apparently be WYSIWYG editor, which anyone will have no problem comprehending how to use.
You can't just expect everyone to read and learn formatting rules to type. I'm an engineer but I don't even want to remember some Mattermost formatting rules to avoid unintended transformations.
Assuming you know the minimum features non-technical users want/need in such a tool is going to exclude a lot of options that might otherwise be viable.
WYSIWYG is probably the canonical example of this: non-technical users DON'T need WYSIWYG.
Slack has been the (non-self-hosted) solution du jour for what you describe. My company use Slack and we have thousands of non-technical staff on it: complaints were rife when they recently introduced WYSIWYG and we continue to get requests for help in disabling it.
For the future, I think Riot is your best bet. Matrix may suffer the same fate of XMPP, but if it escapes that fate, it'll be because of Riot.
It doesn't tick all your boxes yet, but RiotX is a hopeful project in terms of native, and the integrations it supports make a lot of features easy to add in some usable capacity.
Can you tell me how they don't like it?
Do they rather want auto formatting like markdown or no formatting at all?
The present is, however, Slack.
Actually, in terms of number of users, the present is MS Teams. Both companies release their numbers and it's not even close.
Web version is rather mature already, with android / iOS clients coming to shape fast and will soon be released. We'll likely make an Electron-based desktop version, though of course it far from ideal
However, doing all this great stuff we had to replace many common XMPP extensions, like multi-user chat, which is utter garbage. The replacement works like ... well, Telegram groups, has nice fallback capabilities to legacy clients and is generally very well working.
Building for the web first and porting to Electron for desktop and webview for mobile is good as you can have identical interfaces for users to switch between and less bugs to chase for developers and I see no downside with that path.
I understand multi user calls/videos isn't simple as I still use Skype just for that for a group of people and it seems to do that part fine.
In any case, I may have to give this a try - I used Xabber a bit on Android years ago.
[1] - https://delta.chat/en/
What advantages does this have over Pidgin?
There is probably also other examples of XMPP features that Pidgin does not and likely will never support, due to its nature of being multi-protocol (basically limiting features to the smallest common feature set).
For a desktop XMPP client, check out Gajim. It's stable and implements all that a user would expect (server side history, omemo).
> A number of clients already exist for the XMPP protocol, however Dino sets a different focus. Existing clients target tech-savvy power users. The XMPP ecosystem lacks a client that is enjoyable to use while providing the features people expect from a modern chat application.
What I don't know is how this is different than gajim.
I think it's high time we had a concerted effort to have one great UI (probably per platform), and allow all protocol enthusiasts implement the specifics of their own choosing. It's fair to say that at this point the requirements for a "modern" UI are known, and while not all protocols may be up to the task, a very high percentage can be implemented in the most famous ones.
An effort that simplifies channel maintenance, like how easy it is to open a new Subreddit (the #1 portal, a static website URL representing your community identity) is the most important step forward.
Once you establish a www identity for your community, then and only then can you discuss community chat.
For example, lobster.rs community meets on IRC FreeNode, a protocol established on their about page.
------
The reason Reddit, Facebook, and Discord are popular, is because of the easy web-based onboarding process for new users. There are also web guis which make it easy to start new communities.
Support the WWW first, and users will come (as long as the onboarding process is as easy as competitors)
XMPP was primarily about person-to-person communication, with group channels being a separate add-on.
Part of iMessage's popularity is the ability to have group conversations the same way as those person to person communications - to the point where SMS users may get excluded from conversations.
IRC is just a terrible architecture which is exposed in its protocol, but it will survive a long time because you fire it up to participate in a community, not just to talk to an individual person.
IMHO paid tools like Slack got adoption when we had pre-existing protocols and clients for decades prior because it works as a package community-as-a-service (imho, to the point of being a detriment to usability). We had the technology to solve the problem, but the packaging and focus made it a legitimate product.
Probably any single protocol could be used to build a client that Slack or WhatsApp or [insert your target here] users would appreciate with good designers, (and/or with really little to no education.)
Multi-protocol clients are generally not optimal. The set of features that can be used will be the lowest common denominator, and if it's not the case there will be discrepancies in the design.
(Same story for bridges.)
Every protocol has their set of trade-offs, and every developer has their opinion on what's best (or the least worst). Also not every developer work with designers or have designing skills(!)
It's good for developers to be able to write what they want and how they want it. It's fine if their intended target is already with their circle of friends on the platform (if their is a target at all). It's less practical if the target is outside and their circle is not on the platform (network effect/peer pressure etc.).
That's a general "issue" in Free Software, (I'd say in software, maybe anywhere? it's just more visible here.)
Some might say waste of resources, but who gets to decide what to do with others' free time.. no easy answers.
(Sorry to spoil the fun by trying to rationalize :p)
I for one value freedom, through decentralisation (or federation as some like to insist on), and as technicalities I believe standard and extensibility of said standard are necessary. XMPP seems to fit this role ok enough to me.
I'm not even talking about multi protocol clients because, as you said, it tends to level downwards rather than upwards. But if I could "fork" the UI and slap my protocol on it, instead of having to build it from scratch, I'd save a lot of time.
> A decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB). https://www.scuttlebutt.nz
Dino really fell short for me in my needs for XMPP client, though I'm happy to see federated systems and their clients being promoted.
Specifically Dino has issues with OMEMO support with Conversations, while Gajim does not see these issues. This means I can use Gajim on my computer and Conversations on my phone without issues.
Dino has a very limited plugin system, extending it is planned for future releases. We are also interested in adding support for A/V calling and we already have some pieces of code for it, though nothing in a quality for actual usage.
Not everyone has to use the same thing.
As you said: Gajim does lots and lots of things, some of it only half-works. Gajim might be good for some people, but confusing for others. I probably wouldn't recommend it to my mom.
Dino has a good feature set and the user interface feels nice. It doesn't do everything, but that can also be a positive thing. Dino's OMEMO works fine for me.
It is fairly useless on dark theme, rendering grey on grey for the backlog.
Apart from a missing status notifier / appindicator, gajim is miles ahead.
XMPP, like email, is not a 'decentralized' protocol, but a federated one. If you and your chat partners use the same server, it would be as centralized as WhatsApp or Signal.
This makes sense, because Baran was describing a communication network, like later ethernet, where nodes were interchangeable, wherever in XMPP the nodes are not interchangeable: if you have an account on xmpp.org server, you can't connect to xmpp.jp server and receive your messages. Thus, such networks required a special more narrow name to define it.
[1] https://networkcultures.org/unlikeus/resources/articles/what...
It is decentralized in theory (no one server controls the network), but 'federated' is the correct word to use here.
When I saw the title I was assuming this was some cool new sort of client that created and managed a bunch of logins/identities as one on various XMPP servers and used something like OMEMO for key management on top of that 'layer'.
Tox is a better example of a 'decentralized' protocol.
Beside that, Dino does support peer-to-peer file transfers using Jingle.
What's the goto XMPP service these days?
EDIT: I might have misunderstood "service" thinking you wanted to self-host.
One question though: is Windows version planned?
It's definitely something that is now becoming more relevant after the first release.
Crucially: If I have Dino, can I chat with any of my friends? Or do I need to persuade them to install Dino & create an account somewhere first?
JIDs look like email addresses.
Unless you want to run your own XMPP server, you can register a JID at one of the public XMPP servers: https://list.jabber.at/
It was pretty much impossible to run your own server for fun unless you registered a domain or two because of the serious business logic baked into the design of the protocol.
Ages ago when I was working on a replacement for IRC for an organization that needed to decentralize its servers because they had a lot of users spread across the world behind iffy internet uplinks but all on the same domain this was a huge headache. The old IRC system worked really well for them, but some of the higher ups were upset because it wasn't "enterprise quality" and thus shouldn't be on their network.
If you had multiple domains that you wanted to connect the servers would also default to xmpp.other.domain.
If you wanted to connect to test.my.domain to test2.my.domain you were SOL. In a lab environment you could hack it with local DNS fuckery, but to actually deploy it would have been a nightmare. The whole thing assumed the entire domain would be served by one single server and all clients would always have good connectivity.
Their old IRC model was just to have a local server at each site with a cache. When the network went down (which it did frequently), the local users would still have connectivity, and when the link came back up they would get the backscroll. Replicating this sort of config with XMPP turned out to be very difficult, and eventually the bosses relented and let them keep IRC, or at least they passed the problem off to someone else after I left.
My question is what does matrix do better than xmpp. What does xmpp do better than matrix?
However, the protocol itself is governed by the Matrix.org Foundation acting as a neutral guardian (https://matrix.org/foundation/), so it unclear how the spec itself would become part of the product.
To suggest that Matrix itself is not well suited to chat is to ignore the rapid adoption of the protocol now used by millions of people.
What is your motivation? Surely you're aware of the abundant amount of XMPP client applications that have existed for the better part of the last 20 years?
> A number of clients already exist for the XMPP protocol, however Dino sets a different focus. Existing clients target tech-savvy power users. The XMPP ecosystem lacks a client that is enjoyable to use while providing the features people expect from a modern chat application. Dino fills that gap by aiming to be secure and privacy-friendly while at the same time providing a great user experience.
