WEBVTT 00:00.000 --> 00:15.000 We are going to present auto merge plus key hive, the design of a view. 00:15.000 --> 00:22.000 Thanks for your patience everyone. 00:22.000 --> 00:28.000 We are going to talk about auto machine key hive and local first infrastructure. 00:28.000 --> 00:30.000 I am Alex. 00:30.000 --> 00:31.000 I am Brooke. 00:31.000 --> 00:37.000 We are going to talk about auto merge and key hive. 00:38.000 --> 00:44.000 Thank you everyone. 00:44.000 --> 00:49.000 I am going to start by talking about the problem that we think local first infrastructure 00:49.000 --> 00:51.000 can solve. 00:51.000 --> 00:54.000 I am going to do that by talking a little bit about a little story I would like to tell 00:54.000 --> 00:58.000 which is how about five years ago I wrote this application which is a little 00:58.000 --> 01:01.000 tiny little Android app for tracking work. 01:02.000 --> 01:07.000 It is basically a nice front end on a spreadsheet because using a spreadsheet in the gym is 01:07.000 --> 01:08.000 pretty hard work. 01:08.000 --> 01:11.000 I was very pleased with it and then a friend of mine a week later said, 01:11.000 --> 01:15.000 could I have that and I would like to use it to sync with my laptop. 01:15.000 --> 01:19.000 I thought about why we need to do to allow him to be able to sync with his laptop. 01:19.000 --> 01:22.000 He would have to write a server-side component in some language. 01:22.000 --> 01:23.000 I would have to. 01:23.000 --> 01:24.000 It is back. 01:24.000 --> 01:26.000 It is eventually there. 01:26.000 --> 01:29.000 I would have to write some sync code. 01:30.000 --> 01:33.000 The most important thing is I would have to run a server somewhere. 01:33.000 --> 01:35.000 He would have to run a server somewhere. 01:35.000 --> 01:39.000 I think this particular story is a very small piece of software that I wrote almost as a 01:39.000 --> 01:40.000 throw away. 01:40.000 --> 01:42.000 It is not a very important thing. 01:42.000 --> 01:46.000 I think the fact that I would have to host a server somewhere in order to do this represents 01:46.000 --> 01:51.000 like a loss or a difficulty in it. 01:51.000 --> 01:53.000 You want me to speak louder? 01:53.000 --> 01:54.000 Yeah. 01:54.000 --> 01:56.000 All right. 01:56.000 --> 02:00.000 I represent a lot of something that I think is really important in open source software. 02:00.000 --> 02:04.000 The most important thing to me about open source software is the autonomy that it gives me. 02:04.000 --> 02:07.000 If I don't like a change that someone makes to a piece of software, 02:07.000 --> 02:10.000 I can make a change to it or someone makes, I can refuse that change. 02:10.000 --> 02:13.000 I have a lot more freedom than with the closed source software. 02:13.000 --> 02:16.000 As soon as you have a server-side component running, 02:16.000 --> 02:20.000 whoever is running that server is now controlling something about your experiences. 02:20.000 --> 02:26.000 Now, I am able to force choices on you that you don't like. 02:26.000 --> 02:30.000 I think the normal answer that we think of in open source to this problem is say, 02:30.000 --> 02:34.000 well, you should run every part of the stack yourself. 02:34.000 --> 02:36.000 I think that works for some things. 02:36.000 --> 02:38.000 It works for big, important things. 02:38.000 --> 02:43.000 But for these little things, this little app that I wrote from a workout tracker. 02:43.000 --> 02:44.000 I am not going to do that. 02:44.000 --> 02:48.000 I am not going to run a server for every little piece of software on the right. 02:48.000 --> 02:52.000 I think that the analogy to infrastructure here is a little bit like electricity. 02:52.000 --> 02:56.000 Factories used to build their own power stations. 02:56.000 --> 02:58.000 And that is great for factories and many still do. 02:58.000 --> 03:02.000 But I don't want to build a power station to use my Hoover. 03:02.000 --> 03:06.000 I want to have a piece of infrastructure that I can plug into. 03:06.000 --> 03:08.000 And this is the problem here. 03:08.000 --> 03:09.000 Self-hosting is work. 03:09.000 --> 03:12.000 It means that most people don't self-host. 03:12.000 --> 03:15.000 Even if the whole stack of a piece of software is open source, 03:15.000 --> 03:19.000 we don't actually get the autonomy that we want it. 03:19.000 --> 03:20.000 So we are in this room. 03:20.000 --> 03:22.000 Obviously, local first is the answer. 03:22.000 --> 03:24.000 This is what I am going to say. 03:24.000 --> 03:25.000 You expect. 03:25.000 --> 03:29.000 And there is a lot of appealing things about local first there. 03:29.000 --> 03:30.000 I know servers needed. 03:30.000 --> 03:35.000 That is the principle behind local first is the local version of the data. 03:35.000 --> 03:38.000 It is the thing that is primary. 03:38.000 --> 03:42.000 But servers are actually really useful. 03:43.000 --> 03:47.000 Even if you are in a local first peer-to-peer world, 03:47.000 --> 03:48.000 servers are always on. 03:48.000 --> 03:50.000 If you don't have a server that is always on, 03:50.000 --> 03:52.000 if you are just peer-to-peer between our laptops, 03:52.000 --> 03:55.000 we have to make sure that whoever has the data has their machine on. 03:55.000 --> 04:00.000 Also, modern networks are kind of impenetrable for peer-to-peer. 04:00.000 --> 04:02.000 Use cases a lot of the time. 04:02.000 --> 04:06.000 And having a well-connected, well-known location where something is always on, 04:06.000 --> 04:09.000 makes connectivity much easier. 04:09.000 --> 04:12.000 And it is easier to do back up and redundancy on a server. 04:12.000 --> 04:14.000 So servers are really useful. 04:14.000 --> 04:18.000 I don't think we actually get much benefit from saying we shouldn't use them at all. 04:18.000 --> 04:25.000 Instead, I think we want a couple of design principles that make it possible to work with servers without sacrificing an autonomy. 04:25.000 --> 04:28.000 First of, you should always be able to use some server. 04:28.000 --> 04:31.000 It doesn't matter which server you should be able to stand one up. 04:31.000 --> 04:34.000 You should be able to, any kind of server you can point out, 04:34.000 --> 04:36.000 it should be pretty fungable with a placeable thing. 04:37.000 --> 04:40.000 Secondly, you should never be required to use any particular server. 04:40.000 --> 04:42.000 Like, if you're using your things server finance, you'll be able to use mine. 04:42.000 --> 04:47.000 We should still be able to collaborate without having been forced to use the same ones. 04:47.000 --> 04:53.000 And a server should never be able to do anything more dangerous than just not serve data. 04:53.000 --> 04:58.000 And so those kind of principles are behind how automates works. 04:58.000 --> 05:01.000 So I'm going to just briefly introduce automates. 05:01.000 --> 05:05.000 This is a very high level over the architecture rather than a workflow of how to use automates. 05:06.000 --> 05:11.000 This is a very brief intro, but automates is a JavaScript library. 05:11.000 --> 05:15.000 Well, it's also a couple of other platforms, but this is the JavaScript version. 05:15.000 --> 05:17.000 And it's centered around documents. 05:17.000 --> 05:19.000 So you create an automates document. 05:19.000 --> 05:22.000 The document appears just like a JavaScript object. 05:22.000 --> 05:26.000 Except that when you want to make changes to it, you call this function to make changes to it. 05:26.000 --> 05:32.000 And you can see here we've given a callback where we modify some attributes of this document. 05:32.000 --> 05:36.000 And then you can merge that document with other versions of the same document. 05:36.000 --> 05:38.000 And conflicts are resolved automatically. 05:38.000 --> 05:40.000 I'm not claiming that this is magical. 05:40.000 --> 05:43.000 It's similar to the way that JavaScript works in a lot of ways. 05:43.000 --> 05:44.000 It's all dubbed based. 05:44.000 --> 05:47.000 Like last break wins based conflict resolution. 05:47.000 --> 05:49.000 But we hold on to the history. 05:49.000 --> 05:54.000 So if you want to if you want to go and look at how that conflict resolve change it, you can do that. 05:54.000 --> 05:57.000 Great. 05:57.000 --> 06:00.000 How do we actually do that? 06:00.000 --> 06:05.000 That's the interesting part I want to talk about here with respect to the infrastructure arguments. 06:05.000 --> 06:09.000 Is that we already have a local first application where servers are pretty 06:09.000 --> 06:14.000 Fundable, which allows you to work with local changes. 06:14.000 --> 06:15.000 And that's Git. 06:15.000 --> 06:17.000 It gets really, really good of this stuff. 06:17.000 --> 06:19.000 And one way, it's also really, really bad of this stuff. 06:19.000 --> 06:21.000 Everyone hates Git for good reasons. 06:21.000 --> 06:24.000 But the core model is powerful. 06:24.000 --> 06:27.000 And one way of thinking about what to imagine is it's like Git for JSON. 06:28.000 --> 06:30.000 And what it means by that is the under the hood. 06:30.000 --> 06:33.000 An automated document is a commit. 06:33.000 --> 06:34.000 Dag like this. 06:34.000 --> 06:39.000 Where instead of in Git, where the contents of each commit would be the changed files. 06:39.000 --> 06:42.000 Well, actually, you can tie a snapshot of the file system. 06:42.000 --> 06:48.000 But in auto merge, the contents of each commit are changes to an auto to a JSON document. 06:48.000 --> 06:53.000 JSON like, there's some extra features over JSON, but that's not too important for now. 06:54.000 --> 06:56.000 And this has some nice properties. 06:56.000 --> 06:59.000 Most importantly, the server just has to ship commits around. 06:59.000 --> 07:01.000 It doesn't have any special logic. 07:01.000 --> 07:02.000 It doesn't. 07:02.000 --> 07:05.000 You know, you actually have to care about the contents of those commits. 07:05.000 --> 07:08.000 So, see later, that means we can actually encrypt the contents of the commits. 07:08.000 --> 07:11.000 And the server doesn't need to know anything different. 07:11.000 --> 07:13.000 We can examine the history. 07:13.000 --> 07:15.000 So, we never throw away any of these commits. 07:15.000 --> 07:19.000 That means that you can always, someone, I can always say, 07:19.000 --> 07:21.000 Oh, no, at this point in the commit history I was doing eggs. 07:21.000 --> 07:22.000 And I can go back and look at it. 07:22.000 --> 07:25.000 I can compare the difference between two points of history. 07:25.000 --> 07:30.000 So, I can dip, dip the document just like you can with Git. 07:30.000 --> 07:35.000 And it's hashling, which has some really useful properties when we're talking about infrastructure. 07:35.000 --> 07:39.000 Which is, one, if you and I both have the same, 07:39.000 --> 07:41.000 I've derived the same hash for some commit. 07:41.000 --> 07:43.000 We know that we're looking at the same thing. 07:43.000 --> 07:45.000 Right? Like, we don't have to trust anyone in between, 07:45.000 --> 07:48.000 correctly, shipped, day around. 07:49.000 --> 07:52.000 And we, correctly, doesn't just mean that they weren't malicious. 07:52.000 --> 07:53.000 It means that they weren't buggy. 07:53.000 --> 07:55.000 And that's really useful. 07:55.000 --> 07:58.000 Because a lot of, we're talking about concurrent changes. 07:58.000 --> 08:00.000 A lot of the educators are pretty fedly. 08:00.000 --> 08:03.000 Knowing that we both have the exact same data. 08:03.000 --> 08:05.000 If we know that and we've seen something different, 08:05.000 --> 08:07.000 we know that we have a view, probably, 08:07.000 --> 08:09.000 and the implementation is correct producing the wrong view, 08:09.000 --> 08:10.000 but we have the same data. 08:10.000 --> 08:14.000 And it also means that we can sign over those commits. 08:14.000 --> 08:16.000 Which is really useful. 08:17.000 --> 08:20.000 I want to, I want to talk about one thing here, 08:20.000 --> 08:23.000 which is that we don't throw away any data. 08:23.000 --> 08:25.000 Right? So we're collecting every keystroke you make. 08:25.000 --> 08:28.000 And there's been a tool we can various tools previously already about, 08:28.000 --> 08:31.000 compress about, compacting or throwing away data. 08:31.000 --> 08:34.000 First, this is a delayed virtual choice, not to throw away data. 08:34.000 --> 08:38.000 It's, it's really useful because it means you can always look at what was different. 08:38.000 --> 08:41.000 And when you're talking about local first software and concurrent changes, 08:41.000 --> 08:43.000 being able to see what happened and what changed, 08:43.000 --> 08:45.000 so that you can disagree and change your mind, 08:45.000 --> 08:48.000 is really important and liberating. 08:48.000 --> 08:50.000 But it also has a lot of overhead. 08:50.000 --> 08:53.000 So in order to make this possible, we take this commit law on the right. 08:53.000 --> 08:57.000 And we encode it as a column of compressed format. 08:57.000 --> 09:00.000 So we get, on the, in the commit format, 09:00.000 --> 09:03.000 you get overhead of, you know, one commit hash per keystroke. 09:03.000 --> 09:05.000 Yeah, there's quite a lot of overhead there. 09:05.000 --> 09:09.000 There are actually a couple of hashes because you have to reference the parent commit as well. 09:09.000 --> 09:11.000 But once we've done this column of compression, 09:11.000 --> 09:16.000 we end up with about, a kind of a one bite overhead, 09:16.000 --> 09:20.000 a typical, typical payload. 09:20.000 --> 09:25.000 So you end up, as long as you're being smart about how you're compressing the stuff, 09:25.000 --> 09:28.000 you don't worry too much about the history size. 09:28.000 --> 09:30.000 And this is like an analogy to, to get as well. 09:30.000 --> 09:34.000 Get has, no one really worries too much about the fact that get doesn't throw away all of its, 09:34.000 --> 09:36.000 the history, or track everything. 09:36.000 --> 09:37.000 Like that's a useful feature of it. 09:37.000 --> 09:40.000 And there's a lot of stuff going on under the hood to make that possible. 09:41.000 --> 09:44.000 But I, I think it's a feature, and it's, when you talk, 09:44.000 --> 09:47.000 it's a tradeoff that's very important to think hard about. 09:47.000 --> 09:52.000 And we think that the right side of that tradeoff for the kinds of things that we're working on, is to hold all of history. 09:52.000 --> 09:54.000 And what about complex? 09:54.000 --> 09:58.000 Well, there, there was all of the client side in the sense that, 09:58.000 --> 10:02.000 we'll choose, for some, if there's two conflicting rights, 10:02.000 --> 10:05.000 we'll choose one such that everyone chooses the same one, 10:05.000 --> 10:06.000 who has the same data. 10:06.000 --> 10:09.000 But we also give you all the history in a way to resolve them differently, if you want. 10:10.000 --> 10:13.000 Yeah, other dubbed by default, and history retained. 10:13.000 --> 10:15.000 The principal here is service of dumb pipes. 10:15.000 --> 10:17.000 They're not doing anything except shipping around commits. 10:17.000 --> 10:19.000 They can't interpret your data, and they can't. 10:19.000 --> 10:21.000 And she's read it, it's just forward things. 10:21.000 --> 10:23.000 In practice, this works pretty well. 10:23.000 --> 10:26.000 We have a lot of, we use this a lot ourselves, 10:26.000 --> 10:29.000 and we have a lot of, maybe, strange qualities. 10:29.000 --> 10:33.000 Like, for example, we have, in our web applications, we often have a 10:33.000 --> 10:36.000 Sync server, which is actually a service worker, talking to another Sync server. 10:36.000 --> 10:40.000 Just because it's nice to have a homogeneous architecture, and it's fine. 10:40.000 --> 10:44.000 The main place where this becomes a problem in practice, 10:44.000 --> 10:48.000 is when you want to authenticate and authorize access to your documents. 10:48.000 --> 10:50.000 And this sort of becomes a point when most people are using, 10:50.000 --> 10:54.000 or to merge it, end up having to have a central central Sync server, 10:54.000 --> 10:57.000 that authenticates the reader rights. 10:57.000 --> 11:02.000 And so, that's why we've been working on QI, which I'm getting a hand over to, 11:02.000 --> 11:04.000 but great things. 11:05.000 --> 11:10.000 All right, QI, not the actual logo, but we thought we'd modify the auto merge 11:10.000 --> 11:13.000 logo because I want to logo too. 11:13.000 --> 11:21.000 So, the question is, what would signal for documents look like in this local first world? 11:21.000 --> 11:26.000 We need group and to end encryption and post-confirm my security. 11:26.000 --> 11:30.000 So, we have the security level where if somebody breaks in and you don't detect it, 11:30.000 --> 11:33.000 we still kick them out automatically. 11:33.000 --> 11:34.000 We need mutation control. 11:34.000 --> 11:38.000 We need to protect and prevent people that aren't authorized from editing your documents, 11:38.000 --> 11:39.000 obviously. 11:39.000 --> 11:41.000 And we need peering rules. 11:41.000 --> 11:44.000 We don't want people to be able to toss you or pull down copies of your data, 11:44.000 --> 11:45.000 even if it's encrypted. 11:45.000 --> 11:47.000 And I'll talk a little bit more about that on the next slide, 11:47.000 --> 11:50.000 but that's actually a very important property. 11:50.000 --> 11:54.000 So, all of these things actually end up being a really nice fit from, 11:54.000 --> 11:55.000 for a local first. 11:55.000 --> 11:58.000 We've been pulling ideas and techniques from different fields. 11:59.000 --> 12:06.000 But as Alex just illustrated, this is very helpful if we want to have interchangeable sync servers. 12:06.000 --> 12:09.000 So, why prevent peering? 12:09.000 --> 12:11.000 Well, we need defense and depth. 12:11.000 --> 12:16.000 So, on every node, because, you know, the money you have locally is the same as the thing running on the server. 12:16.000 --> 12:18.000 We have our data encrypted. 12:18.000 --> 12:22.000 You know, there's a little envelope there. 12:22.000 --> 12:25.000 And if you leak the keys, so by accident, 12:25.000 --> 12:30.000 you post the key for the file to get hug or on blue sky or wherever. 12:30.000 --> 12:34.000 Well, we're going to not appear with them because they're not in our, 12:34.000 --> 12:38.000 they're not authorized to actually ask for those bytes. 12:38.000 --> 12:42.000 If somebody breaks into the server and they don't have the key, 12:42.000 --> 12:47.000 you're still okay because the bytes are encrypted unless somebody looks the key. 12:47.000 --> 12:53.000 And so, this means that you can still access your own data, 12:53.000 --> 12:58.000 but it radically lowers the bar to running one of these servers. 12:58.000 --> 13:00.000 You can run it poorly. 13:00.000 --> 13:01.000 You can run it. 13:01.000 --> 13:05.000 You know, just been one up temporarily. 13:05.000 --> 13:08.000 You can switch between servers and all of that will just work. 13:08.000 --> 13:12.000 And you don't have to worry about these really tricky things like how do I seek your access to my data. 13:12.000 --> 13:14.000 It's just built in. 13:14.000 --> 13:18.000 But access control in this world happens at right time. 13:18.000 --> 13:20.000 We're doing encryption. 13:21.000 --> 13:24.000 This sets a ceiling on how secure your document can be. 13:24.000 --> 13:29.000 The choices that we make mean that we're going to impose a security model on your application. 13:29.000 --> 13:31.000 So, this is the trade-off. 13:31.000 --> 13:33.000 When you think about these things as infrastructure, 13:33.000 --> 13:38.000 is any choices that we make are going to affect all of your applications. 13:38.000 --> 13:43.000 So, just a quick rundown comparison in a traditional system. 13:43.000 --> 13:46.000 So, if you think, say, oh, off. 13:46.000 --> 13:52.000 The servers, the thing fundamentally control in this model, you are in control. 13:52.000 --> 13:57.000 In a central server, you know exactly who has access to do what right now. 13:57.000 --> 14:00.000 But because local first, you can have people being offline. 14:00.000 --> 14:07.000 Well, that might, you might have an out-of-date view and reconcile that later. 14:07.000 --> 14:09.000 Server can block access to anyone. 14:09.000 --> 14:15.000 In key hive, the off travels around with the document no matter where it lives. 14:15.000 --> 14:19.000 And you don't need a live connection at all. 14:19.000 --> 14:24.000 We can do over Bluetooth and this continues to work. 14:24.000 --> 14:28.000 So, fundamentally, you become the authority, you can switch servers, 14:28.000 --> 14:33.000 and they are completely interchangeable infrastructure. 14:33.000 --> 14:39.000 One of the components that we use to do this is called a capabilities model. 14:39.000 --> 14:44.000 This is a nice primitive for building up other things that people are more familiar with. 14:44.000 --> 14:49.000 So, the way this fundamentally works is the document itself, 14:49.000 --> 14:54.000 and all the users in the system have ideas of a public key. 14:54.000 --> 14:57.000 And we call this a delegation. 14:57.000 --> 15:05.000 And we are going to write in operations that say things like Bob can edit the documents. 15:05.000 --> 15:11.000 And sends that to, sends that between different users. 15:11.000 --> 15:16.000 And as we, you know, the document delegates this to Alice and Alice delegates to Bob, 15:16.000 --> 15:22.000 we can follow this chain back through and know without having to check any particular place. 15:22.000 --> 15:26.000 We all have a copy of all of these operations, all these certificates. 15:26.000 --> 15:31.000 We know exactly who's able to do what on this document. 15:31.000 --> 15:34.000 And then we take all of this and we sign over it, cryptographically. 15:34.000 --> 15:36.000 Everybody has their own keys. 15:36.000 --> 15:38.000 They can sign it just like how you sign your git commits. 15:38.000 --> 15:43.000 I hope. And that makes it verifiable everywhere. 15:43.000 --> 15:46.000 Out of this, you can build lots of different things. 15:46.000 --> 15:49.000 So, you can build your role-based access control. 15:49.000 --> 15:52.000 You can say, you know, Alice is a member of in-consuitions. 15:52.000 --> 15:55.000 So, he's allowed to write to these documents. 15:55.000 --> 15:57.000 These documents are in this directory. 15:57.000 --> 16:01.000 If you have access to this directory, you've access to all these other files. 16:01.000 --> 16:03.000 And you can also build other systems. 16:03.000 --> 16:06.000 People are, you know, some people really like attribute-based access control 16:06.000 --> 16:08.000 and these other systems. 16:08.000 --> 16:13.000 You can build those all up out of these simpler primitives. 16:13.000 --> 16:23.000 There is, because the know-sensual off, we have out-of-order off. 16:23.000 --> 16:28.000 So, if you do revocation, this means that we have to think both this on two timelines. 16:28.000 --> 16:32.000 We have the original set of delegations and who we're bringing into the document. 16:32.000 --> 16:35.000 And if we kick somebody out, we're basically reaching back in time 16:35.000 --> 16:39.000 and changing what they're able to, what they have access to. 16:39.000 --> 16:42.000 This means that we have to take the edits that they made on the document. 16:42.000 --> 16:44.000 So, let's say they're sort of defacing the document, 16:44.000 --> 16:46.000 or writing all kinds of horrible things into it. 16:46.000 --> 16:50.000 We can go back in time and remove those edits after the fact. 16:50.000 --> 16:54.000 This looks basically the same as they're bringing somebody in. 16:54.000 --> 17:00.000 It's, again, an operation that we sign over. 17:01.000 --> 17:04.000 So, there's no system-wide, super admin-baked-in. 17:04.000 --> 17:09.000 This is just, whoever creates the document gets access to it automatically, 17:09.000 --> 17:12.000 and by defaults, groups can have admins. 17:12.000 --> 17:16.000 If you want, they don't have to automatically. 17:16.000 --> 17:21.000 These are a concepts that are accessible in the system, but not mandatory. 17:21.000 --> 17:26.000 And authority always starts with a document creator and flows out from them. 17:26.000 --> 17:29.000 So, the grand vision. 17:29.000 --> 17:32.000 This is all infrastructure. 17:32.000 --> 17:35.000 Local first, CRDT is all of this, sync service, et cetera. 17:35.000 --> 17:37.000 There's things that we all benefit from. 17:37.000 --> 17:38.000 We all depend on. 17:38.000 --> 17:40.000 No one can take them away. 17:40.000 --> 17:43.000 And they're going to last beyond us or a single project. 17:43.000 --> 17:47.000 So, our users don't lose all of their stuff. 17:47.000 --> 17:51.000 It's not tied to any particular app, any company, 17:51.000 --> 17:55.000 any one country, or anyone host, no matter how enthusiastic that host is, 17:55.000 --> 17:57.000 in their self-hosting. 17:58.000 --> 18:00.000 It should be invisible as TCP-IP. 18:00.000 --> 18:04.000 And what we hope, isn't the future of this sort of ship directly in your OS, 18:04.000 --> 18:07.000 as just another system service. 18:07.000 --> 18:09.000 So, where are things at today? 18:09.000 --> 18:11.000 Today, auto merge. 18:11.000 --> 18:12.000 You should use it today. 18:12.000 --> 18:14.000 It's very actively maintained. 18:14.000 --> 18:15.000 It's written in Rust. 18:15.000 --> 18:18.000 It runs everywhere and has bindings in J.S. 18:18.000 --> 18:22.000 Swift, Go, and there's Python in alpha. 18:22.000 --> 18:24.000 And K-Hive available soon. 18:24.000 --> 18:26.000 TM, the code is open source. 18:26.000 --> 18:27.000 You can look at it. 18:27.000 --> 18:29.000 But it's security software. 18:29.000 --> 18:32.000 So, let us do some audits first. 18:32.000 --> 18:34.000 Thank you. 18:43.000 --> 18:45.000 Very much both of you. 18:45.000 --> 18:49.000 We are a bit in a difficult situation with time. 18:49.000 --> 18:51.000 We have one question online. 18:52.000 --> 18:56.000 Jonas asks, does auto merge keep the whole data set in RAM? 18:56.000 --> 18:59.000 If yes, how can I keep the RAM usage to load for big data sets? 18:59.000 --> 19:05.000 And have you considered a database mode where bits of data are loaded into RAM on demand? 19:05.000 --> 19:07.000 Yes, it does keep the data set in RAM. 19:07.000 --> 19:10.000 That column in our compression is pretty effective. 19:10.000 --> 19:16.000 It took a lot of work to actually be able to use the column in the compression at runtime, 19:16.000 --> 19:19.000 as well as just on disk. 19:20.000 --> 19:25.000 But RAM usage is not since that changed since we were able to do that. 19:25.000 --> 19:26.000 Too much of an issue. 19:26.000 --> 19:31.000 But we are also thinking about being able to partially load bits of the document. 19:31.000 --> 19:33.000 It's a bit further down the roadmap. 19:33.000 --> 19:36.000 Unless it's important to you and you have enough money to sponsor us to do it. 19:36.000 --> 19:38.000 But we will get there eventually. 19:38.000 --> 19:43.000 And to add on to that, a lot of people want to do things with multiple documents at once. 19:43.000 --> 19:46.000 And that we do load in just with your request. 19:47.000 --> 19:49.000 Another question? 19:49.000 --> 19:50.000 One. 19:50.000 --> 19:51.000 Two. 19:51.000 --> 19:53.000 No question, perfect. 19:53.000 --> 19:54.000 Thank you very much. 19:54.000 --> 19:55.000 Thank you again. 19:55.000 --> 19:56.000 Group. 19:56.000 --> 19:59.000 And that next one, motommage. 19:59.000 --> 20:01.000 Yes. 20:01.000 --> 20:02.000 Thank you. 20:02.000 --> 20:03.000 Good job.