Notices by JC Brand (jcbrand@mastodon.xyz), page 10

@z428 @strypey

You definitely have a point, but for me what you say still comes down to economics (at least in large part).

An older entrenched protocol with old clients (like email or XMPP) does have inertia.

If you want to implement new features, then older clients won't support them, creating a worse experience over all.

However, this is also true for the web, and yet we get new features on the web all the time and people have evergreen browsers.

So it can be done with open standards.

@z428 @strypey

There's a kind of "tragedy of the commons" here, whereby a commons (in this case an open, federated protocol) doesn't get implemented, due to the rational self-interest of the players in the game.

If the protocol was already widespread and used when the players arrive on the scene (like email or the web was), then they could federate, and interoperate.

But that critical mass and threshold wasn't reached with XMPP, because the web giants already existed when it took off.

@z428 @strypey

> left open that market for services

Coming back to my argument that it has more to do with economics than technical reasons.

How are you going to make money by federating with your competitors and by working with standards bodies to extend an open protocol that your competitors can then also implement?

The same question applies to all players, which is why every for-profit IM company tries to build a silo (aka closed garden).

@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.

@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

@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

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

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.

@raucao

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.

@raucao

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

@raucao

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

@raucao @strypey

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

@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.

@raucao @strypey

BTW, I'm referring to this XEP:

https://xmpp.org/extensions/xep-0357.html

@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.

https://monal.im/