Migrating from gather.town?
Get a discount!







Attending the Matrix fringe event at FOSDEM 2025

Yesterday, I had the pleasure to attend (and sponsor!) the Matrix fringe event.

Matrix fringe event?

The event happened in Bruxelles. It is a side-event of the FOSDEM, the biggest open-source event in Europe (believe me, it is huge)

I had a total blast at the fringe event. As every Matrix event I attended, it is just the right size (50 to 100 people). It was organized in an unconf format which is great. Everyone gets to say what they can bring, and what they would like to receive, and the schedule is built at the beginning of the event.

This article is a summary of the event from my perspective.
I met plenty of great people, learned a ton of things (some unexpected) and generally, I highly recommend attending such events. Math and Yan did a great job at organizing this.

Here is what I learned:

When shall we trigger cross-signing?

My primary interest when I arrived to this event was learning more about the way encryption works and to find if the “invisible crypto” initiative spearheaded by Element could prevent WorkAdventure from communicating with Element. More specifically, invisible crypto advocates that every device should be cross-signed which is not realistic for WorkAdventure (here is a link to the article explaining why).

I got some great comments there. First of all, I learned the day before the event that Matrix treats differently cryptographic and non cryptographic devices. A cryptographic device is a device that has uploaded device keys to the Matrix home-server. It turns out those are handled differently by Element. If you have a cryptographic device that is not cross-signed linked to your account, Element will complain if you try to send a message in any encrypted room.

But how did we fail to realize that at WorkAdventure? The thing is we are using the Matrix-JS-SDK library.
This library uploads the device keys to the home server when crypto is initialized (through the initCrypto method). This is done automatically by the library. We never realized that because we never had to deal with the device keys ourselves.

As a result, WorkAdventure was always seen by others as a cryptographic device, even if the user did not cross-sign.
And since we are looking into cross-signing “on-demand”, there were a number of cases where the user was not cross-signed, but the device was seen as cryptographic.
This let Element to view this as an error condition. According to the invisible crypto initiative, every cryptographic device should be cross-signed and if just one is not cross-signed, Element starts to display warnings when you try to send messages.

The good news is: if we delay the initialization of the crypto, we can avoid this issue. We can initialize the crypto only when the user wants to create or join an encrypted room.
One important thing: for web applications, one device = one session. So each time a user logs back, it is a new device, with a new session and the need to cross-sign again.

Also, up until yesterday, I was convinced that the right thing for WorkAdventure was to do the cross-signing as late as possible (i.e. on-demand).
Why? A lot of our users are invited by people organizing events. They essentially come once on the platform, attend the event, and will never come back.
It is a bit of a waste to ask them to cross-sign their device if they will never come back.

But at the same time, we have some users that are using WorkAdventure as a virtual office, on a daily basis. For those users, it is absolutely logic to apply cross-signing at login time, just like Element is doing.
Someone proposed a solution: we could have settings at the “world” level that decides when cross-signing is done.
That could be a good compromise. For this to work, we need to know in advance what a room will be used for. This might be something we ask in the future.

Passphrases are a thing of the past

Gosh! This was a surprise.

A bit of context: in order to cross-sign a device, you need a recovery key. This key is generated when you create your account. It is a long string of characters that you must store somewhere safe. If you lose this key, you lose access to your account.
Because storing the recovery key is hard, a workaround was devised: the passphrase. The passphrase is a string of characters provided by the users (so it is easier to remember) that is used to encrypt the recovery key. This way, you only need to remember the passphrase to recover your account.

While the idea seemed brilliant, it turns out that it is not. When a user connects, the typical experience is to enter a login and a password.
Once connected, the user now needs to enter the passphrase. This is confusing. What’s the difference between a password and a passphrase? Why do I need to enter two things?

People understand better the notion of key that you must store.

So Element is moving away from passphrases. They will keep supporting recovery via passphrase for existing users, but when new accounts are created, the user is not prompted to create a passphrase anymore.
Beeper never supported those. And it seems that the Matrix community is moving away from those.

Kubernetes and Helm charts

I had an absolutely passionate and geeky discussion about Kubernetes and Helm charts (hey Alexander!). This was unexpected as the event was not really about Kubernetes but I learned a ton of things.

First of all, I learned that Tanka is not dead. Tanka is a super library to do Jsonnet that generates Kubernetes.
I had been using it quite a bunch 5 or 6 years ago along with ksonnet. Unless Helm that is doing templating on strings, Tanka is providing a real functional programming language to manipulate Kubernetes manifest.

I absolutely loved it and assumed it was dead when it was not. Cool!

Along Tanka, I also learned about Cue that seems to fill the same niche. I have not tried it yet, but I will give it a look.

As I was complaining about Helm, I learned there are plenty of great chart sources. I tend to use Bitnami like everyone else,
but I’ve been recommended charts from Zalando, CrunchyData, CNPG, Percona… I’ll need to give them a a proper try!

Beers and pizzas

An event in IT would not be complete without beers and pizzas. We -at WorkAdventure- have had the pleasure to participate into
sponsoring those. It’s the least we can do as we benefit from this ecosystem. I had a great time discussing with people from Element, Beeper, system administrators from various universities, people doing hosting. A special mention to my first try at tasting Swedish candies. Let’s just say I was not ready 🙂