@z428 the question nobody promoting #XMPP apps seems to ask is, does it do anything users need? As I said, I've been using XMPP since it was still Jabber. I still install XMPP apps on my laptop from time to time, and I have Conversations on my mobile, it's a nice UI. But do I use them? Almost never.
vibe@stevenroose@fosstodon.org @charlag @lightone


That's a problem with you not having friends on XMPP, not with XMPP itself.

I have most of my family on XMPP (mostly due to my awesome wife getting them to switch) and then about 100 other contacts.

@jcbrand fair cop, but it's not for lack of trying. I had more interaction in my first year on the #Quitter-era #fediverse than I've ever managed to get on the XMPP-verse, despite more than a decade of encouraging people to use it.


Back in the GTalk days, you could talk to your entire Google contacts list via federated XMPP.

So even back then I had way more contacts on XMPP than GNUSocial or Identica.

Google played a large role in killing off XMPP usage and the day they announced sunsetting GTalk was when I realized they're just another embrace-extend-extinguish monopolist.

Society needs self-hostable, scalable and functional alternatives to surveillance capitalist systems of manipulation and censorship.


I know I'm preaching to the choir, and I know it's difficult to get people to choose freedom and sustainability over temporary comfort.

It's the same problem with environmental destruction and reducing ones own environmental footprint.

@jcbrand I agree with you in general I just don't know if I agree with you about XMPP in particular. It may still have a major role to play in a federated future, or like UseNet, it might remain a niche for ubergeeks. There's a fascinating history of all the competitors to TCP/IP. Where are they now?



The protocol is used all over the place (Telecoms, NATO, Games, chat apps, IoT, chat ops) and I expect that to continue.

We might never see mass adoption of the idealistic kind.

That said, having a healthy XMPP ecosystem is still important even without mass adoption.

It provides an escape mechanism out of oppressive surveillance and I believe if circumstances were right (i.e. things get bad enough) it could gain mass adoption and be an important tool for exercising freedom.

> having a healthy XMPP ecosystem is still important even without mass adoption.

Replace "XMPP" with "federated" and we are in total agreement. I'm just not convinced that the particular set of tech standardized by XMPP is the best tech for the job, and the growth of other federation standards seems to suggest it isn't, at least for some use cases. I've seen it described as a "heavy stack".


> Replace "XMPP" with "federated" and we are in total agreement.

Obviously I support open, federated protocols in general (of which XMPP is one that I'm personally the most involved with).

> I'm just not convinced that ... XMPP is the best tech for the job

Depends on what "the job" is.

ActivityPub is tailored to different usecases.

There is some overlap between the usecases, so to some degree they are in competition, but there's more room for cooperation and IMO space for both.

> Depends on what "the job" is.

I don't have the technical knowledge to assess the pros and cons of the specs, or the protocols, formats etc they depend on. All I've noticed is that I've been enthusiastically promoting XMPP for any IM-like feature for years, but I've found it much easier to get the devs I interact with excited about newer tech like AP and WebTorrent. Maybe there's technical reasons for that, or maybe it's just people following trends. Who knows?


XMPP has proven itself, it's been around and it's not going anywhere.

The problems that people complain about (e.g. bad UX and ugly clients) has much more to do with economics than with the protocol.

Large players (e.g. Google, FB), want user lock-in, so there's no incentive to federate and use open protocols.

ActivityPub is riding the hype train that XMPP was on in the early 2000s.

That's great and all, and I'm very hopeful for its future, but let's talk in 15 years.

@jcbrand @strypey

the success of the protocol is entirely dependent on the quality of the clients. mastodon launched with OStatus, which had been around for a decade before the recent fedi explosion. only real difference this time around was the UX and availability of good mobile apps.

@xj9 @jcbrand @strypey Totally agree. That's why I'm so happy about Conversations for XMPP on Android for example. (Minus the hopelessness with that big iOS problem I just mentioned in another reply.)

@xj9 OMG, this! A thousands times this! As I said to someone else the other day, you can invent the most elegant and efficient back-end you like. It it doesn't have a great UX that drives adoption and network effect, you might as well tattoo your source code on the side of a herd of elephants, and compile it by starting a stampede ;-P

Best mental image of the week. File this along with the RITA Troubleshooter #RFC2321 and, of course, IP over Avian Carrier #RFC1149

Thanks @bobjonkman . BTW Great to see someone still using #GNUsocial. Do you know how their #ActivityPub support is coming along?

@jcbrand @strypey I've identified a major problem for XMPP adoption, since switching our company chats to it, and also using it a lot more for personal group chats and such: it's iOS.

The issue being that due to Apple forbidden background processes for 3rd party apps, and all notifications having to go through Apple servers, iOS users don't get notifications for messages easily or at all. It's a huge issue for decentralized apps, but not for centralized ones like Signal.

@raucao @strypey

The "Push Notifications" extension was created to solve this problem (and is used by Conversations since Android is also moving in that direction).

So I think that XMPP does provide a technical solution to the problem.

I've never used iOS, so can't comment on the clients.

Have you tried Monal? All I can say is that the creator blogs actively and makes regular releases.


@jcbrand @strypey Even with that extension, servers have to register with Apple and support APN. And also, there's currently not a single iOS client that has proper push notifications, even with the extension on the server. It's a nightmare.

@jcbrand @strypey Correction: it can be deferred to the app provider's server, but you still have a centralized bottleneck.

@raucao @strypey

The way it works is that you need a so-called "app server" which receives the notifications from the XMPP server and relays them to Apple (APN I believe).

This "App Server" is independent of the XMPP server.

Daniel Gultsch has written such an App Server which integrates with Google's push services.

Something similar is needed for APN.

@jcbrand @strypey I know exactly how it works, because we're doing that in production. It doesn't work, and there's no client that does it propelry.

@raucao @strypey

Why does it not work? What's the problem with the app server that you have?

@jcbrand We don't run an app server. We send notifications to ChatSecure's API/server. It doesn't work, because ChatSecure only lets you receive notifications for *all* messages, not for mentions or whatever else you might want to configure as a user.That's completely useless.

@jcbrand But also, there are plenty of bugs that make it fail entirely.

@jcbrand If you want to experience all of the issues with XMPP notifications on iOS, then please try it out. Have fun!


Have you considered writing your own app server? Might be better than trying to rely on a 3rd party.


Or paying someone to improve the ChatSecure one (assuming it's FOSS).

@jcbrand Paying someone to make something work on iOS, wihch I don't even use? Where do you get this Apple entitlement from?

@jcbrand Also, if you don't want to look into the various issues (and e.g. the state of that issue in the ChatSecure GitHub repo), then please just leave it be and either believe me that it's a nightmare, or stop responding either way.

@jcbrand Pretending we're not trying hard enough is missing the entire point. These questions are all very passive aggressive.

@jcbrand There's the issue. Why would I ever consider that? I'm not on iOS and this issue is not an XMPP issue. It's an Apple issue.

@jcbrand Nobody should even have to deal with it. And if they do, and people do try, and ChatSecure is ceetainly no shitty app in general, then if they can fail that hard, what does that say about your great solution?


I don't know enough about your or what you're doing with XMPP to know what your motivations and incentives are.

But I can easily imagine usecases where there is incentive to fix this problem, even if Apple caused it.

If I was an iOS XMPP developer asking money for my app, then I would have an incentive to get push notifications to work, which would mean fixing the app server.

So it's not crazy of my to suggest going that route to someone complaining about the problem.

@jcbrand Apparently you have forgotten the beginning of this conversation. It was me complaining that it's currently not working on iOS and that that's a huge adoption blocker for the protocol.

Personally, I'm working on kosmos.org on the side, and our Web app alpha already has Web Push notifications, completely forgoing the native route and also ignoring Apple users until they get Web Push.

@jcbrand Unfortunately, there's the next pet peeve of mine: Web Push servers and GCM. But I'm sure you know about all that jazz.

@jcbrand @strypey Even if it could work in theory, and it's just a matter of improving clients and literally every XMPP server implements it, the problem is still only there because of Apple's restrictive rules.

@raucao @jcbrand the problem there appears to be people buying #iThings. The solutions would appear to be a) stop buying iThings, and b) come up with ways to jailbreak all existing iThings and replace iOS with a fully free code OS, along the lines of what #PostMarketOS is doing for #Android.

@raucao @strypey @jcbrand So everyone who runs an xmpp server needs to get their own apns certificate which is contingent on apple's goodwill? could say cock.li get a cert?
@ayy @raucao @strypey @jcbrand cock.li is down at the moment so like VC has bigger things to deal with
@louisoft01 @raucao @strypey @jcbrand It was just as an example anyway. Sad that it's down though.
@jcbrand @strypey

This is only partially true; XMPP's issues stem from technical problems more than they do from economic ones. It's a mistake to presume that there are only economic problems with the protocol.

1. XMPP itself does not define basic functionality that users expect from IM protocols, instead choosing to defer such functionality to XEPs.

2. Consequently, the 'minimum viable product' for XMPP *requires* implementing protocol extensions.

3. What extensions should a client or server implement, anyway? Anyone wishing to write new software for XMPP would have to figure out what XEPs they need to implement by looking at existing implementations and figuring out what *they* implement.

Contrast this with the Fediverse, where the backend servers all support multiple competing implementations, so developers can just pick one and they have a minimum viable product rather quickly, just by reading the spec for the protocol they chose, without needing to research all backends and frontends to figure out what needs to be supported.
@jcbrand @strypey

In addition, Facebook and Google chose to abandon XMPP for sound technical reasons, like XMPP not supporting infinite history or cross-client history. Economics has very little to do with it.

@jcbrand @strypey @Aerdan it does support cross client history via message carbons xep now iirc

@a_breakin_glass @jcbrand @strypey @Aerdan right but like mentioned you had to extend it to get a feature that's deemed as canonical

@Aerdan @strypey

Economics has almost everything to do with it.

There's no money to be made by working with the relevant standards body in advancing the protocol to meet the developing needs of users and providers.

No-one knew 20 years ago what people will be doing with IM in 2018, which is why they rightfully made the protocol extensible.

Google could have worked with the XSF to extend the standard in whichever way they wanted to evolve it, that's what they do with web standards.

@Aerdan @strypey

They killed GTalk because they wanted to push Google+ and create more user lock-in.

Again, where's the money in federating with Facebook and Microsoft (who also didn't want to federate) or with smaller players?

If XMPP federation was as big as email federation then they wouldn't have been able to kill it in such a way, but XMPP never reached the critical mass of email.

Many companies are actively trying to kill email in a similar way, but it's too entrenched by now.

@Aerdan @strypey

If you're Google and you're using XMPP for GTalk, there's really nothing stopping you from creating a protocol extension to implement the features that are lacking.

That's the whole point of making the protocol extensible.

They already did that with Jingle and video calls.

Same deal with Slack. They complained that XMPP doesn't support emoji reactions. Well, they could have extended the protocol to support them. Problem solved.

Why didn't they? No money to be made that way

@Aerdan @strypey

> XMPP itself does not define basic functionality that users expect from IM protocols, instead choosing to defer such functionality to XEPs.

What people consider basic functionality in 2019 is not what people considered basic functionality in 2000 and is not what people will consider to be basic functionality in 2040.

Which is why they rightfully made the spec extensible.

Where the XSF can improve, is to explain to developers what suite of XEPs they should implement in 2019

@jcbrand @strypey

I'm sorry, but "can send messages to people" should not be *an extension to the basic protocol* for a specification which asserts that it is a *messaging* protocol.

@Aerdan @strypey

Now you're just trolling.

If you implement RFC 6120 and RFC 6121, which is the "basic" protocol and which all XMPP clients and servers implement, then you can send messages to people.

@jcbrand @strypey @Aerdan

To understand why companies do what they do you really need to look at it from the perspective of the business model.

Google's business model is targeted advertising. To target ads you have to control the platform, otherwise people will just choose a less spammy platform without ads. With XMPP/GTalk, Google couldn't really control or read everything which went on there. There could be other independent xmpp servers which they couldn't so easily datamine or push ads to.

Not having control of the platform was why Google abandoned various open standards. I think they will also eventually abandon the Linux kernel for the same reason, at least on mobile. Linux isn't ever likely to agree to having display rendering dumping ads to the screen in a manner that the user can't block, or the kernel level telemetry they're planning.

@bob @strypey @jcbrand @Aerdan

You could also blame the overwhelming percentage of users who didn't choose to keep XMPP in their lives. They could've created a new account elsewhere, but didn't do anything about it. Just let's go with anything Google picks for us.

@aemon @Aerdan @jcbrand @strypey

Even among technical people, in the past the assumption was that "Google knows best". Many times I encountered arguments like:

"Why would you want to run a web server? Google employs people who are much more expert to do that."

"Why run an email server? Gmail is far more secure than anything you could make."

There was the myth of the Google engineer being a god-like ubergeek with supercow powers. Similar to the myth of the 10X developer.

@bob @strypey @jcbrand @Aerdan @aemon I see this sentiment on HN a lot: "<proprietary service> is cheaper time-wise than rolling your own so it's /irrational/ to roll your own". But.... What if cost or time are not the only considerations? What if privacy and decentralization matter as well?

@waterbear @aemon @jcbrand @strypey @bob

Didn't say it'd be cheaper. Did say XMPP is a pile of shit which only makes sense to implement from the viewpoint of being literally the only FOSS IM protocol. (And, again, my theory is that it was originally someone's personal project; someone with no background in realtime comms could readily believe XMPP is a good choice )

Besides, Google has been known to write their own thing from time to time; see Chromium.

@waterbear I get frustrated with this as well, but I also see how it makes sense from their POV. My fanatical devotion to #SoftwareFreedom results in huge amounts of time spent a) researching new tools, and b) constantly repairing my tools. Even though my main product is a blog about ethical design and the commons, so these experiences can be mined for raw materials, I find this frustrating. If I was designing a more generic product, and had deadlines to meet ...
@bob @jcbrand @Aerdan @aemon

@bob @gaditb this isn't a myth of god-like competence, it's just a simple consequence of economies of scale/centralization of capital

It's a bit more complicated than that @aemon . People can't just pick another XMPP server, login with their Google account, and have it smoothly integrated with GMail. So from that POV, they are stuck with whatever Google picks. If even a single #FreeCode email client integrated XMPP chat, folks could have switched to that (even while keeping their GMail address), but there wasn't one, and there still isn't. #Thunderbird is trying but the #UX of the integration needs work
@bob @jcbrand @Aerdan

@strypey @bob @jcbrand @Aerdan

I tend to think it's more about unawareness, indifference, not lack of integration. Non-tech (99%) folks couldn't care less about the technology. Also, I think desktop IM had started to loose its massive momentum after MSN Messenger and was starting to head for mobile IM (i.e. Blackberry Messenger). So having that vision was fundamental. Google missed the oportunity and in fact they have never regained its momentary strength in that field...

@aemon I didn't specify a *desktop* client. If there was even a single #FreeCode *webmail* client that integrated XMPP chat as smoothly as GMail did, people could have replaced GMail by just registering for a new email account as a hosting using it. Instead, they had to sign up for new email account, find a host for an XMPP account, choose an XMPP client for their OS, figure out how to install and configure it, and try to get all their email contacts to do the same etc.
@bob @jcbrand @Aerdan

@aemon This is appalling #UX. The #SoftwareFreedom movement can and must do better. Victim-blaming people for staying with Google and the rest of the datafarms is a cop-out.
@bob @jcbrand @Aerdan

@strypey @bob @jcbrand @Aerdan

Well, you did mention a desktop client (Thunderbird), and in fact Gtalk only had some power in the desktop world, not mobile (still marginal in those days).

I'd say 80% of the people who used MSN Messenger had to create a @hotmail account and install the MSN client in order to work with it.

Now there's a big bunch of people spending $1000 to buy iThings disregarding any other option.

To me is a clear case of PR power + net effect. You can't UX-fix that.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!