[MattJ100]

This is not a problem with XMPP, but any open ecosystem. There's no way to force third-party developers to implement stuff, especially when they are open-source volunteers working in their free time.

XMPP does have this feature parity issue, though there is a good selection of modern active XMPP clients across platforms with important features like end-to-end encryption and calls. But you're right - there's no way to stop people trying to use clients like Pidgin, which have been essentially frozen in time for a decade.

Matrix is newer, so has less diversity, and lots of resources to put into the Element clients. However there certainly is exactly the same problem growing in the Matrix ecosystem too - there are many features supported by Element that are not (yet?) implemented in popular alternative clients such as FluffyChat.

The best you can do is ensure that when two clients communicate without the same set of features, that you degrade gracefully and securely (e.g. the worst case I can imagine would be E2EE that silently becomes unencrypted if not supported by your contact - thankfully that's not how it's done) to the best common feature set between the two.

[gefhfff]

In Matrix you "can't" select between multiple extensions. The protocol defines one way of doing things, so either you have that feature or you don't have it. There is no choice between two ways of doing things.

Yes I know, since Matrix there is now an extension that defines a selection of extensions to try to overcome this

[jayd16]

I think a major problem is there isn't (last I looked) a clear set of feature tiers or a collection of XEPs that are given names and tests.

Instead of "oh MS teams supports up to xmpp2017" it's just a crapshoot.

[MattJ100]

Here's what you're looking for: https://xmpp.org/about/compliance-suites/

Compliance suites are reviewed, updated and published annually with the recommended set of features across a range of different categories.

[rapnie]

See also "Modern XMPP".

https://news.ycombinator.com/item?id=28276266

[jayd16]

Well there go. I guess now that I think of it, last I looked was MUC support in 2012 or so.

Looks like it's on the list but as "* Support can be enabled via an external component or an internal server module/plugin."

So...a crap shoot, haha.

[SamWhited]

That just means that some servers may have it built in (all of the maintained ones that I'm aware of do), but that you can still claim compliance if you support a general plugin system and delegate your multi-user chat implementation to an external plugin (because of the way it's designed it doesn't necessarily have to live on the same server or in process with the XMPP server). That seems like a fine implementation detail to mention and not a problem…

[jayd16]

You can say that..but it was a problem. It was not trivial, despite what the spec says or what is claimed now. If it was, more people would have used it.

[SamWhited]

I don't know what you mean "is a problem"; what's a problem, setting up groupchat? Everything uses multi-user chat and it's built in to all the servers I know of (but can generally be run as a standalone server if you prefer, which is what this means)? You can just enable it in your config and it just works on at least Ejabberd and Prosody, probably others.

[LaGrange]

> There's no way to force third-party developers to implement stuff,

...ever heard about "the state"?