News News feed (Atom)

This Week in Ruma

› published on by

From the editor

I'm back from my vacation to Montreal and Quebec City (which are lovely and you should visit) and working on Ruma again! Although development this past week was hindered a bit by another round of breaking changes to the Rust compiler's libsyntax crate, which affects Ruma's use of serde and diesel, there have been a few changes to Ruma and some movement on the Matrix specification.

For anyone interested in following This Week in Ruma regularly, it is now available via an Atom feed.

Notable changes to ruma

  • New CLI subcommand, ruma secret

    This new subcommand generates and prints a secure random value suitable as the macaroon_secret_key in the Ruma config file. This value is used as the secret key for creating user access tokens using Macaroons.

  • Interactive authentication removed from /register

    At least for now, user registration will not require any sort of external credential verification. This area of the spec is currently less stable, so implementing it will wait until it makes more sense.

  • Simplified structure for crates, modules, and tests

    The integration tests have been moved into the src directory so that it's not necessary to split ruma into a binary and a library just so the integration tests can link to the library. This makes Cargo.toml and various cargo commands simpler.

  • Swagger data source

    By default, ruma now serves a JSON structure at /ruma/swagger.json that can be loaded by Swagger UI to display the full Matrix client-server specification that will eventually be implemented by Ruma.

Matrix at large

There has been a bunch of activity on the spec recently. It appears that the Matrix team is preparing for a stable 1.0 release of the client-server API spec. A branch I worked on for the spec landing page of the specification was also merged. Those changes improve the organization of the information to make several things clearer to first-time readers.

This Week in Ruma

› published on by

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.

This Week in Ruma

› published on by

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!