From the editor
This week I want to take a moment to talk about something personal.
My best friend, Tamara Boyens, passed away last Friday, January 6, after more than a year of suffering from a spine injury and various related issues.
It's been incredibly heartbreaking for everyone who loved her.
She was a friendly, lively person, and was genuinely interested in any topic you would talk to her about.
She and I talked online a lot—many hours every day, year after year.
This was especially true after we both moved away from the city where we met.
Because chatting online was the way we talked the most, we were always looking for a better chat system than what was available to us, and this was a large part of my initial motivation to get involved with Matrix and build Ruma.
I have dedicated Ruma to her memory.
I hope, once it reaches production quality, that it will help many people to strengthen their relationships and get the use out of it that Tamara and I no longer can.
And now, on with the project updates.
Notable changes to ruma
- Added
POST /rooms/:room_id/leave endpoint.
- Fixed intermittent deadlocks in the test suite.
- All users in trusted private chats now have equal privileges.
- Improved some error handling and factored out some duplicated logic.
- Replaced some string fields with appropriate ruma-identifiers types.
- Published version 0.3.0 to crates.io.
- Added missing trait implementations for
PresenceState.
- Began spiking out the API for this high-level Matrix client library.
- The "supported versions" API endpoint has been moved into an
unversioned module.
- Converted path parameters in docs from colon-snake-case to brace-lower-camel-case
- Updated to ruma-api 0.3.0.
Notable changes to ruma-api
- Published versions 0.2.0 and 0.3.0 to crates.io.
- Added a
Deserialize + Serialize constraint to Endpoint::QueryParams, for use with the serde_urlencoded crate.
Endpoint::router_path's return type changed from String to &'static str.- Added new required methods to
Endpoint: name, description, requires_authentication, and rate_limited.
New contributors
Call for participation
Interested in getting involved with Ruma?
Here are some good places to start:
New:
Previously featured and still available:
There are also plenty of API endpoints that still need to be implemented.
Check the status document for a list.
From the editor
The last couple weeks have been very busy for Ruma, in spite of the holiday season!
We released another of the Ruma crates to crates.io, ruma-events, which contains Rust types for all the events in the Matrix specification.
Events are the primary data structures that are exchanged in Matrix.
ruma-events makes it easy for client and server code to share the same representations of these events, and to convert them to JSON and back.
ruma-events was the first component of Ruma that was developed, so I'm very happy to see it reach a stable enough point to be published.
The Ruma homeserver had been using it as a Git dependency for a while, but now it's at a good place to start using for client applications.
There's also been a lot of contributions to ruma-client-api.
This crate contains types for the requests and responses for each of the API endpoints in Matrix's client-server specification.
In the near future, it will replace the the request and response types currently used by the homeserver, and is already being used to spike out an implementation of ruma-client, a high-level client library.
These Matrix libraries are part of the broader ecosystem and vision of the Ruma project.
Our goal is not only to build a Matrix homeserver, but to build a collection of Matrix libraries that developers can use to build high quality, interoperable Matrix-enabled software in Rust.
We recently launched a new projects page on the website that explains each library and how it relates to the others in detail.
Notable changes to ruma
- Added support for the room creation API endpoint's
initial_state parameter.
- Implemented the API endpoints for filters.
- Implemented partial support for the event synchronization API endpoint.
- Implemented the API endpoint for joining a room with either its room ID or a room alias ID.
- Improved error handling to reduce the amount of cloning.
- Added missing Content-Type header for error responses.
- Fixed a bug that used the wrong value for a user's power levels in certain situations.
- Now published to crates.io.
- Added missing variants of the "stripped" versions of events.
- Released crate version 0.6.0, which includes a new
RoomIdOrAliasId enum type for APIs that accept either form of Matrix room identifier.
- All API endpoints except push notifications are now implemented.
- Added links to the relevant section of the Matrix specification for each API endpoint.
Notable changes to ruma-api
- Created and published this small crate which contains core types that will be used by all Ruma crates that implement request and response types for the various Matrix APIs.
Notable changes to ruma.dev
- Added a new projects page.
- Added a script to determine new contributors to the project across all repositories.
New contributors
Call for participation
Interested in getting involved with Ruma?
Here are some good places to start:
New:
Previously featured and still available:
There are also plenty of API endpoints that still need to be implemented.
Check the status document for a list.
2016 was a fantastic year for the Ruma project.
Although the project began in 2015, 2016 is the first full calendar year of development on the project and most of the major developments happened this year.
I wanted to take a few moments to review what we've achieved, and what's been going on in the Matrix and Rust communities as well.
As a developer with many previous open source projects, I've been amazed at the amount of interest in the project and the number of people who have contributed significant portions of the current code base.
I'm used to flying solo, but Ruma has very quickly grown into a group effort of which I am only one member.
As of the end of 2016, Ruma has 11 people who have contributed commits to one of our repositories.
This does not include people who have opened issues or the more than 250 members of #ruma:matrix.org who have participated in discussions, asked questions, and generally shown support of or interest in the project.
I particularly want to mention and thank mujx and farodin91, who have contributed substantial amounts of code and functionality, including some of the more difficult APIs.
A while back I invited both of them to join the Ruma organization's members to acknowledge their work and the importance of their involvement in the project.
Ruma would simply not be nearly as far along as it is without their help.
Thank you both!
While the 0.1.0 release of the Ruma homeserver did not quite make it in time for 2016, we got very close, and I expect to see it in the beginning of 2017.
It may seem that not much work was done if we were able to go the whole year without a release, but it's important to recognize that Ruma is more than just the homeserver.
We're developing several separate Rust crates covering various functionality of the Matrix system, all of which will be used in the homeserver itself.
Four of the Ruma crates were published to crates.io in 2016.
It's been a goal from the beginning to extract as much independently useful functionality as possible from the homeserver so that developers have a great collection of libraries for developing Matrix applications in Rust.
We want to see Matrix succeed, and I think supporting the wider Matrix community with good development tools will be just as important as the homeserver in that regard.
Along with supporting Matrix on the software development side, another of Ruma's goals is to help improve the Matrix specification.
Prior to Ruma, the reference implementation, Synapse, was the only real attempt to implement the entire spec.
Because much of the spec is derived from the behavior of Synapse, there are many places where the spec was unclear or even incorrect.
Having a new homeserver implementation driven by the spec helps the Matrix team clarify, correct, and improve many details all across the specification.
The team has mentioned that we will be seeing the r0.3.0 version of the spec sometime in the next few weeks, and we're excited to see the new improvements.
Matrix itself has been growing in usage and becoming a more serious contender among the choices for modern messaging in 2016.
The flagship web-based Matrix client Vector came out of beta and was rebranded as Riot, bringing with it clients for desktop computers, iOS, and Android, as well.
Riot has been very well received and although still under heavy development, shows that there is a bright future for messaging that gives power and control back to users.
At the end of the year, Riot's long-awaited end-to-end encryption feature went into beta.
Although there still some bugs and usability issues to work out, the beta is very usable.
I've been using it myself since the beta was announced with success.
The importance of an open end-to-end encrypted messaging system cannot be overstated.
The imminent r0.3.0 version of the spec will include all the new APIs for encryption key management that were added to Synapse to support end-to-end encryption.
Rust has seen an incredible amount of activity in 2016 as well.
Since there have already been many other articles on the topic, I will just mention that it's a goal of Ruma to help increase interest and adoption of Rust, just like Matrix.
We want to be another name on the growing list of examples of Rust being used for high quality, production-ready software.
We want more people to learn what a joy Rust is to write, how well the ecosystem of tools and libraries work, and how involved and helpful the community is.
For the language itself, we want to help push more of the useful unstable features into stable Rust.
Most significantly, we've seen that happen this year with the impending stabilzation of Macros 1.1.
Ruma currently builds only on nightly Rust, and the most significant reason for that was our need to use the "custom derive" feature for both Serde (serialization) and Diesel (database ORM).
I wrote a blog post on my personal blog about my experiences with Rust earlier this year, and that was part of a series of public commentary on the topic that helped the Rust team to prioritize a short-term solution to the problem of needing nightly Rust for the very common task of serialization.
Now, only a few months later, the new system is expected to be stable in the upcoming Rust 1.15 release.
With the stabilization of Macros 1.1, Ruma is getting very, very close to being able to build on stable Rust.
The last remaining unstable feature is try_from.
It's very likely that Ruma will be targeting stable Rust by the end of 2017.
I will close by saying thank you again to all Ruma's contributors, to the whole Ruma community, to the Matrix community, and to the Rust community.
It's very fun and rewarding to be working at the intersection of these two new and exciting technologies, building an application that is sorely needed for safe online communication in our modern age.
Thank you for all the achievements of 2016, and here's to another great year!
— Jimmy Cuadra, Ruma project leader
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.
- 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.
- 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.
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.
Event, RoomEvent, and StateEvent are now traits.
- 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: