It's ironic; that albeit they started with an open federation protocol they don't federate and are essentially a proprietary service.

XMPP isn't an "open federation protocol" it's just a protocol that includes a means to federate; doing so is a matter of server preference. It would be great if more large services federated, but I'd rather have them use XMPP and not federate than build more custom protocols and not use XMPP at all so that I can't write a third party client for them.

My point is that being based on XMPP is still a good thing, regardless of whether they federate or not.

The whole point of XMPP is interoperability, so saying some proprietary service uses it internally is useless for the rest of the world without interoperability.

Can you connect with third party clients? Can they federate? Are they contributing to the protocol? No.

So what's good about it?

Big proprietary users of protocols tend to discover bugs in them, that they feed upstream, even if they run otherwise closed networks.

E.g. it benefits you that Google uses TCP internally, even if you can't get on their network? Why? Because they've submitted patches to Linux to make it work better.

> E.g. it benefits you that Google uses TCP internally

But they didn't modify TCP to prevent interoperability did they?

So what if they did? How are we any worse off than if they'd written their own TCP replacement from scratch to begin with?

Maybe someone outside Google gains nothing, but presumably their engineers will spend less time reinvesting the wheel, which is a net gain for humanity in less time wasted.

> but I'd rather have them use XMPP and not federate than build more custom protocols

Well, bad news then: They never federated and they modified their implementation of XMPP to the point of third party clients not being able to connect.