danigm.net - fractal

Fractal: Refactoring and the review process

danigm — Tue, 30 Jun 2020 00:00:00 +0200

In this year GSoC, Alejandro is working on Fractal, moving code from the backend to the client, to try to simplify the code used to communicate with the matrix.org server and maybe in the future we can replace fractal-matrix-api with the matrix-rust-sdk. And then we'll have less code in our project to maintain.

This is a great work, something needed in a project with a technological debt of several years. I created this project to learn Rust, and also I was learning about the matrix protocol during the project build. And other contributors do the same. So we've been building one thing on top another for a lot of years.

In this kind of community driven projects it's the way to go. For some time we've people interested and developers think about the design and start change some parts or to write new functionality following a new design pattern. But voluntary developers motivation change in time and they left the project and the next one continues the work with a different vision.

It's not something bad, it's the greatness of the open source. Different people has different motivations to participate in a free software project, and every contribution is welcome. I'm the maintainer of the project and I've spent a lot of time building Fractal, but I don't have the same motivation now to work on the project, to it's good to have other people working on it so it can continue alive.

Alejandro is doing a great work and he's not a 4 months contributor. He's working on the backend refactoring for 2 years now, step by step and he has plans for the future.

Refactoring a big project is always hard, because there's a lot of code movement and always there's the fear to regressions.

Rust is a great language and it shines when big code refactoring comes to the scene. If it compiles, you know that there's no memory errors, dangling pointers and that kind of problems. If it builds it will work.

But maybe it will work different, so the review process is needed to ensure that the application continues working.

Automated tests are really useful for big code changes and project refactoring, because you have a quick picture and some certainty that the project is working. But we don't have tests in fractal :D, so someone should do that.

So here I am. Reviewing large MR, with a lot of lines. At least gitlab makes this process a bit easier.

What I'm trying to do in the review process is to just read the whole diff and check if there's some problem in the code. And after every change, I run the app and I do some tests, trying to use the functionality that could be broken by those new changes.

This takes a lot of time and it's not something fun to do... But someone has to do that. And during that process, sometimes I learn something new. Reading code is an interesting task and try to find bugs in code while reading it, is something useful. To think about that code, what it does and why.

Fractal: Google Summer of Code 2020

danigm — Fri, 08 May 2020 00:00:00 +0200

I'm glad to say that I'll participate again in the GSoC, as mentor. This summer we'll try to implement multi-account support in Fractal.

The selected student is Alejandro Dominguez (aledomu), that is collaborating with Fractal since the Seville Hackfest in December 2018, doing a great work in the backend. Alejandro is young developer with a lot of energy and ideas, so it's great to have this kind of people working on GNOME.

I've not spend much time lately developing Fractal, the time and energy is limited, but I'll try to use this GSoC mentorship to go back to the active Fractal development. My objective during this summer will be to stabilize, fix bugs and improve the performance and create a new release at the end of the GSoC, because we've a lot of new functionality in master, but I didn't spend the time to do the release.

The google summer of code is a great opportunity for free software, it give us a full time working student, during three months, working on free software, so it's really appreciated in a community where a lot of work is volunteer work.

There are a total of 14 projects selected for this GSoC round for gnome, you can take a look to the full list in the GSoC page.

GNOME Outreachy mentorship

danigm — Sun, 13 Jan 2019 00:00:00 +0100

The Outreachy program is a three month internship to work in FOSS. There are two periods for the outreachy, the first one from December to March and the other one from May to August. It's similar to the Google Summer Of Code, but in this case the interns doesn't need to be students.

I proposed some ideas for interts to work on GNOME, with me as a mentor. I wrote three proposals this time:

Extend Fractal media viewer with video support and explore video conference
Create Gtranslator initial integration with Damned Lies
Books : Improve the epub support in gnome-books

There was people interested in all of three projects, but for the Books app we don't have any real contribution so there was no real applicants.

I've two good proposals for Fractal and for Gtranslator, so I approve both and the Outreachy people approve these two interts. So we get two new devs working in GNOME for three months as interns.

This is something great, paid developers working in my proposals is a good thing, but this implies that I need to do the mentor work for these two interns during the three months period, so it's more work for me :/

But I think this is a really important work to do to bring more people to the free software, so I've less time for hacking, but I think it's good, because the fresh blood can do the hacking and if, after the Outreachy, one of the interns continues collaborating with GNOME, that will be more important for the GNOME project that some new features in one app.

GNOME Translation Editor

Teja is the intern working in gtranslator. She is working in the Damned Lies integration.

Damned Lies is a web application for GNOME translators. This app provides updated .po file for each GNOME module and language and translators can download and update that file using the web interface. That web is able to do the commit to the original repository with the upload version from translators.

The idea is to provide a simple integration with this platform in the GNOME Translation Editor app, using the web json API to be able to open .po files from the web directly without the need to download the file and then open it.

The current API of DL is really simple so we can't implement a real integration without adding more functionality to this API. So this project requires some work in the DL app too.

In the future we can improve the integration adding the posibility to upload the new .po after saving to DL so translators doesn't need to go to the web interface and can do all the translation flow using only the Translation Editor.

Fractal

Maira is the intern working in Fractal. They are working in the initial video preview widget.

Fractal is a instant messaging app that works over matrix.org. Currently we support different types of messages, like text, images, audio and files. But for video we're using the same widget as we're using for files, so you can download or open, but we've not a preview or inline player.

The main idea of this project is to provide a simple video player using gstreamer to play the video inside the Fractal app.

This is not an easy task, because we're using Rust in Fractal and we need to deal with bindings and language stuff, but I think it's doable.

During the internship, Maira is also working fixing some bugs in the audio player, becuase it uses gstreamer too, so during the code review, Maira detected some problems and they are fixing it.

Fractal December'18 Hackfest (part 2)

danigm — Sun, 16 Dec 2018 00:00:00 +0100

The Friday 14th was the last day of the second Fractal Hackfest. I've not spend much time writing real code, the Thursday was mainly another hacking day and I've been able to continue with the fractal-backend creation, but there's a lot of work to do there.

But the hackfest was really productive, we've talked about big issues, project management, some design ideas, new functionalities, the application refactor, etc.

GNOME newcomers experience

We talked about how to improve the GNOME newcomers experience and how to improve the main view of Fractal. I think that Tobias will talk more about this, he was working in some cool design for this and I think we can start to implement this new views soon.

Best practices

We've been developing Fractal in a fast way, without spend a lot of time thinking about the code quality, maintainability and that stuff. Recently we've set the rustfmt linter in the CI pipeline and we've some tests, but the Merge Requests process wasn't defined and for example I was pushing directly to master.

To improve the quality of Fractal we've started a new wiki page to have a list of best practices to follow. There we'll add some guidances on how we should write code and the processes to follow to improve Fractal.

We've decided that we should be more strict with the Merge Request code review and now, direct push to master is not allowed, all changes will go through the review process. We should wait at least two days to merge something and have at least two people that approve the change.

This will slow down the MR process, but will improve the code quality and will reduce regressions. Any help is welcome, if you're able to test the MR, you can leave a comment and other reviewers will have more confident in the change.

We're also working in the code quality using the cargo clippy tool. There's a Merge Request waiting for review, so we'll have a better rust source code soon.

Fractal is now in the GNOME group

The Fractal project was on the World group inside the GNOME gitlab. Fractal is a GNOME application, the most active developers are GNOME developers and we try to follow the GNOME Human Interface Guidelines.

Fractal is one of the first new applications that born just during the gitlab migration so we go through a new process. At first Fractal was in my personal gitlab under /danigm/fractal then we move to the World group under /World/fractal and finally we're in the main GNOME group /GNOME/fractal.

New release 4.0.0

The last release was the 3.30.0, more than three months has passed since this release and we've a lot of changes so we want to provide a new stable release.

We discuss a bit about the version number that we should follow and we decided that we should do use our own version number system, because we want to release as much as possible, when we've important changes.

We're working in the 4.0.0 release, we're stabilizing and fixing important bugs before the release and maybe we can have the new release during the next week.

So I've spend the last day looking for bugs and preparing the new release.

Matrix Live

We've a meeting with the people from Matrix.org to talk about Fractal and the hackfest. You can view the full interview in youtube:

Friday sponsored lunch

We've a sponsored lunch the Friday 14th, the local group Plan4D invite us to a great lunch in the city center.

After that, I goes back to my home and leave the other people there in Seville doing some tourism, I've to go back to Málaga.

The hackfest was great and we have done a lot of things. This was the second Fractal hackfest in 2018, and we meet at the GUADEC too. We've had two GSoC students and now we've another intern thanks to the outreachy program. There's a lot of people contributing to Fractal and that's great.

GNOME is a great community and I think that Matrix.org and Rust are helping to this project a lot. The Matrix.org people are supporting us, indeed, Matthew comes to the first hackfest and I think that the success of Fractal and the community behind has a lot to thank to the Rust language and to the people working in the Rust + GNOME integration, Gtk-rs is a great project.

I want to apologize about the network problem during the hackfest. We've been working all days thank to Julian network sharing, with eduroam, because we aren't able to have guest access in the university.

The university has a strict internet connection filtering, so only a professor can ask for a guest connection for events and we do the request too late.

Fractal December'18 Hackfest (part 1)

danigm — Wed, 12 Dec 2018 00:00:00 +0100

First two days of work

The Tuesday 11th started the second Fractal Hackfest. I've organized this hackfest in Seville, the city where I studied computer science and here I've a lot of friends in the University so is a good place to do it here.

The weather was important too for the hackfest selection, in December Seville is a good choice because the weather is not too cold, we're having sunny days.

The first day was a good day, thinking about some relevant issues and planning what we want to do. We talked about the work needed for the interface split, about the E2EE support, new features and the need for a new release.

We're having some problems with the internet connection, because the University has a restricted network policy and we ask for the guess internet connection the Monday, but we're still waiting.

Meantime we have to thanks to Julian Sparber the hackfest wifi, because he's using his laptop to stream the eduroam connection.

Newcomers

The first day we try to promote as a newcomers day, and some people comes. We've some contributions and I spend some time trying to help people to introduce to the GNOME community.

GNOME Foundation sponsored dinner

The GNOME Foundation payed for a Fractal dev day dinner, so we should thanks this great dinner to GNOME:

We've a good time eating and drinking in the Coco Verde. We talk about GNOME, the desktop, matrix.org and other communication tools.

Hacking day

Today was a hacking day, so we started to work in the stuff that we talk about yesterday. We've resolved some minor issues and I started with the fractal-backend crate.

We talked about move all the app data model and logic to the fractal-backend and leave fractal-gtk only as UI management.

We talked about the LMDB use to store rooms and messages and we decided that the best solution should be to use a relational database, because we've relations and with the key-value thing we'll end creating those relations and maintaining by hand. In any case, I've this decision in mind and I'm implementing all this with a trait to hide the storage detail so we can change easily in the future.

So today I've spend a lot of time implementing this trait and a first implementation for the Room struct. I've decided to use rusqlite instead the diesel orm because I want to keep it simple.

I want to finish all the database storage and move the AppOp main loop to the fractal-backend and try to update the fractal-gtk to use the backend instead the AppOp struct to get the rooms and messages. But maybe is a lot of work, I don't know if I'll be able to finish this before the end of the hackfest.

Thanks

This hackfest is possible because there's a lot of volunteer work and people helping us. First of all, the Fractal core team that comes Tobias Bernard, Julian Sparber and Alexandre Franke and of course the GNOME Foundation. And also we've to thank Alejandro Domínguez, a newcomer that is doing a really good job fixing bugs and cleaning some old code.

Then I want to thank the Linux local group, SUGUS for the help and also I want to thank to other free software related group Plan4D.

Plan4D is giving us some help with the place and cookies, fruits, juices and some tea.

And finally I want to thank again to my coworkers in wadobo because they support me to spend a full work week working in gnome and they also spend some time helping us to organize all the hackfest stuff.

mdl

danigm — Fri, 03 Aug 2018 00:00:00 +0200

The last month I wrote a blog post about the LMDB Cache database and my wish to use that in Fractal. To summarize, LMDB is a memory-mapped key-value database that persist the data to the filesystem. I want to use this in the Fractal desktop application to replace the current state storage system (we're using simple json files) and as a side effect we can use this storage system to share data between threads because currently we're using a big struct AppOp shared with Arc<Mutex<AppOp>> and this cause some problems because we need to share and lock and update the state there.

The main goal is to define an app data model with smaller structs and store this using LMDB, then we can access to the same data querying the LMDB and we can update the app state storing to the LMDB.

With this change we don't need to share these structs, we only need to query to the LMDB to get the data and the work with that, and this should simplify our code. The other main benefit will be that we'll have this state in the filesystem by default so when we open the app after close, we'll stay in the same state.

Take a look to the gtk TODO example app to view how to use mdl with signals in a real gtk app.

What is mdl

mdl is Data model library to share app state between threads and process and persist the data in the filesystem. Implements a simple way to store structs instances in a LMDB database and other methods like BTreeMap.

I started to play with the LMDB rust binding and writing some simple tests. After some simple tests, I decided to write a simple abstraction to hide the LMDB internals and to provide a simple data storage and to do that I created the mdl crate.

The idea is to be able to define your app model as simple rust structs. LMDB is a key-value database so every struct instance will have an unique key to store in the cache.

The keys are stored in the cache ordered, so we can use some techniques to store related objects and to retrieve all objects of a kind, we only need to build keys correctly, following an scheme. For example, for fractal we can store rooms, members and messages like this:

rooms with key "room:roomid", to store all the room information, title, topic, icon, unread msgs, etc.
members with key "member:roomid:userid", to store all member information.
messages with key "msg:roomid:msgid" to store room messages.

Following this key assignment we can iterate over all rooms by querying all objects that starts with "room", we can get all members and all messages from a room.

This have some inconveniences, because we can't query directly an message by id if we don't know the roomid. If we need that kind of queries, we need to think about another key assignment or maybe we should duplicate data. key-value are simple databases so we don't have the power of relational databases.

Internals

LMDB is fast and efficient, because it's in memory so using this cache won't add a lot of overhead, but to make it simple to use I've to add some overhead, so mdl is easy by default and can be tuned to be really fast.

This crate has three main modules with traits to implement:

model: This contains the Model trait that should implement every struct that we want to make cacheable.
store: This contains the Store trait that's implemented by all the cache systems.
signal: This contains the Signaler trait and two structs that allow us to emit/subscribe to "key" signals.

And two more modules that implements the current two cache systems:

cache: LMDB cache that implements the Store trait.
bcache: BTreeMap cache that implements the Store trait. This is a good example of other cache system that can be used, this doesn't persist to the filesystem.

So we've two main concepts here, the Store and the Model. The model is the plain data and the store is the container of data. We'll be able to add models to the store or to query the store to get stored models. We store our models as key-value where the key is a String and the value is a Vec<u8>, so every model should be serializable.

This serialization is the bigger overhead added. We need to do this because we need to be able to store this in the LMDB database. Every request will create a copy of the object in the database, so we're not using the same data. This can be tuned to use pointers to the real data, but to do that we'll need to use unsafe code and I think that the performance that we'll get with this doesn't deserve the complexity that this will add.

By default, the Model trait has two methods fromb and tob to serialize and deserialize using bincode, so any struct that implements the Model trait and doesn't reimplement these two methods should implement Serialize and Deserialize from serde.

The signal system is an addition to be able to register callbacks to keys modifications in the store, so we can do something when a new objects is added, modified or deleted from the store. The signaler is optional and we should use it in a explicit way.

How to use it

First of all, you should define your data model, the struct that you want to be able to store in the database:

#[derive(Serialize, Deserialize, Debug)]
struct A {
    pub p1: String,
    pub p2: u32,
}

In this example we'll define a struct called A with two attributes, p1, a String, and p2, an u32. We derive Serialize and Deserialize because we're using the default fromb and tob from the Model trait.

Then we need to implement the Model trait:

impl Model for A {
    fn key(&self) -> String {
        format!("{}:{}", self.p1, self.p2)
    }
}

We only reimplement the key method to build a key for every instance of A. In this case our key will be the String followed by the number, so for example if we've something like let a = A { p1: "myk", p2: 42 }; the key will be "myk:42".

Then, to use this we need to have a Store, in this example, we'll use the LMDB store that's the struct Cache:

    // initializing the cache. This str will be the fs persistence path
    let db = "/tmp/mydb.lmdb";
    let cache = Cache::new(db).unwrap();

We pass the path to the filesystem where we want to persist the cache as the first argument, in this example we'll persist to "/tmp/mydb.lmdb". When we ran the program for the first time a directory will be created there. The next time, that cache will be used with the information from the previous execution.

Then, with this cache object we can instantiate an A object and store in the cache:

    // create a new *object* and storing in the cache
    let a = A{ p1: "hello".to_string(), p2: 42 };
    let r = a.store(&cache);
    assert!(r.is_ok());

The store method will serialize the object and store a copy of that in the cache.

After the store, we can query for this object from other process, using the same lmdb path, or from the same process using the cache:

    // querying the cache by key and getting a new *instance*
    let a1: A = A::get(&cache, "hello:42").unwrap();
    assert_eq!(a1.p1, a.p1);
    assert_eq!(a1.p2, a.p2);

We'll get a copy of the original one.

This is the full example:

extern crate mdl;
#[macro_use]
extern crate serde_derive;

use mdl::Cache;
use mdl::Model;
use mdl::Continue;

#[derive(Serialize, Deserialize, Debug)]
struct A {
    pub p1: String,
    pub p2: u32,
}
impl Model for A {
    fn key(&self) -> String {
        format!("{}:{}", self.p1, self.p2)
    }
}

fn main() {
    // initializing the cache. This str will be the fs persistence path
    let db = "/tmp/mydb.lmdb";
    let cache = Cache::new(db).unwrap();

    // create a new *object* and storing in the cache
    let a = A{ p1: "hello".to_string(), p2: 42 };
    let r = a.store(&cache);
    assert!(r.is_ok());

    // querying the cache by key and getting a new *instance*
    let a1: A = A::get(&cache, "hello:42").unwrap();
    assert_eq!(a1.p1, a.p1);
    assert_eq!(a1.p2, a.p2);
}

Iterations

When we store objects with the same key prefix we can iterate over all of the objects, because we don't know the full key of all objects.

Currently there's two ways to iterate over all objects with the same prefix in a Store:

all

This is the simpler way, calling the all method we'll receive a Vec<T> so we've all the objects in a vector.

    let hellows: Vec<A> = A::all(&cache, "hello").unwrap();
    for h in hellows {
        println!("hellow: {}", h.p2);
    }

This has a little problem, because if we've a lot of objects, this will use a lot of memory for the vector and we'll be iterating over all objects twice. To solve this problems, the iter method was created.

iter

The iter method provides a way to call a closure for every object with this prefix in the key. This closure should return a Continue(bool) that will indicates if we should continue iterating of if we should stop the iteration here.

    A::iter(&cache, "hello", |h| {
        println!("hellow: {}", h.p2);
        Continue(true)
    }).unwrap();

Using the Continue we can avoid to iterate over all the objects, for example if we're searching for one concrete object.

We're copying every object, but the iter method is better than the all, because if we don't copy or move the object from the closure, this copy only live in the closure scope, so we'll use less memory and also, we only iterate one. If we use all, we'll iterate over all objects with that prefix to build the vector so if we iterate over that vector another time this will cost more than the iter version.

Signal system

As I said before, the signal system provide us a way to register callbacks to key modifications. The signal system is independent of the Model and Store and can be used independently:

extern crate mdl;

use mdl::Signaler;
use mdl::SignalerAsync;
use mdl::SigType;
use std::sync::{Arc, Mutex};
use std::{thread, time}; 

fn main() {
    let sig = SignalerAsync::new();
    sig.signal_loop();
    let counter = Arc::new(Mutex::new(0));

    // one thread for receive signals
    let sig1 = sig.clone();
    let c1 = counter.clone();
    let t1: thread::JoinHandle<_> =
    thread::spawn(move || {
        let _ = sig1.subscribe("signal", Box::new(move |_sig| {
            *c1.lock().unwrap() += 1;
        }));
    });

    // waiting for threads to finish
    t1.join().unwrap();

    // one thread for emit signals
    let sig2 = sig.clone();
    let t2: thread::JoinHandle<_> =
    thread::spawn(move || {
        sig2.emit(SigType::Update, "signal").unwrap();
        sig2.emit(SigType::Update, "signal:2").unwrap();
        sig2.emit(SigType::Update, "signal:2:3").unwrap();
    });

    // waiting for threads to finish
    t2.join().unwrap();

    let ten_millis = time::Duration::from_millis(10);
    thread::sleep(ten_millis);

    assert_eq!(*counter.lock().unwrap(), 3);
}

In this example we're creating a SignalerAsync that can emit signal and we can subscribe a callback to any signal. The sig.signal_loop(); init the signal loop thread, that wait for signals and call any subscribed callback when a signal comes.

        let _ = sig1.subscribe("signal", Box::new(move |_sig| {
            *c1.lock().unwrap() += 1;
        }));

We subscribe a callback to the signaler. The signaler can be cloned and the list of callbacks will be the same, if you emit a signal in a clone and subscribe in other clone, that signal will trigger the callback.

Then we're emiting some signals:

        sig2.emit(SigType::Update, "signal").unwrap();
        sig2.emit(SigType::Update, "signal:2").unwrap();
        sig2.emit(SigType::Update, "signal:2:3").unwrap();

All of this three signals will trigger the previous callback because the subscription works as a signal starts with. This allow us to subscribe to all new room messages insertion if we follow the previous described keys, subscribing to "msg:roomid" and if we only want to register a callback to be called only when one message is updated we can subscribe to "msg:roomid:msgid" and this callback won't be triggered for other messages.

The callback should be a Box<Fn(signal)> where signal is the following struct:

#[derive(Clone, Debug)]
pub enum SigType {
    Update,
    Delete,
}

#[derive(Clone, Debug)]
pub struct Signal {
    pub type_: SigType,
    pub name: String,
}

Currently only Update and Delete signal types are supported.

Signaler in gtk main loop

All the UI operations in a gtk app should be executed in the gtk main loop so we can't use the SignalerAsync in a gtk app, because this signaler creates one thread for the callbacks so all callbacks should implement the Send trait and if we want to modify, for example, a gtk::Label in a callback, that callback won't implement Send because gtk::Label can't be send between threads safely.

To solve this problem, I've added the SignalerSync. That doesn't launch any threads and where all operations runs in the same thread, even the callback. This is a problem if one of your callbacks locks the thread, because this will lock your interface in a gtk app, so any callback in the sync signaler should be non blocking.

This signaler should be used in a different way, so we should call from time to time to the signal_loop_sync method, that will check for new signals and will trigger any subscribed callback. This signaler doesn't have a signal_loop because we should do the loop in our thread.

This is an example of how to run the signaler loop inside a gtk app:

    let sig = SignalerSync::new();

    let sig1 = sig.clone();
    gtk::timeout_add(50, move || {
        gtk::Continue(sig1.signal_loop_sync())
    });

    // We can subscribe callbacks using the sig here

In this example code we're registering a timeout callback, every 50ms this closure will be called, from the gtk main thread, and the signal_loop_sync will check for signals and call the needed callbacks.

This method returns a bool that's false when the signaler stops. You can stop the signaler calling the stop method.

Point of extension

I've tried to make this crate generic to be able to extend in the future and provide other kind of cache that can be used changing little code in the apps that uses mdl.

This is the main reason to use traits to implement the store, so the first point of extension is to add more cache systems, we're currently two, the LMDB and the BTreeMap, but it would be easy to add more key-value storages, like memcached, unqlie, mongodb, redis, couchdb, etc.

The signaler is really simple, so maybe we can start to think about new signalers that uses Futures and other kind of callbacks registration.

As I said before, mdl does a copy of the data on every write and on every read, so it could be cool to explore the implication of these copies in the performance and try to find methods to reduce this overhead.

LMDB: Cache database in memory

danigm — Sat, 30 Jun 2018 00:00:00 +0200

Some days ago I was in a meeting talking about the E2E implementation for Fractal, to know the current implementation state and to talk with other developers. This meeting was promoted by Puri.sm people, because they want to use Fractal for the Librem5 phone and they want to have E2E. There's people working in the E2E and I think we can have this on Fractal at the end of the year, but this is not what I want to talk about today.

In this meeting there was Fractal developers but we've also other people, like the nheko developer, mujx (nheko is a Qt matrix client). During the meeting, mujx ask us about the cache storage that we're using, because for the E2E is too important to don't lose any key, because that'll be catastrophic, you won't be able to read room messages. So it's important to have a transactional database storage for this information. They are using LMDB, I didn't know nothing about LMDB so after this meeting I start to about it.

LMDB

Lightning Memory-Mapped Database Manager (LMDB) is a key-value database, it's memory mapped so it's fast, and also uses filesystem storage so we've persistence. This database has transactions so it's safe to read/write from different threads or process.

In Fractal we're using a simple json file for cache, but this doesn't support transactions and if the app crash or if something bad happens, we can lose data. This method is simple, but is slow and insecure, so using LMDB will improve Fractal in several ways.

But LMDB is in memory and in Fractal we've a lot of interface code sharing the app state, so we're passing the state between threads with copies and complex data sharing. This can simplify the interface code because using LMDB for the application global state will make this state accesible from different threads.

Testing LMDB

Fractal is written in Rust so I want to write some tests before start to use this on Fractal. There's a simple LMDB rust crate, and I've been writting an example lib to test it.

Basically what I've done is to write a simple trait that you can implement for simple Rust structs so that struct can be stored and recover from the cache with a simple method:

#[derive(Serialize, Deserialize, Debug)]
struct B {
    pub id: u32,
    pub complex: Vec<String>,
}
impl Cacheable for B {
    fn db() -> &'static str { "TESTDB" }
    fn key(&self) -> String {
        format!("b:{}", self.id)
    }
}

The struct should be serializable/deserializable with serde because in this example I'm using bincode to convert structs to [u8].

The Cacheable trait only have two required methods, the db and the key. The db is the db name to use to store this struct instances and the key is the key to use when storing a concrete instance.

With this, we can store in the cache and query from the cache, using the key:

let db = &format!("{}-basic", DB);
let mut cache = Cache::new(db).unwrap();

let b = B{ id: 1, complex: vec![] };
let r = b.store(&mut cache);
assert!(r.is_ok());

let b1: B = B::get(&mut cache, "b:1").unwrap();
assert_eq!(b1.id, b.id);
assert_eq!(b1.complex.len(), 0);
b1.complex.push("One string".to_string());
b1.complex.push("Second string".to_string());
b1.store(&mut cache);

let b2: B = B::get(&mut cache, "b:1").unwrap();
assert_eq!(b2.id, b.id);
assert_eq!(b2.complex.len(), 2);
assert_eq!(&b2.complex[0][..], "One string");

This is thread safe, so we can read from the cache from different threads and we'll always get the last version in the database.

LMDB is a key-value database, so we don't have relations. This is not a real problem for us because we can model the relations in the keys, for example, we can store Room messages with keys like this "message:ROOMID:messageID" and then we can iterate over all objects with this prefix: "message:ROOMID" that will give us all room messages. Something like this should work:

let prefix = format!("message:{}", room.id);
Message::iter(&mut cache, &prefix, |m| {
    // m is a Message struct fetched from the database, we can do
    // what we want here
    // ...
    Continue(true)
});

LMDB in Fractal data model

We're thinking about moving the Fractal data model from the AppOp struct to a new crate, independent of the UI, to simplify the UI code and to be able to use the same data model from different UIs (we wan't to split fractal in two different apps), Julian wrote about this.

I think that we can use the LMDB cache to store this new app state that we want to have and this will simplify a lot our code, because we will share the same state and this state will be persisted in filesystem.

I'll start to write a new crate for Fractal to start to move all the app state to this new crate. I think I can write a generic tool to simplify the LMDB use, maybe I'll publish another crate in crates.io and use that in Fractal, but I need to think a little more about the pattern to follow.

I write a lot of web code in my day to day work, and I've been working with react+redux. This LMDB cache thing in Fractal reminds me a lot to the redux store and I want to follow a similar pattern so we can have only an app state and only a way to update this state.

Stickers in Riot

danigm — Sat, 19 May 2018 00:00:00 +0200

Yesterday I read a blog post about the new Riot.im Stickers. This is not a matrix.org feature, it's implemented as a widget, when you send an sticker you're sending a new event with the type "m.sticker", which is similar to the "m.image" event.

The matrix.org protocol is flexible so this is a good example of how to add new features to the clients that uses matrix without the need to change the protocol.

This is not a core feature because you can send images, but I think this is great and add a simple way to show reactions for the users, so as I was reading I thought that we can add this to Fractal, so I started to read how we can add support for this.

Reading the doc

The first thing to implement a feature is to read the specifications or the technical documentation so we can know what is needed... But there's no documentation yet about Stickers or widgets yet.

This is a problem because we can't implement a feature if we don't know what we should do. But free software give us a great opportunity when this happens, we've the Riot source code so we can look at the code and learn what they are doing.

Reading the code

Riot web is a javascript application that uses AJAX to communicate with different server APIs so the first thing that I did to start to understand the stickers thing was to open the firefox debugger and view how riot is communicating with the server.

From here I've learned that for stickers riot is asking to the scalar.vector.im server. But I don't understand the whole thing with the requests because riot does a lot of request to different APIs and I can't isolate the stickers thing easily.

To fill my understanding gap I go to the matrix-js-sdk and matrix-react-sdk and I did a quick grep to the source code looking for the API calls that I've view in firefox. With this I can understand the full stickers process.

Writing an example

To say that I know how this is working, it's not enough the code reading. To make sure that I've understood the whole process I need to write a simple program that does all the process and then I can say that I understand this.

So I started to write a simple python script using requests. This simple script does the request to the server and list all the stickers json so I can say that I'm able to communicate with the API.

Stickers in Fractal

After this small research I'm able to implement an initial sticker support for Fractal. I'll try to add a simple way to show and use stickers and a way to render stickers in the messages history.

If there's no secret problems we'll have a basic stickers support in Fractal soon.

Fractal Hackfest, Strasbourg (day 2)

danigm — Sat, 12 May 2018 00:00:00 +0200

The second day of Fractal hackfest was really productive, we talk about a lot of topics and takes some important decisions.

E2E Encryption

The encryption is a needed feature but encryption is hard to do in rooms. Matrix uses public-key cryptography, for rooms they are using Megolm, that's a protocol to exchange encrypted messages with more than one and share that message keys in a one-to-one secure communication.

I don't know a lot about this E2E because for me it's more important to have the client working with a basic functionality before the encryption. So you should read the official doc because maybe this that I'm writing here is completely wrong.

To do all this E2E key sharing, client side encryption and communication, Riot has three different implementations of the same lib, so they have this code in the JavaScript SDK, the same ported to iOS version in ObjectiveC and the same ported to Android in Java. Below this lib there's the libolm that does the real encryption.

For the future it should be a good solution to have only one lib that does the encryption thing, so we need to push in that direction and maybe matrix.org and Purism can pay for that work to be done.

From Fractal, we've two options or wait until we've the official E2E C/C++-lib or something, or try to port the iOS lib to Rust or C to use in our codebase. I think that the best solution is the first one, in any case, we'll need to wait some time to view E2E in Fractal.

Calls

Calls are easy compared to the Encryption thing, the protocol is well documented and it's really simple. The hard part here is that the call is implemented using the webRTC and that is a web protocol... But it seems that there's something done in this case with GStreamer working with webRTC.

Multiple accounts

We was talking yesterday about the multiple accounts problem, if we want to support and in that case what solution we should take.

We've two possible solutions, one is to support multiple accounts at the same time and a way to change between accounts, and the other one is to open a window for each account.

At the end we think that the best solution could be to open a separated window for each account so if you've multiple accounts, at first you should choose what account you want to open and then from the menu you can open a new window and go to the account selection menu again.

We need to work in the design of this feature and it's not confirmed but I think that this was the best solution, because it's simple and powerful.

Communities

Communities are something really new in the Matrix.org protocol and it's not well documented yet and there's some functionality that is not implemented so we decide to wait until this functionality is more mature to view how we can integrate this in Fractal.

Communities today are a group of rooms and a group of people and a full html description to show in the community page. There's other features like show a label for each member of the community or group, so I think these features are cool. We'll need to support some parts of the communities protocol soon.

Google Summer of Code

As I said this year we've two students working on Fractal thanks to Google, as part of the GNOME organization, and both students comes to the Hackfest so thank you Julian and Eisha for coming and for the work done before the GSoC and for sure for the work you'll be doing during the summer.

We're talking about how we'll be organizing, I'm the mentor of both but we'll have the help from Tobias Bernard and from Alexandre Franke so we'll have a summer hacking group to improve Fractal a lot.

We'll have a weekly meeting to talk about what we're doing and what to do in the next week.

For this first week we'll start with two needed features. Julian will be working in the user preference dialog and Eisha will start to work in the internationalization (i18n) because it's not easy to use gettext in rust and we want to translate the app to make it more accessible for everyone in the world.

Hacking a bit

In the meantime, between functionality discussion I was working in a way to use Fractal without SecretService, so if you're using Fractal outside GNOME or KDE you can configure it to store password and token in a plain text. We shouldn't store passwords in a clear text file, but I think that this will simplify the day for many people that wants to use Fractal but don't want to write the user and password every time.

This is not finished yet, but we'll have this very soon, and with this it's possible to implement other password & token storage services and make it configurable, so maybe in the future someone implements the storage for MacOS or something.

Holidays

This was my last day in the hackfest, I've the travel back to Spain the Sunday but I'll do some tourism here so I need to leave the people, they will continue working the Saturday and the Sunday.

This have been the first Fractal hackfest and it was a great experience, to meet other people working on it and to talk about the future of the application. It's really cool that with less than a year project we've now a big community, so thank you all form coming and see you on GUADEC.

There's a lot of work to do, but we're lucky because we're two students working in Fractal this summer and the people from Matrix.org and Purism are working with us, so thank you all.

I want to thank again the GNOME foundation and GNOME people for make this possible and to my company Wadobo, for let me spend some time working on this great project.

Fractal Hackfest, Strasbourg (day 1)

danigm — Fri, 11 May 2018 00:00:00 +0200

Yesterday was the first day in the first Fractal Hackfest. I'll try to write an small blog post every day to share the development with the world.

My travel to Strasbourg was not an easy travel because I've to take two flights to get here from Málaga so a long day travelling.

I met with Mathew from Matrix.org at the London airport because we took the same flight to here and it was really cool to meet him in person and we talk a little about the current Matrix situation.

I've met the other Fractal people and collaborators at the event, and it's great that people from Purism, Matrix, Gnome and the two GSoC students come here to work together in this great application.

Barbecue and Banquet

We've spend almost all the day talking about the different uses cases for the messaging problem and Tobias has come with a proposal for split the current application in two because the use case is totally different.

We've the first case when you use the app to talk to family, friends and small groups of people where all conversations are private and you want to read almost every message there, we call that situation the "Barbecue".

The second case is the one where you use the messaging app to talk in a public or private room with a lot of people, where you are receiving a lot of messages but you don't want to follow the full conversation you'll talk with someone or read a topic conversation, we call this one the "Banquet".

Currently Matrix clients are more oriented to the Banquet use case so there's a lot of people and communities using it for this. The idea behind this split is to provide two apps to the user to make both cases possible.

We need to work on this idea but it seems that is the correct way to go.

Initial Syn speed up

At the afternoon. We've reviewing the current initial sync filter and detect some points to speedup.

I changed the filter and the initial sync goes a lot faster. I've removed the member events from the initial sync so there's a lot of less information to retrieve from the server.

This little change breaks the one to one room name and default avatars because that name is calculated using the members in the room so I need to fix that making the name calculation a backend process. So now if a room has no name, We'll ask for the room member list and when we've that we'll calculate the room name with the same algorithm, if there're only two people, we'll use the other person username, if there's three people we'll use "one and another" and if there're more we'll use "one and others".

Gnome dinner

We've a good dinner sponsored by the gnome foundation. Thank you so much.