If the former entails an adopted RFC, isn't it common practice to prove need via a product before proposing a standard?
Asking because I'm at work on a safer, decentralized protocol for email, TMTP.
Are you saying that the Matrix authors won't submit an RFC?
In terms of contributions to the Matrix spec; from a quick eyeball at https://spec.matrix.org/unstable/proposals/, there are 95 different authors, of which 31 work for Element (the company formed by the original team who created Matrix). Or to slice it another way, there are 498 spec change proposals there, of which 358 were written by folks at Element (so 70%). Meanwhile the protocol itself is defined by the independent and neutral Matrix.org Foundation non-profit (https://matrix.org/foundation).
In other words, accusations that Matrix is entirely defined or controlled by Element are untrue - by the time we created Element there was already significant contribution from the wider community, and these days there are loads of other individuals and companies like Beeper, Famedly and even Ericsson contributing to the spec.
Edit: oh, and Rocket.chat is adopting Matrix too, which refutes the GP comment even more...
You and your company has all the leverage and no sane independent developer will invest in your protocol because he'll always have to play the catch up game.
So, to resolve it, the spec core team (which is a mix of element employees and community members) went through the two proposals to compare them and concluded that joepie91's approach is better. So we're about to kill off MSC2962 and merge MSC3216 into the spec instead.
Please stop with all the disinformation - it'd be way more constructive to invest your energy into improving XMPP than trying to make Matrix out to be evil.
However, I already have the answer on how you plan to deal with such conflicts, you've said it yourself [1]. I'll quote:
> The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind
If we say it in a less courteous manner, "Once we introduce changes, your independent implementation will be cut off from our network, and if you'll need several more months to implement changes, well, tough luck".
You see, I'm not saying Matrix is evil. It's a rather developed product, just like Mattermost or Flock. But a federated protocol it is not. Please stop advertising as such, and I'll have nothing to say about it.
Because they seem to like it and, based on my experience with the military being able to run it independently is a major consideration for them even for smaller systems.
On-premise software is nothing new. But the fact that some software can run on-premise and can interoperate between instances does not mean that it is a protocol. Mattermost can do that, is it a federated protocol too?
Disclosure: I work with real open protocols.