Jackal 0.54.1 – Go XMPP Server
github.comAny run down of the xmpp extensions it supports compared to something like ejabberd or openfire?
Edit: Found it:
https://github.com/ortuman/jackal#supported-specifications
Ejabberd in comparison: https://www.process-one.net/en/ejabberd/protocols/
It’s crazy how much stuff a mature xmpp server can do out of the box.
With stuff like "nicknames" being its own extension (xep-0173), the list gets long fast.
Incidentally, that one is missing from jackal's list. I wonder if that means that you can't set or see users' nicknames when using it?
If you mean XEP-0172 then there is no server support required. I don't know why it is on a list of XEPs that a server supports other than the possibility of using server side storage in the form of XEP-0163 (PEP).
You must not have seen sprint planning now days.
Go is a great choice for building an XMPP server. Solid performance, great developer productivity compared to something like C++.
I'm not entirely sure what use cases remain for XMPP in 2021 though.
Your notable open alternatives are Matrix or Signal. Matrix is a PITA to set up and admin and has all the issues you'd expect from a newcomer. It's fine if you like living on the bleeding edge, and has some promise, but isn't exactly "tried and true" yet and its software ecosystem is small and immature. Signal, OTOH, is only kinda, halfway, sorta, open. In both cases, your options for server software, if you don't want to step directly into "here be dragons" territory, are limited to at most two options, and options for client software aren't a ton better.
With XMPP it's easy to get a server running on dirt-cheap hardware, maybe straight from your favorite distro's official repo (you have multiple choices of mature daemons for your server), and it has tons of clients and client libraries on every platform under the sun.
Basically if you want to serve an open protocol for chat, with all the ecosystem benefits one wants from a protocol (versus an ecosystem that's, at least so far, tightly coupled to an official implementation), XMPP's your front-runner.
(I'm omitting IRC because its ideal use-cases are different from XMPP's, so they're not exactly competitors)
Matrix servers are now fairly simple to deploy. https://www.youtube.com/watch?v=dDddKmdLEdg I do wish the Element team moved a bit quicker at attacking Slack head-on. Element isn't super polished yet nor does it implement all the features built into the server/spec. So there is some catching up to do there. But the project is more than ready to use today at a large org and it includes a ton more features than what you get out of the box with an off the shelf XMPPd. https://joinup.ec.europa.eu/collection/open-source-observato...
I run a Matrix server with Dendrite, it was pretty easy to set up. My biggest complaint is the RAM usage, but if you don't join large rooms it's fine.
My big dig against Matrix is that it is monolithic. By compare, XMPP's virtue is in the very first word of it's name: Extensible (of Extensible Messaging and Presence Procotol; really: Protocols).
XMPP is designed to be grown, to have new capabilities added, to be experimented with. XMPP was used to build Google Chat's video conferencing a long long time ago (Jingle) because it was the only sensible straightforward chat system out there built for extensibility, built to be grown on. XMPP has all manners of neat uses, from IoT to VPNs (EdgeVPN) to nearly anything else you could imagine.
A lot of people seem to like the authority & control & centralization of systems like Matrix, but to me, this consigns away the future for an easy convenience. It restricts what a thing might become. I value loose coupling, I value extensibility highly, and XMPP continues to be an evolvable, changing, enhancing set of technologies that stays relevant because Extensible leads it's design. It's something Matrix will not nor ever could compete with, and to me, it nearly certainly dooms some latter version of Matrix to obsolescence: there will come a point when the bad choices have added up, and no progress can be made.
Let's take a little case study example. XMPP itself faces a moment of crisis now, imo, with Multi-User-Chat (MUC), which is a very not good experience & technically crufty; a very early specification that has really obstructed chat rooms from being good & let Slack et cetera take over & dominate. There are some attempts to fix MUC but the tech underpinnings are, imho, bad. The good news? There is a much wiser, much better engineered alternative, MIX, that builds upon many of the other XMPP standards that have emerged over the years & stood the test of time. MIX is a way simpler, way better, way smarter way to do chat in XMPP. The ugly? There are nearly no clients that have implemented MIX. Not a lot of xmpp servers have implemented MIX. Trying to drive adoption of this thing necessary for XMPP to survive has been hard going.
But still, to me, even with this struggle, even with these huge pains, & a non-adapting future, I still think this case study hugely shows the need for Extensible systems. This is just one realm, one battle being fought, amid a system that made up of a bunch of different components. Matrix might be able to muster up the need for serious breaking changes, but my feeling is that the concensus based, forward moving innovation of Matrix will keep adding decisions & technical nuance & capabilities forever, and will likely never have the chance for redress & re-appraisal that XMPP by it's nature, by it's namesake, promises. XMPP can re-orient, learn, adjust. Nothing prevents Matrix, with it's monolithic , core-contributor-driven specification system from making radical changes, but they will forever lack the outsider perspective & autonomy that folks can bring to XMPP specification development. Matrix can't be the platform for a next-Google to build their next-chat VR platform on, because Matrix is not extensible, it's not a system of protocols: it's monolithic, it's top down, it's structured for linear, forward progress, not the free innovation that extensible systems are designed for. Matrix has many decades of wonderful innovation & advancement to go, but to me, it's already a dead end, it's already made it's bed, where-as XMPP will always have a freer hand to keep becoming more, freer hand to becoming something different, is always available for radical innovation (such as EdgeVPN, or IoT).
> XMPP is designed to be grown, to have new capabilities added, to be experimented with.
so is Matrix.
your entire post is based on a wrong assumption...
I don't see any technical evidence of that. matrix is a single unified protocol, maintained by a small core contributor group. matrix has no extensibility mechanisms. not sure how you can make a claim like this.
There's a process, guided by core team members, to contributing to the one specification.
This does not sound like extensibility at all. It's monolithic development. Gated by a core team.
> I'm not entirely sure what use cases remain for XMPP in 2021 though.
So many! The first obvious use-case is federated, encrypted instant messaging. The only two alternatives are delta.chat and Matrix. Former is pretty cool (everyone has email right?) but lacks good desktop clients, latter is pretty cool (decentralized rooms, "spaces") but server-side recommended software is resource-hungry (but conduit.rs is an ongoing alternative) and client-wise there's only one client that implements all features and it's a web client which is really bad for security and reasonable resource usage (here again alternatives are coming like Nheko).
The Jabber/XMPP ecosystem is more or less advanced depending on what features are of interest to you: PubSub-based microblogging has been standard for years, audio/video used to be a disaster but the situation has greatly improved with interop between major clients... while IRC-like IM stuff has been working fine and stable for almost two decades, a timelapse during most people had time to change addresses at least three times outside of that ecosystem (IRC -> MSN/AIM -> GChat/FBChat -> Whatsapp/Signal/Telegram -> Matrix/Briar/?).
So what's relevant about modern XMPP specifically? Account portability is being worked on as part of the Snikket project, and ActivityPub interop as part of the Libervia project. The former is a complete client/server XMPP distribution for easy selfhosting (no hard fork, only friendly forks contributing upstream), the latter is a library for building native XMPP clients (frontends) more easily which pioneered federated forging (to replace Github & cie) and is currently using itself for its own development.
So not everything is perfect and shiny but XMPP ecosystem is doing good after all those years. It's pretty easy to selfhost a server and get started. I just really hope we have more cross-protocol cooperation to promote interop between the different federated networks. It's a shame that some federated ecosystems don't value interoperability as a key feature.
Please prove me wrong, but self-hosting an XMPP server isn't something you can just install and have it work, if your definition includes all the XEPs that you actually end up needing and chat working at a level of user friendliness people expect these days.
I spent over 2 days learning what was out there and installing Prosody myself, followed by giving up and hiring a guy with experience to do it for me, and it took him a solid day (spread out over 3) to get the basic system set up and mostly passing the list of recommended XEPs on the compliance tool at https://compliance.conversations.im/. Then it took another week of fiddling around to get everything mostly dialed in. Then we realized that the XMPP clients on iOS were unusable in a business situation (can't navigate to find old group chats, notifications sometimes don't work, message history sometimes didn't work) and had to move to something else.
Federation is a nice feature, but the rest of it needs to work well enough across iOS/Android/browser to not drive people away.
Following https://snikket.org/service/quickstart will get you a self-hosted XMPP running in minutes, with all modern messaging features you'd expect to be working out of the box.
On iOS it works with Siskin, Monal and ChatSecure, but you're right that there are some rough edges on that platform. We're working on polishing off those edges for a Snikket iOS client (based on Siskin).
Android is working well, and the plan is to work on a web client after iOS is released. In the meantime, https://conversejs.org/ or another generic XMPP web client can be used to log into a Snikket server.
I think there is nothing to prove, I set up my prosody just by reading the documentation -- eventually https://compliance.conversations.im/ is a great tool to see how well you are doing, and which modules are worth uncommenting lines from the initial config file. I have a functional and working server with just a score of 85%.
The only real pain point could be iOS, but it is the platform the one that makes things extra difficult, see for example what happens with browsers (https://en.wikipedia.org/wiki/Firefox_for_iOS)
> self-hosting an XMPP server isn't something you can just install and have it work
For basic needs ala IRC it should just work out of the box by defining a virtualhost. For respect of advanced features as defined in the XMPP Compliance Suites, it'll need a few more settings but there's good guides:
prosody: https://homebrewserver.club/configuring-a-modern-xmpp-server...
ejabberd: https://www.process-one.net/blog/ejabberd-xmpp-server-useful...
All in all it should take a novice (who has some experience of sysadmin, can deal with DNS records, firewall, etc) a few hours to setup to their taste... Or you could go with Snikket, a XMPP distribution, to have everything pre-configured in a docker container.
> XMPP clients on iOS were unusable
Sorry I don't know about iOS mostly because my acquaintances can't afford Apple devices and/or are not interested in a walled garden where a private company owns all your computations. Though i heard similar stories as yours, but there is progress with Siskin, with some development (eg. OMEMO groupchats) being funded by the Snikket project.
> notifications sometimes don't work
This may have to do with your OS settings. I don't know how iOS handles low power mode but i know for sure some Android distros restrict network queries (apart from the privileged, centralized push notifications service) and there's settings to uncheck for that.
> in a business situation
In a business situation you might find the resources to implement the features you need or pay someone to do it. I understand it may not be the answer you expect, but that's how free-software ecosystems move forward. In this regard, XMPP is not named "eXtensible" without reason.
> it needs to work well enough across iOS/Android/browser to not drive people away
Sure. I think that's the goal for everyone. If there's something that doesn't "work well enough" then it's a bug and should be reported then fixed.
When we did our testing we went through all the iOS settings and more than one user was testing on iOS. It was a client problem, not a settings problem.
Everything here sounds to me like "with a year or two of improvements, non-technical users might not run away screaming". I would love to use a federated chat protocol, but the reality is that XMPP isn't in the same league as other chat programs right now from a feature perspective, ease of installation, client availability, or user friendliness standpoint.
My company tried it, hard, for about 3 weeks. I paid something like $2000 in consultant and employee time to do that test. I was willing to deal with it because it was literally the only option in our case (we needed to avoid google push notifications). Once we realized we could make Zulip work by routing push notifications through a separate service we switched and almost everything about Zulip works smoother and with more useful features. None of these replies are convincing me that XMPP would work any better if I just knew more about how to install it right, etc. Again, I would love to use an open, federated chat protocol, but XMPP isn't useful right now in the ways I need it to be.
It's 2021, but people are still communicating online... so plenty? :)
XMPP is a great choice anywhere you want interoperable real-time communication between systems (either for person-to-person or machine-to-machine messaging). There are of course other choices as well these days, but all have trade-offs.
I believe it's the only major protocol that doesn't rely on google services for push notifications on Android and also has clients available in the app store on iOS.
So if you want to, for example, chat with people in China and avoid WeChat it's a pretty solid choice. Or if you just want to avoid google services.
That said, the clients available on iOS are lacking features you would really need in a business context. Conversations on Android is pretty good out of the box.
Believe it or not some of us still run private XMPP services so that we can communicate with our contacts in a private and secure manner....and it still just works.
How crazy is that?
For others wondering what XMPP is, here's a thing: https://xmpp.org/about/technology-overview.html
> XMPP is the Extensible Messaging and Presence Protocol, a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.
Click the link above for more detailed info
I haven't tried jackal yet. Has anyone here tried it? Could you compare your experiences with other XMPP server software?