Hacker News new | past | comments | ask | show | jobs | submit login

Matrix has always deliberately put implementation before formalising the spec, because there's no point in speccing things which haven't first been tested in the wild. This is also partially influenced by observing that many XMPP XEPs seem to have lacked a proven implementation at the point of being specced, contributing to the fragmentation of the standard.

Now, the reason that we didn't formalise the federation spec until very recently (Jan 2019 - https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/) is because the implementation in the wild was showing problems which we wanted to resolve first. Now, this took ages to do, mainly because the team got mired in technical debt in Synapse and keeping the matrix.org server running, whilst trying to support the overall featureset (E2E etc) needed for Matrix to be successful. But we made it in the end. Meanwhile, it's true that server implementors got bitten by the lack of formal spec. The Ruma project for instance went on hiatus until a stable spec was released. Meanwhile unfortunately the mxhsd project lost patience and forked.

In an ideal world we'd have been able to move faster on releasing the stable federation spec, but the reality is that Matrix is a lot more than the federation API (although server implementors obviously focus particularly on it): we've put a lot of work into the CS API, E2E encryption, AS API, bridges, bots, reference clients etc too. History will tell if in the long term we got the prioritisation right.

Meanwhile, the federation API should now be sufficiently specced for server implementors to be able to successfully implement it - see https://matrix.org/docs/spec/server_server/r0.1.1.html if you're interested.




Still can't implement to this day.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: