|
|
|
|
|
|
by Arathorn
1682 days ago
|
|
|
An example of resolving conflicts is something like MSC2962 (https://github.com/matrix-org/matrix-doc/pull/2962) and MSC3216 (https://github.com/matrix-org/matrix-doc/pull/3216). Two proposals to solve the same problem, different ways. The first one was written by me; the second one was written by joepie91, who's a completely independent community member. Doesn't get much more of a direct conflict than this. 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.
[1]: https://news.ycombinator.com/item?id=19421978