News News feed (Atom)

This Week in Ruma

› published on by

From the editor

Another big milestone was reached this week: ruma-signatures became the second Ruma crate to be published to crates.io. ruma-signatures is a stand-alone library for working with digital signatures used by the Matrix system. It can be used by either client or server code, and is not specific to the Ruma homeserver, so anyone writing clients, servers, bots, or integrations for Matrix can use it. One feature, the ability to sign Matrix events, is notably absent from this first release, mostly because Matrix's federation specification is still unstable. However, the library should still be useful as is. Check out the documentation to learn how to use it.

The release of ruma-signatures also makes it possible to finish the last remaining task in ruma-events, which was to update a struct field to use one of the types from ruma-signatures. ruma-events should see its first release to crates.io next week, further expanding Ruma's contribution of independent Matrix libraries for the Rust ecosystem. In turn, ruma-events's release will unblock ruma-client-api, which in turn will make it possible to begin implementing ruma-client, which will be great for anyone looking to write a Matrix program in Rust.

Back in the Ruma homeserver, there are several pull requests waiting for review, so more API endpoints will be implemented soon!

Notable changes to ruma

  • Ruma's internal error type's API was improved using the Into<Option> trick by a new contributor.
  • Another new contributor fixed a bug in the GET /_matrix/client/versions endpoint, and made the crate's manifest consistent with the program's CLI.

Notable changes to ruma-events

  • New types were added to support heterogeneous collections of events.
  • The types for the m.room.member event now use the Signatures type from ruma-signatures.

Notable changes to ruma-identifiers

  • Released crate version 0.5.0, with supports the new 0.9 release of Diesel.

New contributors

And a belated contribution attribution to my coworker and friend, Ramiro Jr. Franco, who did a bunch of work to get Ruma's website started a while back.

Call for participation

Last week I included this new section, and intend to include it every week from now on, to highlight ways people interested in the project can contribute. Writing code is not the only way to contribute. Adding or improving documentation, doing code review, and participating in discussions are helpful too!

There are also plenty of API endpoints that still need to be implemented. Check the status document for a list.

This Week in Ruma

› published on by

From the editor

We had a very productive week, landing several pull requests, including a major revamp of ruma-events and new APIs.

A very important milestone was reached: The number of unstable Rust features Ruma uses was reduced from six to two! Ruma was migrated to the new Macros 1.1 approach for custom derive, which meant we were able to drop the custom_attribute, custom_derive, and plugin features. As part of the integration of the ruma-events revamp, specialization was also removed. With question_mark now stable, Ruma uses only proc_macro (Macros 1.1, which will be stable in a few more releases) and try_from, which I hope to see movement on soon. The day that Ruma can target stable Rust is approaching!

The revamp of ruma-events changed the design of the library, so each of the kinds of event in Matrix (events, room events, and state events) are now traits rather than structs with two generic parameters. This change took quite a while, so I'm happy to have it finally integrated into Ruma.

Notable changes to ruma

  • Added support for local room invitations.
  • Removed unstable features: custom_attribute, custom_derive, plugin, and specialization.
  • Updated to Macros 1.1 versions of Serde and Diesel.

Notable changes to ruma-events

  • Event, RoomEvent, and StateEvent are now traits.

Notable changes to ruma-identifiers

  • Released crate version 0.4.3, a small bump to update dependencies.

Call for participation

Here are a couple of items to check out if you're interested in contributing to the project:

This Week in Ruma

› published on by

From the editor

It's been several weeks since I published an update to This Week in Ruma. I've been out of town for a lot of that time and too busy to give Ruma the time it deserves. This hasn't stopped Ruma's contributors from moving forward, however! There are several pull requests in various stages of completion and review. It will likely to continue to be on the quiet side for Ruma through the remainder of the year, but don't worry. The project is not going away.

Notable changes to ruma

  • Added support for user profiles.
  • New room aliases now properly generate an m.room.aliases event.
  • The construction of API endpoints and the various middleware they use has been refactored to use a trait and a macro.

This Week in Ruma

› published on by

Many thanks to Ruma's contributors this week. The status document is quickly going from red to green!

Notable changes to ruma

  • Added support for listing the members of a room.
  • Added support for room-specific client configuration data.
  • Added a new custom error code for cases where the client submits an invalid parameter.
  • The creator of a room now automatically joins is.

Notable changes to ruma-signatures

  • Added a Signature type that is produced from a SigningKey.
  • Added a SignatureSet type that works like a set but serializes to a map, which is how a homeserver's signatures are represented in Matrix events.

This Week in Ruma

› published on by

Ruma had some major progress this week. We're getting ever closer to the first alpha release. Ruma's fantastic community contributed implementations for several new API endpoints, with more on the way.

On Friday I did my second live stream of Ruma development. If you missed it, you can watch the recording. In it, I work on a new crate, ruma-client-api, the purpose of which is to separate the request and response data types for each API endpoint from the homeserver so that the same types can be used by client code. The general structure of the API has changed since the Friday screencast, and is coming together very nicely now.

And finally, a milestone was reached with ruma-events by converting the Event, RoomEvent, and StateEvent types from structs to traits, greatly simplifying the overall API, and paving the way for better generic treatment of the different event kinds in the Ruma homeserver. Initially I thought it would require language support for fields in traits, but I managed to get almost the same effect with macros. At least ergonomic enough that I'm comfortable stabilizing the current API without fields in traits, at least once I verify that it works well in the homeserver code.

Notable changes to ruma

  • Added support for deactivating an account.
  • Added support for joining a room.
  • Added support for listing the members of a room.
  • Cleaned up the way variable URL path parameters are handled, moving all the logic in to Iron middleware, and reducing the volume of code in each API's handler function.
  • Squashed all database migrations into a single "prerelease" migration to make it easier for contributors to work on features requiring new tables concurrently, and because there is no need to have more than one migration per released version of Ruma.

Notable changes to ruma-client-api

  • Added this new crate to share the request and response types between client and server.
  • Overall API designed and types added for about a third of the Matrix client API functionality so far.

Notable changes to ruma-events

  • Event, RoomEvent, and StateEvent are now traits, which unifies and simplifies the crate's overall API.
  • Enums now implement Display and FromStr.