Dino: An open-source application for XMPP messaging
dino.im
dino.im
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
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.
What's important is that when you log into your email account, you're logging into Teams, Planner, etc. I recently started using Planner, as awful as it is (seriously, you can't even drag cards!) because I can't expect others to adopt a new tool.
XSF contributed the XMPP spec to the IETF after ~10 years, Matrix is a younger protocol (2014) and perhaps it will do something similar in the future.
Given the adoption rates of Matrix, I think it is fair to conclude it is a good fit for chat. Though it is fair to call out that it works quite differently under the hood from many other chat protocols. The decentralised architecture adds a resilience not possible in a purely federated system.
The Jabber project started in 1999 and https://tools.ietf.org/html/rfc3921 was published in 2004.
https://mail.jabber.org/pipermail/xmppwg/2002-May/000000.htm... suggests that the IETF process was already started in 2002.
In any case Matrix would not rule out working with the IETF in the future, but for now the Matrix.org Foundation manages the governance of the protocol.
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?
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.
Our approach does not require anything from a participant's server, and it does not even require a specialized support by a participant client: a reasonable fallback is provided for legacy clients, even if a participant is connected using 2 clients, one of which does support the new standard, and another one does not. It was achieved by clever dancing around how message carbons work and allows to sync clients nicely.
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.
All I can say is that I see that successful chat apps for 'normal people' seem to have converged on something that isn't WYSIWIG, and it's probably not an accident.
P.S. Asking users what they want probably isn't the best idea. See "Homer's car" for a humorous take on this issue.
[1] - https://delta.chat/en/
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.
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.
IRC is for public channels (and supports direct messages). It’s far from perfect, but I wouldn’t call it terrible; it works very well for its original purpose (and has been for almost 3 decades now).
Servers in a network generally have little to no proper recovery from partitions/splits, and a split may result in changes in moderator/administrative users due to the lack of persistent permissions. There is no attempt to recover discussions during a split, or to apply consistent ordering to communication. Splits, which should be transparent, become a highly impactful event to the users within a channel.
Due to the lack of packetized responses and the simplistic method of determining an active TCP connection, it is possible to (for instance) be disconnected because of asking for a list of channels on a slow connection.
It has a _lot_ of problems, and most of the ones I listed are at the network protocol layer. It is still usable for environments where there are very active administrators and few to no bad actors, but it falls apart quickly on the public internet.
You are going to be more suspicious if you are using $protocol-specific-for-encrypted-chat than if you are just browing the web.
> Bits are bits
I agree, but this does not stop my ISP from throttling my SSH speed.
There are also replay attacks and probably many other issues I can't think about. Maybe some IM protocol already deals with that.
> A decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB). https://www.scuttlebutt.nz
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.
What advantages does this have over Pidgin?
> 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.
Although IIRC Pidgin also stored network credentials in plain-text file. Maybe that has been resolved in the past 10 years?
So rather than a reversible cypher they leave it plain so that their users will freak out and /not/ share their files with folk and will properly lock down their creds file.
It might be due to Pidgin's age but in modern programs storing this data in plain text should be a last resort for systems that don't do secret management for you.
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).
One question though: is Windows version planned?
It's definitely something that is now becoming more relevant after the first release.
I'm genuinely fascinated: what was your mindset when posting this?
It's a fair enough comment to make — the notion that mass adoption comes by catering to the masses is not one that should be so readily dismissed with a downvote and aggressive italicisation.
In a discussion of an XMPP client that's specifically designed for mass appeal, in this modern world of iMessage, Facebook Messenger, WhatsApp, Slack, and Discord, it's a perfectly reasonable point to bring up.
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?
What's the goto XMPP service these days?
EDIT: I might have misunderstood "service" thinking you wanted to self-host.
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.
>If you had multiple domains that you wanted to connect the servers would also default to xmpp.other.domain.
This seems strange. XMPP has SRV records specified for discovery of the client endpoint, so the "correct" thing for a client to do would be to look up the xmpp-client SRV record for your domain and attempt to connect to that. It's possible that some clients had a fallback to prepend "xmpp" to the domain, but I'm not aware that that's ever been standard practice - more commonly they'll fall back to an A record lookup on the domain part of the account.
>The whole thing assumed the entire domain would be served by one single server
Certainly not. Clients will (or should, anyway) try connecting to servers based on their priority/weight in the SRV record: https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer
As GP mentioned, this does assume that you have servers capable of scaling horizontally, because XMPP is stateful. Not all can, but some do.
Your other option is just to give everyone their own XMPP address on a subdomain for each site - foo@dublin.example.com, bar@brussels.example.com, etc. I do this with a number of independent XMPP servers and it works fine. Then you're just depending on ordinary XMPP s2s to communicate between them, which is obviously well-supported.
It's not a friendly technology for enterprises where it might take weeks to add a DNS record, maybe. But nor is much else.
DNS SRV is just the easiest (IMO) and most widely supported method, so I generally recommend just doing that since you probably have DNS anyways, even if you don't necessarily have an HTTP server running on your chat machine.
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.
The matrix foundation has had trouble trying to fundraise to pay developers, it's not a proper non-profit standards foundation, in my opinion. I'd be skeptical of trusting them.
You can see numbers for the public network here (https://matrix.org/faq/#what-is-the-current-project-status), though these figures do not include installations that choose not to federate publicly.
The Matrix.org Foundation is a non-profit UK Community Interest Company. As you might expect, it accepts donations which can be used to fund work on the project. It reports publicly on its financial status in the same was as any other UK CIC is obliged to. This doesn't seem very controversial to me.
In any case, should you wish to donate yourself you can do so here https://www.patreon.com/matrixdotorg
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.
Beside that, Dino does support peer-to-peer file transfers using Jingle.
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.
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.