*libQMatrixClient was renamed to libQuotient

The project aimed at adding end-to-end encryption to libQuotient for future support in Qt/libQuotient-based clients like Quaternion and Spectal, or even Telepathy IM.

The work done

Regarding my initial proposal, I’ve completed tasks enough for message receiving, and not finished tasks related to message sending.

Focused on libQuotient, I've also added changes to Quaternion client to support the proposed API and test the results. I've reused libQtOlm, which is a Qt wrapper to the matrix olm library and contributed to provide better compatibility during its building and deployment. This also required to dive into the olm library itself and provide minor patch for the olm CMake files too.

So, the basic structure of the project changed a bit, libQtOlm was added as a dependency to support libolm:

                              |   Quaternion/Spectral/Telepathy|Tank/etc   |
+------------------+          +--------------------------------------------+
|      CS API      |  <---->  |                  libQuotient               |
+------------------+          +-------------------------------+------------+
|Synapse homeserver|          |               Qt              |  libQtOlm  |
+------------------+          +--------------------------------------------+
                                                              |   libolm   |

During the coding period, I've resorted to the specification, the guide and the last year GSoC python implementation actively. And added minor fix for the documentation about names constants at the documentation examples.



Future work

Talking about future work, the status is going to be captured at libQuotient project board. Next steps are:

  • Managing devices list for users in the room
  • Sending encrypted messages

While olm account management architecture and device_one_time_keys_count sync data handling is here, such tasks as session management after a restart and device verification still requires additional efforts. After that encrypted attachments support and key backups could also be added.

I'm going to take care about that, but it definitely will be harder as just a side project. I still have enthusiasm though :)


To take part in the Google Summer of Code project was my dream. I'm very happy I've managed to took part this year, since it was the last year of my study, while I had doubts about my personal results until I've received final confirmation and the review.

From the beginning of the project, I've realized I'm very lucky since I've got all the chances to provide perfect results. @Kaffeine helped me a lot with my TelepathyIM contribution. He helped me to evolve my CMake, git and Qt/C++ skills and that's how I've started contributing to the libQuotient before GSoC. After that, it turns out that I've accepted and received even two mentors. @uhoreg from the Matrix team, who helped me with End-to-End Encryption logic and olm/megolm understanding. And @kitsune from the Quotient project, who helped me a lot with the code review, with the architecture decisions and the library logic, and even with the time management (he was the one who watched carefully about my results). The last year GSoC python implementation and guide from @Zil0 were also here, and it turns out that Spectral developer @BHat provided QtOlm wrapper right before GSoC stated.

However, planning and updating the plan were my weak points, where I've made key mistakes, such as poor combination with my regular part-time job. And I definitely should have reserved a small vacation at least for the final period of the project to handle tasks better.

In the end, I've managed to debug the mistakes and provided encrypted messages receiving that could already be used at the clients. Also, I evolved my skills and dived into the megolm E2EE subject. I'm willing to continue my contribution to develop libQuotient as full-featured Qt-based Matrix library.

In general, I am not disappointed. I'm wishing luck to all the future students who are reading this. I'm happy to receive support and contribute to an international open project not only for myself, but also for the other developers and users.

GSoC project page: link

Mentors: Alexey Rusakov, Hubert Chathi

GSoC Matrix room: link

Contribution: libQuotient GSoC E2EE PRs list, full final report at the project wiki

The Foundation needs you

The Matrix.org Foundation is a non-profit and only relies on donations to operate. Its core mission is to maintain the Matrix Specification, but it does much more than that.

It maintains the matrix.org homeserver and hosts several bridges for free. It fights for our collective rights to digital privacy and dignity.

Support us