I miss the "golden age" of chat where I could talk to anyone (google/fb/msn messenger/aol?) with my own jabber server. Pidgin was a great client at the time.
I've been looking for a modern self-hosted chat solution. I want it to be XMPP so badly (running XMPP with something like prosody is so convenient). The clients are really letting me down though. Desktop clients are old-fashioned and awful (I could get behind that, but I don't think my kids could). The mobile situation is even worse.
The new-fangled chat solutions (Matrix, Zulip, etc.) are interesting, but the operational requirements are insane (in the case of Matrix, I'm also very nervous about reliability).
I can't say I'm super hopeful, but I'm rooting for you, XMPP.
This golden aged failed when it missed the boat to go mobile. Ridiculous to think that none of the messengers from this time could envision to sync with the mobile phone's address book. I don't think we would have WhatsApp or Signal if any of the desktop chats had allowed that.
Arguably, they were killed by the mobile platform-owners.
Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.
Nah, they were killed by XMPP's braindead protocol design that made it useless for multiple clients. Apparently the idea that people might want to read messages on both their phone and computer, or on two computers, was completely unimaginable for XMPP, despite every other messaging system doing the sensible thing. Eventually there was an XEP ("Message Carbons") to give the basic sensible functionality, and eventually eventually most servers more or less supported it and it more or less worked most of the time, but that killed XMPP on mobile long before push notification platforms were even a thing.
That indeed was a problem that hurt it badly, but XMPP is also old. If I remember correctly, supporting multiple simultaneous clients at all was more than other contemporary IM systems did.
This is certainly not a problem with XMPP now. I run my own XMPP server and use XMPP to share things between my different devices. I have multiple accounts logged in from multiple machines all day every day.
What I really like about XMPP is that I can do precisely this. Also, setting up and running prosody is dirt simple if you have any UNIX experience. IMO it's even simpler than running your own web server.
Exactly. XMPP's a little younger than AOL, but the idea of having more than one device connected to the Internet and using them simultaneously, was sheer opulence at one point. Combined with XMPP being an open protocol and difficulty incrementing protocol versions, lead to the shortcomings described.
From my memory at the time AIM and Skype would both Just Work. I think maybe MSN would forcibly log you out if you logged in on a second computer? (Still better than continuing to route messages to your other computer, which is what XMPP does by default).
> ...has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it).
Not understandably at all, the reason for the lockdown is not for your benefit even if it is portrayed as such. Push notification can be run just like SMTP and is subject to the same type of abuse with the big difference that it actually easier to keep the spammers out since you know up front which senders are allowed to send notifications. It would be fully possible to self-host a push notification daemon which connects to those services which are meant to send you notifications, to which your devices connect for notifications. If you don't want to self-host it would be possible to choose a notification service just like you can choose an email provider. Things could be just as hands-off as they are now without being forced to open an Apple/Google/Microsoft account and hand over your communications to them.
Don't be fooled by these 'for your protection' lockdowns, they are for the benefit of the one doing the lockdown, not for your own.
Those kinds of systems tend to have been created and popularized before any single large actor appeared and started using it. Push notifications were single-actor from the very beginning. Decentralized setups in that situation are much more expensive to build and run - with the exception of "from the goodness of their hearts" projects, a business has little reason to make the sole implementation vastly more complex and open to abuse.
And tbh I'm not sure SMTP serves as all that positive of an example. It works, sure, but the reputation system and extreme complexity that has sprung up around it makes it difficult for newcomers to join - I can't just host one from my house, most email hosts will reject my emails. It works in spite of all this because it has too many large actors already using it for any new ones to stand any chance of rejecting (or improving) it.
You absolutely need push on iOS and modern Android. S60 and Android before doze didn't because you could just have a connection in the background; afaik, BlackBerry didn't restrict background data either. But it's not like there was a lot of good mobile XMPP clients that died out when push became mandatory.
If there was, it wouldn't take much to make an XMPP extension or three for the client to provide a push url to the server. Client devs would (probably) need to standup a push proxy, so xmpp server pushes to client server pushes to client, because I don't think many platforms give out push urls that can be securely passed on to 3rd parties. There's some expense there, but not a whole lot, IMHO.
I feel like I must be misunderstanding what you're saying here, at least in the last sentence. I think of "first party" as "platform owner" and "third party" as, uh, not the platform owner, but third-party real-time messaging apps obviously can send push notifications on iOS and Android.
While it's been an awfully long time now, I seem to remember that services like AIM didn't successfully move to mobile because they required stateful connections similar to telnet/SSH, and that was something that just wasn't (and largely still isn't) possible under iOS.
Since we're talking about a federated system (xmpp as a whole), I mean "first party" as in "an xmpp ecosystem runner" like google used to be. And "third party" as "any other implementation".
Google had an xmpp system (google talk) for which they have a first-party app which they send push notifications to. No other xmpp app can take advantage of that for google accounts - they all need to run, essentially, an xmpp-bouncer + their own push notification infrastructure and client implementation.
In ye olden days, a google-free version for google-free xmpp accounts could not be built in many cases, as the mobile device's APIs wouldn't let you hold open connections in the background like that - that was unique to the platform-owner (Android / iOS). Now you basically can, but each implementation increases battery use, so there's a fair bit of pressure to use the built-in one instead... which you can't do, Google won't send your app any push notifications that are intended for their apps.
---
The same thing applies to email apps, for example. IDLE just plain doesn't work well enough on phones, so email apps build their own email backends so they can use google's push notification infrastructure to push notifications for google-owned email account events. Google is the first party here, owning the email account and infrastructure, but not sending notifications to other email applications.
And also for basically any third-party app for basically any service. E.g. Talon (a third party twitter app) has to resort to polling Twitter's API to do anything. But those at least aren't federated systems, so though I'm still a bit sad about that, it's much more understandable that it happens.
Blackberry had their own software (BES/BIS) running as an intermediary between email and their devices. Were they using the same method for chat apps too?
While a lamentable situation, this has been addressed to a considerable degree and it's not all that bad. For example Matrix has its Push Gateway API (https://matrix.org/docs/spec/push_gateway/r0.1.1#id4) which allows any client to register any kind of push service. This means that any given iOS app, for example, can maintain its own backend for feeding events into APNs like Apple requires. I'm not as familiar with it but I believe XEP-0357 does something similar.
It's mitigated in several ways. But first of all consider that XMPP is hardly inefficient by today's standards, when mobile devices can stream video continuously for hours on a single charge.
Still, battery is important to consider, so what have we done in XMPP to improve energy efficiency in the past 15 years?
One of the first things we did was define a way for clients to reconnect a session that suffered a broken connection - the classic "I just went through a tunnel" scenario. With this optimization we gained two things: a way to quickly reconnect without resynchronizing everything, and a guarantee that no traffic was lost in the process due to the network interruption.
Secondly, we've implemented traffic optimization in servers. Clients will tell the server when they are idling in the background, and the server will stop sending any traffic that isn't time-sensitive. As soon as the user focuses the app, it tells the server and the connection switches back to "real-time" delivery. This behaviour helps keep network activity low when the client is in the background, and prevents continuously waking up the device's radio (such wake-ups can be quite power hungry over the course of a day).
Finally, modern mobile XMPP clients support push notifications, which is the Apple/Google sanctioned way of solving this problem. It means that you can safely close the XMPP client entirely and still get notified when you receive messages.
There's probably more besides these things that I've forgotten but I think these changes are the highlights!
The Palm Pre actually had a really nice mobile messenger. It synced with Address Book, supported SMS, Jabber, Facebook Messenger (back when it was jabber), aim, and others. It would seamlessly switch protocols based on how the contact messaged you. Like most things with the Pre, it was way ahead of its time.
> This golden aged failed when it missed the boat to go mobile.
There were plenty of mobile applications that supported multiple chat protocols. There might even still be. The issue is proprietary protocols would often change breaking support -- I suspect intentionally breaking support for 3rd party client.
Linux / Unix nerds running FOSS would be tolerant of that but I suspect your average smart phone user who might have spent 99c on the client would be less understanding.
People weren't polite on the internet in the 90s! There was plenty of trolls even back then. Plenty of spam too.
I'm ashamed to admit this but I even wrote software what ran on Windows 95 and would spam chat rooms with thousands of phrases generated on the fly from a dictionary. The intention was it would run over a RAT (also of my creation) and get other people booted off the chat room. ie the spam would be posted by other people in chat rooms against their will and channel admins would then kick them. I wrote this because at college we "only" had dual ISDN lines and kids in chat rooms would slow down my warez downloads.
I know, I know, the justification is worse than the tool itself. But we were young, I've grown up since and these days the lessons I've learned from my college exploits are put to good use :)
Yeah! I ran my own XMPP server on my home network and used it to accept status messages from other boxes on my network. Worked really well. The clients were generally horrible though, especially the IOS ones. I've now switched to MQTT.
I've been looking for a modern self-hosted chat solution. I want it to be XMPP so badly (running XMPP with something like prosody is so convenient). The clients are really letting me down though. Desktop clients are old-fashioned and awful (I could get behind that, but I don't think my kids could). The mobile situation is even worse.
The new-fangled chat solutions (Matrix, Zulip, etc.) are interesting, but the operational requirements are insane (in the case of Matrix, I'm also very nervous about reliability).
I can't say I'm super hopeful, but I'm rooting for you, XMPP.