Become Local-First: Not Your Keys, Not Your Data | Matěj Husák, Trezor | ETHSofia 2026

[music] All right. Thank you.

So, so not your keys, not your coins. That's well a phrase that we all know, right? And my presentation kind of steals it for the title and tweaks it a little bit and it says not your keys, not your data. Why? Well, because I think the keys part is kind of like sorted out.

We have hardware wallets. We use multisix. We also have like a proper setup for our backups. But I don't think we have something like that for the data. So uh the cure to this diagnosis is in my honest opinion to become local first.

So the presentation name is become local first, not your keys, not your data. Uh I'm Matt. Uh I work at Treasure. I'm really glad to be here and today I want to talk about what it actually means to become a local first. What benefit it has and uh how you need to change your mind.

Uh so I will start with some distinction of two different terms and that's security and privacy. So security means you have some sort of a secret that you don't want to leak and that's why we mostly use the Harvard wallets because they don't leak our secret right. But uh the privacy means you want to control the data that you want to share with others uh in the terms of like size and to who to share it with. And for example, you can imagine you have a transaction and you want to label it. So you want to say hey this transaction is like uh I don't know my salary, this pays my rent uh etc.

And usually like these data kind of enriches our experience. uh that we work with the with the key store and enriches the flow of the keys. But these are mostly like off-chain data and we usually hand them to someone else's cloud. Even in the treasure uh when you turn on a labeling, you were asked if you want to save it to your local file system only into one file or some any third party uh cloud. And that's how most things works nowadays.

you have a central server for your application that owns your data and if you want your application to actually do something you have to go to the server and then ask like hey can I have my own data by the way and that's how it works today uh you I guess you get the point like asking someone else for your own data is not an ideal setup so there's a approach that's been called a local first approach And in this approach, your device is the source of the truth. The server in this case we call the server relay just syncs the copies of your uh across your devices. And by devices, I don't mean your hardware wallets. I mean like your um MacBook or uh or phone. The term itself local first approach was actually set up by ink and switch essay in 2019.

Uh, by the way, I really recommend reading that essay because it really shows the sentiment behind it and what benefits it has besides those that we will talk today, but we don't have much time to talk about them. And but that doesn't mean it was set in 2019. Uh actually in 1989 we had a application that was called Lotus Nodes and that was some sort of a first of those local first application that did birectional syncing between the devices and was kind of good at it. So uh local first approach kind of changes the mindset that we look at nowadays application because you want to own your data not anyone else. Uh yeah there is also a really good myth.

Uh so for those who are not really familiar what local first means they usually kind of mix it with offline mode. And uh offline mode in nowadays standard is nothing else than just a some sort of degradated state of a application. So it kind of shows you banner hey you need to connect to your internet. Okay. Uh you don't you can't use these features because you're not connected to the internet.

Uh a really really great example that happened like couple of minutes uh in the backstage because I wanted to see like uh what decks I have. I went uh to my cloud presentation creation application. I went I I could see all of the slides, the images, but then I was like, hm, maybe I should turn on the full screen and like click it through and and no, you're not connected to the information. Me as the application, I have the data, but no, full screen is not available. So, uh the benefits of the local first approach is not just it's like fast because you have the data locally.

You don't have to fetch or do any network changes. It's also the mindset switch you actually can own the data and literally like the worstc case scenario that could happen in such uh local first application is that that you borrow for some sort of period of time your data to some API that needs to do some transform but it states locally you can work uh even without being connected to the internet and it's it's just how the things should be right uh so you might want to build your own local first application and there are mainly three problem plus one that applies across all of these problems to follow. In general, you should not have a server that you trust because you want to own your data, right? Uh and then you have those three problems that you can see on the on the presentation. The first one is actually you need to encrypt your data.

uh for example, you want to sync some sort of data from device A to device B and you don't want someone to intercept in the middle and read your data what you're syncing. So you need some sort of a key and you need to encrypt it. Uh obviously if you're building some public stuff uh the encryption would be not needed and you can share it like freely. Uh the second thing or the second problem that you have to solve is actually the synchronization. And it might seem like very easy to transfer just like two data from the devices from one one device to another one.

But it's actually the hardest part of this local first approach because let's imagine you have two devices uh both of them are offline and you do changes on both of them. How do you resolve the conflicts like which one applies? Uh yeah. So that's actually the the hardest problem to sync it conflict free and to to keep the right version. If you're building for people that or if your application is for like wide uh base of users, not everyone is also possible to host the relay by themselves.

Uh so in that case you have to create some default relay that you can offer to the users. But then you have another set of problems. You have to prevent the abuse. you have to do some sort of a data storage limitation so people won't like store like gazillions of data in there and then you get the bill from the from the server right uh so the third problem is actually to prevent uh the abuse uh handle some sort of a limits uh by the way uh we did not have to to make the solution for the syncing from the ground up we were doing some sort of a research of the local first libraries that were out there and We stumbled upon one library that is from Daniel. Uh that's a cipher punk that likes privacy and local first and it's called Evolu.

Evolu is like really great library. Uh there are like a lot of technical stuffs that are also interesting in a good way and uh it's just a good library. It solves all the problems efficiently. It uses SQLite under the hood. It has a uh improved merries for uh conflict uh resolution and seeing what changed.

It has uh conflict or CRDT message envelope and so on. But yeah uh then you need to encrypt the data and you don't want to make user fill out the password or password. So what what's how how to do it? So the UX is not bad. Uh the best case is actually the one uh that the users already have.

So that's the seat on their device or hardware wallet and we decided to derive uh the keys from the seed deterministically so that the user doesn't have to fill some passwords and and crazy stuff. Uh how did we do it? Well, we have a set of shells improvement proposal 31 which is a method for uh uh deterministic hierarchy derivation from master secret which in the case is the seat. We derive three main keys. Owner ID, encryption key, right key.

Owner ID basically tells to the relay who owns the data. Right key is basically a token that with the combination of the owner ID let you actually change the data that you own on the relay. So no one else can can actually change your data. And then we derive the encryption key. Uh that encryption key just encrypts the data.

As I said, owner ID and right key are the only two keys that kind of reach the relay. Uh they need to reach the relay because the relay then now knows who can change the data. So uh the sync problem the most like interesting part in uh this problem or the evol that kind of solves besides the CRDT and the the improved uh merries is the hybrid clock. So imagine you have two devices both of them are offline you do change on device E uh device A then you do changes on device B and then you connect to the internet and the relay is like relay gets like two two changes and needs to decide like which which one is the newest one. So uh when your device is sending data to the relay, it's wrapped in a so-called CRD message envelope which is a envelope that along the data uh travels with some additional uh additional data in in this case it's the time stamp the hybrid clock from the device.

So when relays sees this, it actually uh knows which message is the newest one because it compares the hybrid clock timestamps values and the size which one is the correct one. Also uh for the case when you have two different fields coming from two devices, there's nothing to solve because they are new, right? So both of them are preserved. Cool. So as I said uh if you're building for some wider user base you need to uh also provide them some default relay or let them selfhost uh we have a some some sort of a quota manager solution for providing the relay and only thing what quota manager does is that anonymously checks if the device the hardware wallet has a proof to save labels.

uh data to the relay. I won't get too much deeper in this because we have no no more time left. Uh but uh actually we we had to solve this problem. Uh it's like pretty much interesting uh the way the device proves that it's unique and uh and authentic. So about the thread model, so what what the relay can actually see.

So uh it can see that there's are some bunch of owner ID hashes uh and then basically like nothing nothing pretty much important. It can see uh the timestamps because that's what they what the relay needs for uh resolving the conflicts. But then it even like comp it even can't compare the data sizes uh because there's some petting happening. So you cannot check if some of the shorter data uh mean something etc. Uh this slide is actually related to uh the UX of it.

So we want uh people to not uh type in some password or passphrase. The en encryption key is actually on desktop and mobile being saved in a uh safe storage that uh lets you without any additional uh typing do the uh the encryption and the decryption and yeah that's basically it. You already hold your keys. So now now hold your data. Thank you [applause] [laughter]

Matt. This was great. You're already escaping. Thank you very, very much. I just wanted to double check if anyone had a burning question.

If so, feel free to post it because we still have one minute. If not, make sure to catch Matt off stage. Just double checking if anyone has a [music] very brief question for Matt. Yeah. Yeah.

I I just checked Vlad. Let me double check because I didn't see anything on the um on the app. Ah, there is one. Fantastic. So Matt, the question is what are the realworld applications for this?

Okay, so uh I will mention the treasure companion app and for a long time we had the ability to let users label a transaction uh that you have on your account. But it was like the the syncing between the devices was kind of limited to two options. So you either was able to save it to a local file that did not sync across the devices or you could choose some third party clouds. Uh it was not ideal solution. So we uh implemented this and it and it works with the labels.

So there are some plans to extend within the treasure companion app. But if you if you actually open the evolve website you can see what applications the evol is using and the list is kind of growing. So that's basically the best source of uh information for the real applications nowadays.

Thank you very very much indeed. Please give a round of applause for Matthew. [music]