How is ejabberd or XMPP in general doing these days?
I remember Nintendo adopted it for their push platform [1] but it was old news. Are there any interesting development and/or adoption stories in recent years?
Modern versions of ejabberd and MongooseIM are much better than earlier versions in regards to scaling. But XMPP is still a mess. If you need to develop a custom messaging app, it's much better to start from a clean slate, rather than trying to fit your data and interaction models into an XMPP framework. As a transport you can use Websockets, MQTT, and/or GraphQL.
The main problems with the earlier versions of ejabberd were:
1. Using Erlang strings (linked lists of UTF32 codepoints) instead of UTF8 binaries, which led to 16x more RAM use.
2. Over-reliance on Mnesia for session management which is a maintenance nightmare when used in large clusters. Now it can be replaced by Redis or your own DB.
3. Non-scalable default implementations for mod_muc (Multi-User Chat) and mod_pubsub.
4. Absence of built-in mobile push support.
That was before WhatsApp, which later committed upstream many of their scalability improvement to the BEAM VM.
Source: I scaled an old ejabberd cluster to 500K concurrent users, and wrote my own Erlang-based Long-Polling/Websocket Pub/Sub servers and MQTT brokers scaling to 1M concurrent connections per node in a cluster. Also Elixir-based specialized messaging systems.
> Please refrain from developing custom messaging apps
I fully support this sentiment when talking about consumer messaging apps.
I once joined a hackathon where organized asked participants to use 4 different consumer messaging apps, each for a different purpose.
It's a mess, not sure if Google's RCS will solve it. Maybe governments need to force interoperability by law.
What I meant by "custom" is "industry-specific". One of the first B2B uses for Instant Messaging was in Finance/Trading. There are many industry-specific messaging apps, each answering specific needs and/or compliance/regulation issues.
Also in many cases you need a messaging/notification feature for an existing app, and using a full-blown messaging service is an overkill and/or doesn't fit your app.
> Please use standard existing protocols. If XMPP is not your jazz, there are others.
I did lots of XMPP-based projects. I also developed my own MQTT brokers/gateways. I'm following Matrix development.
MQTT is too lightweight for human messaging. Matrix is certainly better than XMPP, but it's not designed to be easily embedded into an existing app. You have to write a bridge which is problematic. Matrix is really a decentralized conversation store rather than a messaging protocol.
Snikket isn't just an Android app, so it's unfair to dismiss it as such. Sure, the Android app is based on Conversations. We sponsored some features, such as the easy onboarding flow which is a big part of Snikket, but also available upstream.
But there is also an iOS app and a self-hostable server. All these components build on open-source projects (working with and supporting upstream whenever relevant).
Our goal is to have a suite of software across platforms that is a consistent, integrated and family-friendly while being fully open-source and open standards: https://snikket.org/about/goals/
As of 2 years ago, there were good XMPP clients for every platform except the iPhone. On the server side, both ejabberd and Prosody are in great shape. There is zero excitement for administering them.
With ejabberd, your scalability problem is that you don’t have enough users to load a single node. So you have a popularity problem, but not a technical one.
To get back to familiar technical ground, try Synapse. A node can support, like, 3 concurrent users.
I wish you would joking. But it doesn't depend so much on the users but more on the size of the room / amount of events and the amount of other servers in the room.
I hope someday someone pulls off an memory/cpu efficient matrix protocol implementation. https://conduit.rs/ looks good and there is still work on construct the c++ server: https://github.com/jevolk/charybdis - but both only implement a subset of the rather huge and complicated spec at the moment.
There are several talks by WhatsApp people who describe how they're scaled their systems. They run on FreeBSD and used Dtrace to quickly find bottlenecks in the BEAM VM. BEAM has a very good builtin instrumentation, but if you're only looking on them, you're missing a lot. Also they committed upstream many of their improvements.
Not only WhatsApp, but also the initial implementation of APNs (Apple Push Notification System) was based on ejabberd. They even used the same port numbers.
I did an ejabberd scaling training in SF in 2011, and there were several Apple guys. It doesn't mean that they're used ejabberd for sure, but it's a hint.
I like the federation abilities of xmpp and ran ejabberd for a previous job. It’s perfect for an organization … in theory. Client support for the protocol was always hit or miss though.
Have file transfers over xmpp gotten any better in the last decade?
Haven't tested much. But I think HTTP upload is reliable and has been ok for me on Snikket server (Prosody) between Snikket clients (Conversations) and between Snikket and Gajim.
I remember Nintendo adopted it for their push platform [1] but it was old news. Are there any interesting development and/or adoption stories in recent years?
[1] https://www.process-one.net/blog/ejabberd-nintendo-switch-np...