This week in the ruma/matrix Google Summer of Code project, ruma-events was made ready for use! After adding stripped and sync event generation to the event_enum! macro there were only a few small tweaks needed to try it out in some dependent rust crates. I spent a few days converting matrix-rust-sdk to use the ruma-monorepo. Since ruma is used on both client and server-side, I also opened a PR to update Conduit, a homeserver implementation written in Rust. To test that everything worked together, I updated rumatui, my command-line client written in rust.

Then I could test that Conduit sent, and matrix-rust-sdk received the new ruma events successfully. While updating, I felt the pain of not having accessor methods for the Any*Event enums to get at the event fields held within. I have opened a pull request to add the generation of these methods to the event_enums! macro. Hopefully, the Conduit and matrix-sdk PR's will be merged and the ruma monorepo can be tested in the wild!

This week in ruma-events' Google Summer of Code project, after trying out the new Any*Event enums matrix-rust-sdk, we found a few big flaws. There was no easy way to go from StateEvent<AnyStateEventContent> to StateEvent<SpecificEventContent>, the other issue was one could create a StateEvent with differing content and prev_content fields using the AnyStateEventContent enum. The 0.22 ruma-events will be similar to the existing API; each event type has a corresponding event enum variant.

pub enum AnyStateEvent {
    RoomMember(StateEvent<MemberEventContent>),
    RoomAliases(StateEvent<AliasesEventContent>),
    // ...
}

There were a few minor fixes during the week also. Unknown field deserialization is fixed, allowing deserialization of a JSON blob that has extra fields which are ignored. Custom events are now present in the Any*EventContent enums, although now they have to be moved up to be included in Any*Event enums. Benchmarks for deserialization have been added and used to increase performance.

This week in ruma-events' Google Summer of Code project, I was able to finish the macros needed to generate the event content enums and trait implementations required for events. I started by defining the generic event structs (state, message, etc.) and manually writing the Serialize and Deserialize implementations. Over the next few days, this was moved into a custom derive macro called Event. The derive now implements all necessary traits with appropriate bounds, so a StateEvent<C> can not contain any ephemeral event content and so forth. I have removed the raw mod and related FromRaw and TryFromRaw traits, moving the validation into the deserialization and constructor for the few types that needed it. On the event content side of things, a function like procedural macro was used to allow declaring the enum using Matrix event type identifiers.

event_content_enum! {
    /// Any message event.
    name: AnyMessageEventContent,
    events: [
        "m.call.answer",
        "m.room.message",
        // ...
    ]
}
// Produces
pub enum AnyMessageEventContent {
    CallAnswer(CallAnswerEventContent),
    RoomMessage(MessageEventContent),
}

Thanks to GSoC and the continued help of Jonas Platte, Ruma's GSoC mentor, there is a new contributor... me! My name is Devin Ragotzy, a University student from Michigan. I was chosen to help contribute to the macro code of ruma-events and ruma-api.

Ruma Community Bonding

Before the official coding period began on June 1st, a large breaking change started taking shape for the upcoming release of ruma-events 0.22.0. Jonas, I, and others have been hard at work, replacing the previous event declaration macro with a set of derive macros and generic event types, as well as getting rid of the boilerplate required for event enums (the types currently found under ruma_events::collections). The new types will be able to express JSON events from a Matrix server with more accuracy.

Planned work for ruma-api

Once the macros in ruma-events are implemented, I will switch gears to work on ruma-api.

• First, add a few tests to ensure the changes I make do not break important functionality
  • Test macro code using macrotest and/or trybuild which test errors or expansions respectively
• Allow more code sharing between Request and Response processing inside the macro
• Refactor ruma_api!, breaking up the large block of code in Api::to_tokens
• Document any refactored or new code as I work

Today, I have a bit of a sad announcement to make:

Ruma, the homeserver, won't be developed anymore

To those who have actively been following the project, this probably won't be a big surprise, given the homeserver's readme file was already update do note the missing maintenance and people interested in contributing to the homeserver have now gathered around a new homeserver project by the name of Conduit.

The main reason for ending homeserver development is that nobody who has previously worked on its codebase is currently able to guide and review work on it. The codebase has also bit-rotted a lot, with the web framework it uses being almost un-maintained and a number of its other dependencies having seen major new releases since the most recent commit; it also doesn't build on ruma-client-api, for the simple reason that ruma-client-api simply didn't exist yet when most of the homeserver work happened.

However, the end of the homeserver does not at all mean the end of Ruma, the overall project.

The future of Ruma, the project

We will be continuing work on our library crates, making sure they are usable for all kinds of applications, including homeservers. The new homeserver project mentioned at the beginning is based on them and some other folks are currently working on a highlevel client library, also using many of Ruma's library crates.

I am planning to replace the current website with a new one, mostly for technical reasons, but the new one will also reflect our changed focus. This work hasn't started yet, but in the interim I will likely update parts of the current site. Other than that, nothing will really be different compared to last year.

If you are still interested in a Rust homeserver

… then check out Conduit. It is a Matrix homeserver, written in Rust using Ruma's library crates. It is focused on experimenting with new ideas to achieve better performance, for example by using sled as its database. The goal is to make it as easy as possible to set up your own homeserver.