Google Summer of Code 2021 Intro
› published on byHello all! This year, Ruma has the pleasure of having two students for Google Summer of Code (GSoC) 2021: Devin (who worked on Ruma's proc-macro code during last year's GSoC) and Adam. We'll let them [re]introduce themselves.
Ruma API Coverage GSoC
by Adam Blanchet
This year for GSoC, Ruma has two students! I am the "newer" one of the two, and my name is Adam Blanchet. I've been at work adding support for more of the Matrix Spec in the past few weeks, and will be continuing on doing so for the remainder of GSoC.
Identity Service API
Although I had made progress before the official coding period for GSoC had started, I continued with finishing the remaining unimplemented Identity Service API endpoints:
- 3PID validity endpoint
- 3PID bind endpoint
- invitation signing endpoint
- store invitation endpoint
- 3PID unbind endpoint
Apart from the 3PID unbind endpoint which is currently blocked, this concludes the full coverage of the Identity Service API. This means that now projects built upon Ruma will be able to more easily integrate functionality with identity servers. This could also enable easier development of an identity server written in Rust!
Implementing MSCs and adding types
I then moved on to a few other miscellaneous issues, to get accustomed to working on the other parts of the Ruma project:
-
Add client secret and session identifier types: I found this PR to be more interesting than its title may indicate. Not only did I add two identifier types, but I added a new macro to create validated identifier types. The new macro was also used to greatly simplify the declaration of
ServerName
struct. I really enjoyed working on this PR. It was an occasion to create a new macro to simplify the creation of these and new types. I had never written macro code before, and it was a good occasion for me to learn something new! -
Add RoomName struct: This one did not involve macro code, though similar in principle to the previous PR. It adds a
RoomName
struct to be used in an event, which enforces a maximum length. -
Update endpoints for Blurhash implementation: MSC2488 adds the use of Blurhashes to the Matrix Spec. Although some Blurhash support had been previously added to Ruma, I extended this to all endpoints and events specified in the MSC.
-
Add "knock" feature from MSC2403: This adds support for knocking on rooms, a feature which I'm looking forward to see implemented in clients. It was introduced in MSC2403.
-
Implement reasons for leaving a room: Adding this feature, introduced in MSC1983, seemed rather straightforward. However, I bumped into an issue with a conditionally compiled field with a lifetime annotation. Thankfully, @DevinR528 helped diagnose the problem which was some macro code, for which they think they have found a solution along with @jplatte.
Once that fix is implemented, we will also be able to merge my PR.
What's next?
I'm looking forward to implementing the MSC for Secure Secret Storage and Sharing. This is the second large part of my project, it will involve adding a number of events to support storing and sharing both keys and secrets. To achieve full support, I would also need to implement crypto routines. I expect that adding these will require more effort than adding the events, though I look forward to the challenge.
I found my first half of GSoC to be very enriching. I really enjoyed working on this project: I got to learn how to read and apply a specification, and I learned the rigor required for a project such as Ruma. I have sometimes been caught off-guard: sometimes I miss extraneous newlines, sometimes (often) I forget to add a changelog entry, and other similar more stylistic rather than functional issues. Ruma is a big project with many crates, yet it maintains consistency throughout, a quality I greatly appreciate. I now know that this consistency comes from the thoroughness with which each change is checked, and I hope to improve my own rigor when it comes to each of my pull requests.
Ruma Tooling GSoC
by Devin Ragotzy
It's been a busy few weeks! I have started the process of checking four todo items off of Ruma's automated checks issue by contributing lints to the Clippy project.
I temporarily broke Clippy, Oh No! Luckily, the fix seems to have worked.
I've spent a lot of time familiarizing myself with the rustc usefulness checker. The is how the Rust compiler determines if you have a match for all possible patterns and checks if any of the patterns are useless.
let x = true;
match x { // `x` is matched exhaustively (all match patterns are useful)
true => {},
false => {},
// true => {}, would be un-useful
}
This is where I now plan to add a lint to check for missed patterns on structs
and enums that are marked non_exhaustive
(see issue).
This is helpful to Ruma because all of our public types are marked in this way,
allowing us to update our types in a non-breaking way while still informing
users of the change. Also, for anyone interested, I saw an interesting blog
post about usefulness checking.
For the last few days, I have been working with my mentor @jplatte to find and fix a very sneaky issue with conditionally compiled fields and lifetime annotations. This was found by my fellow GSoC participant in this PR. I think we have finally found a solution, fingers crossed.
I have thoroughly enjoyed the first half of this year's GSoC! I'm excited to
contribute to back the compiler for the language we all love so much ;). In the
second half of GSoC I hope to get ruma-check
to a
usable state adding the few checks left from Ruma's automated
checks.
Devin and Adam have already made it through the first half of GSoC and have made good progress. We're looking forward to the rest of the summer with these two!