Fractal Hackfest

This week, I was able to attend to the Fractal Hackfest. My train from Paris arrived at Strasbourg at 12:45, so I missed the beginning of the Hackfest in the morning but I could be there for the afternoon. I stayed until the middle of Saturday’s afternoon.

On Thursday, I wasn’t there on the morning but there was a sum up of the important part of the morning’s discussions.

There can be two main use cases for Matrix: one for friends, family and other small group discussions, where there are a low volume of messages and you care about all of them; and another for huge and noisy rooms in which there is a lot going on and you don’t necessarily care about most of it (for instance, you would want to be able to focus on the messages mentioning you). Both of these use cases could motivate to split Fractal in two apps: “Barbecue” (for the first use case) and “Banquet” (for the second one).

However, this leads to several open questions:

• How to decide where each room goes?
• Would there be one or two code bases for these apps?
• Would there be one or two Matrix daemon? The Matrix daemon would be a multiplexer for the two applications which would dispatch Matrix events to the appropriate application and send messages and media to Matrix homeservers (see the pictures above). But how would the IPC be implemented? With D-Bus, with COAPT or CBOR over a Unix socket? With JSON over HTTP?
• For Barbecue, what would be the possible fallback options and how would work the interactions with other protocols (e.g. SMS)?

On Friday morning, there was discussions about the support of E2EE (i.e. end to end encryption). Some questions need to be solved for that:

• How to implement it? There would either be a portage of the Matrix<->libolm interface code from matrix-js-sdk to fractal-api or a contribution to build a common matrix-olm-wrapper project which would provide Matrix<->libolm glue for all native clients.
• Investigations about how to share keys more securely between devices are going on.

There was also a discussion about VoIP support for Fractal. There are currently three implementation choices for it WebRTC.org (Google’s library), GStreamer or TNG (if/when Matrix.org opensources its own WebRTC library). WebRTC.org is the most mature and resourced implementation so it would be strongly recommended to use it even if it isn’t part of GNOME.

Different use cases for the multi-account has been listed: personal vs work, multi-project (i.e. an account for each project you would work on) or in order to be able to still use an old account (because it is not possible to migrate an account from a homeserver to another).

In the afternoon, there was a discussion about the possibility of dividing fractal-gtk in order to have three crates (the Matrix API, the backend and the UI). We have talked with Julian (the other GSoC student working on Fractal) and Daniel (our mentor) to know precisely the planning for GSoC. I will be investigating on the localization support during the next weeks and implement it, if it is possible (we are not sure about it for now because of the uncertain status of the Rust binding for gettext). Finally, we have established a list of tasks that should be done for Fractal during the upcoming time (see the picture below).

Saturday morning was about the room history:

• The width of the column in which the messages appear (how to deal with the resizing of the window and the different layouts)
• The support of inline media (like images, videos, audio, formatted text, document preview, link preview, emotes, notice (like GitLab notifications), location).
• Support the display of redacted messages, membership changes, replies and room events.
• The design of the interface to download files.
• Displaying read receipts: just indicate when a user have read a message in a one-to-one chat, also display the name/avatar of the people reading a message, maybe just display the read receipt when pinging someone.
• Messages actions: possible implementations are mouse hovering, secondary/long press or primary click on the messages.

About how I felt about this event, I was quite shy at first, especially because it was the very first event related to computer science I was attending to and I wasn’t participating very much. But the other people were very welcoming (some of them even told me that I was welcome in the GNOME family :)) so it helped me a lot! At least I could learn some things about UI/UX design and have an idea of how decisions are made. At the end, I was very happy about this experience and I will certainly come to GUADEC too!