From the editor

I said last week that there wouldn't be an update this week because I'm on vacation, but as it turns out a bit of progress was made before I left and I have a few minutes to make the update while my partner writes postcards to send back home.

Notable changes to ruma

• Add initial stub implementation of user-interactive authentication.

  Matrix's interactive auth system is in a bit of a transition, so there has been lots of investigation and discussion with the core team to learn how it works. I was able to make some good progress on how it will be represented as Rust code, but there are many more changes to come. I hope to have "dummy" authentication working soon.

Matrix at large

Many of my questions about the specification have been answered, thanks to Richard van der Hoff of the Matrix core team. A few issues are ongoing, but all of this discussion will be very helpful in improving the specification and clarifying some flows so that Ruma can implement them.

Specifically:

• SPEC-385: PUT requests should use the JSON body for all request parameters

  Came to agreement that, at least for the /register API endpoint, request parameters related to the registration should not be split arbitrarily across the query string and the body of the request.

• SPEC-343: Explain the purpose of refresh tokens

  Clarified why Matrix authentication involves both "access tokens" and "refresh tokens," where implementations are free to make their own choices, and the trade offs involved.

• SPEC-313: Provide a high level overview of the different event syncing API endpoints

  Ongoing discussion of which APIs are used by the client to get events, and how best to update the spec to make recent API deprecations more clear.

• SPEC-310: Consider renaming "state key" to "subtype" and making it optional

  Ongoing discussion of the semantics of Matrix's "state events," as well as discussion about how to balance the quality of the spec with the need to make progress on implementations.

• SPEC-308: Authentication API is unclear/misleading

  Ongoing discussion about how the user-interactive authentication system relates to specific API endpoints that use it, like /register and /login.

From the editor

Greetings! My name is Jimmy Cuadra and I am the developer of Ruma. This is the first post in a new series of updates about the ongoing progress of Ruma. It roughly follows the pattern of weekly newsletters for other projects in the Rust ecosystem, such as This Week in Rust, This Week in Servo, and This Week in Redox. I am doing this for a few reasons:

• To keep myself motivated to make progress on Ruma every week.
• To promote interest in Ruma, Matrix, and Rust.
• To provide interested parties in a way to keep track of the project's development.
• To provide interested parties opportunities to provide feedback and contribute.

Feedback is appreciated via GitHub issues, tweets, and comments on social media websites.

For the time being, I am not promising a post every single Sunday, since I am the project's sole contributor at this point, and I may not be available to work on it every single week. That said, Ruma is a big priority for me and I expect missed posts to be the exception rather than the rule. Notably, there will not be an update next week, as I will be on vacation in Montreal!

Notable changes to ruma

• Add support for full stack integration tests.
• Implement access tokens using macaroons.
• Respond with appropriate errors when a guest operation is attempted. For now, Ruma does not support Matrix guest users.

Matrix at large

This week I had a good discussion with some of the Matrix core team members about the status of the Matrix specification and the role it plays in relation to Synapse, the homeserver developed by the Matrix team. Synapse is described as a reference implementation of the Matrix spec, but after several months working on developing Ruma against the spec, I think it is more appropriate to say that Synapse is an experimental project that serves as a proving ground for what will eventually end up in the Matrix spec. In other words, Synapse could not currently be recreated from only the information contained in the spec, as it contains a great deal of behavior that is not represented accurately or at all in the spec itself. This is not a bad thing, but having some clarity on the exact purpose Synapse fulfills will be important in thinking about how best to develop and maintain the spec.

Obviously, my perspective on Matrix is that of an implementor, and so the spec is my concern over any details of Synapse. The fact that Matrix has an open specification is one of the most important things that sets it apart from other attempts at a next-generation chat platform—especially the various "open source Slack clones" that have sprung up in the last year or so. As a result of our discussion on the topic, I've decided to put more work into helping the Matrix team improve the spec, even if it means going slower on the development of Ruma. I think my perspective as a developer attempting to implement an interoperable homeserver from the spec alone will be very valuable in filling out the gaps in the spec. I am exactly its target audience!