WEBVTT 00:00.000 --> 00:07.000 Yeah, hello, fustum. 00:07.000 --> 00:14.000 Okay, so authenticated encryption in start system is the thing I want to talk about. 00:14.000 --> 00:18.000 I don't know if any one of you knows what authenticated encryption is. 00:18.000 --> 00:20.000 Just a quick shorthand. 00:20.000 --> 00:23.000 So I think everyone here knows what ASXTAS is. 00:23.000 --> 00:26.000 That's probably like the most common storage cipher. 00:26.000 --> 00:31.000 You know, when you have used the encrypted default that it uses ASXTAS. 00:31.000 --> 00:37.000 But, you know, from maybe some government regulation, you might hear that, you know, 00:37.000 --> 00:42.000 the usage of a authenticated encryption or something like ADC cypress like ASGCM. 00:42.000 --> 00:43.000 It's recommended, right? 00:43.000 --> 00:47.000 Like when you use something like server-side encryption in S3. 00:47.000 --> 00:50.000 For example, ASGCM is used by default. 00:50.000 --> 00:54.000 And that's just an example of an authenticated, 00:54.000 --> 00:57.000 or an ADC cypress or authenticated encryption in the system. 00:57.000 --> 00:58.000 And what essentially happens? 00:58.000 --> 01:01.000 What is the engineering challenge behind it? 01:01.000 --> 01:03.000 Why isn't everyone using it? 01:03.000 --> 01:08.000 That's essentially because we have something called the Ciphertext Expansion. 01:08.000 --> 01:13.000 So when you encrypt, let's say, four kilobytes of data with ASXTAS, you know, 01:13.000 --> 01:18.000 the encrypted standard, then you're 4K input, 4K output, or 4K be output, right? 01:18.000 --> 01:23.000 But with using a authenticated encryption, we get an additional authentication tag. 01:23.000 --> 01:27.000 You can think of it as something like an HMEC or like hash, right? 01:27.000 --> 01:31.000 So when you encrypt, you're 4K by something, and you get 4K by it, 01:31.000 --> 01:35.000 and let's say, 32 bytes of authentication tag. 01:35.000 --> 01:42.000 And when you decrypt it, you need to supply this specific authentication tag with that corresponding data 01:42.000 --> 01:44.000 to be able to decrypt it. 01:44.000 --> 01:48.000 If you don't have that, if you know, this 32 bytes gets lost on the way, 01:48.000 --> 01:50.000 then you have no way to recover your data. 01:50.000 --> 01:52.000 That's how these algorithms are designed. 01:52.000 --> 01:56.000 And the main reason why you want to use them or write, you know, 01:56.000 --> 02:02.000 some compliance people say why you should use them is because in ASXTAS, 02:02.000 --> 02:07.000 there's no kind of checking if the Ciphertext is actually valid, right? 02:07.000 --> 02:12.000 Like, if I have a Ciphertext that's encrypted, something I don't know, 02:12.000 --> 02:18.000 I flip a bit, I decrypted, and ASXTAS gives me the guarantee that the output will be garbage. 02:18.000 --> 02:23.000 You know, we'll just be some random seemingly random byte screen, right? 02:23.000 --> 02:29.000 And then kind of the system that's consuming that decrypted garbage has to somehow deal with it. 02:29.000 --> 02:33.000 And at best case, it will throw an error and be like, oh yeah, I don't know, 02:33.000 --> 02:38.000 out of order format or something, but it's not really a deterministic behavior, right? 02:38.000 --> 02:42.000 And with AD encryption, you know, if you try to decrypt, 02:42.000 --> 02:47.000 and the data, the Ciphertext system will be modified, then it will throw an error. 02:47.000 --> 02:52.000 And that's essentially it. And the nearing challenge is storing this extra bytes. 02:52.000 --> 02:58.000 So in S3 and object storage, we have this program, the problem is kind of solved. 02:58.000 --> 03:03.000 And file system encryption that says standards like FScript, they don't use it at all. 03:03.000 --> 03:08.000 Or as I mentioned before, DMcript also doesn't support it by default. 03:08.000 --> 03:12.000 There might be some user space tools that use it, but as I said, like the big, 03:12.000 --> 03:16.000 let's say kernel space encryption solutions, they don't really employ it. 03:16.000 --> 03:22.000 Except in the Linux kernel, or I think also in 3BSD. 03:22.000 --> 03:25.000 There are ways to use it, but it's always a little bit cumbersome. 03:25.000 --> 03:30.000 For example, in a Linux kernel, you can use something called the encrypt, 03:30.000 --> 03:33.000 the encrypt with DM integrity to use it. 03:33.000 --> 03:39.000 But if you use it in a cloud environment, you essentially use your thin provisioning and 03:40.000 --> 03:47.000 and resize and capabilities because it expects a set formatting that you kind of change afterwards for some reason. 03:47.000 --> 03:51.000 I think that's a implementation limitation that can be overcome. 03:51.000 --> 03:53.000 But it has yet been to overcome. 03:53.000 --> 03:57.000 So if anyone's interested in that kind of topic, how to make storage more secure, 03:57.000 --> 04:00.000 that's maybe a thing that you could look into. 04:00.000 --> 04:02.000 So I'm really looking forward into the second talk. 04:02.000 --> 04:05.000 And yeah, that's been my liking talk. 04:05.000 --> 04:08.000 All right. 04:08.000 --> 04:10.000 All right. 04:10.000 --> 04:11.000 All right. 04:11.000 --> 04:12.000 All right. 04:12.000 --> 04:13.000 All right. 04:13.000 --> 04:14.000 All right. 04:14.000 --> 04:15.000 All right. 04:15.000 --> 04:16.000 All right. 04:16.000 --> 04:17.000 All right. 04:17.000 --> 04:18.000 All right. 04:18.000 --> 04:20.000 One could say too little. 04:20.000 --> 04:21.000 All right. 04:21.000 --> 04:22.000 All right. 04:22.000 --> 04:23.000 Perfect. 04:23.000 --> 04:24.000 Good. 04:24.000 --> 04:25.000 Yeah. 04:25.000 --> 04:26.000 I do. 04:26.000 --> 04:27.000 I just put a Google Drive. 04:27.000 --> 04:28.000 I hopefully better. 04:28.000 --> 04:29.000 Yeah. 04:29.000 --> 04:30.000 I'm looking. 04:30.000 --> 04:31.000 I'm looking. 04:31.000 --> 04:32.000 Yeah. 04:33.000 --> 04:35.000 So my button is very sticky for some reason. 04:35.000 --> 04:37.000 I think it's actually in the. 04:37.000 --> 04:38.000 I just edited it. 04:38.000 --> 04:39.000 Oh, yes. 04:39.000 --> 04:40.000 Yeah. 04:40.000 --> 04:41.000 Nope. 04:41.000 --> 04:42.000 It's the wrong one. 04:42.000 --> 04:43.000 Okay. 04:43.000 --> 04:44.000 Here we are. 04:44.000 --> 04:45.000 At the bottom. 04:49.000 --> 04:50.000 All right. 04:50.000 --> 04:51.000 Okay. 04:51.000 --> 04:52.000 Hopefully. 04:52.000 --> 04:53.000 It's okay. 04:55.000 --> 04:56.000 It seems to be working. 04:56.000 --> 04:57.000 Okay. 04:57.000 --> 04:58.000 All right. 04:59.000 --> 05:01.000 I was in the center bit. 05:01.000 --> 05:02.000 Yeah. 05:02.000 --> 05:03.000 Perfect. 05:03.000 --> 05:04.000 That works. 05:04.000 --> 05:06.000 Okay. 05:06.000 --> 05:07.000 So everyone. 05:07.000 --> 05:11.000 I just wanted to give everyone a preview of what I've been working on for the last while. 05:11.000 --> 05:13.000 Or this doesn't quite show the whole thing on here. 05:13.000 --> 05:16.000 But I call this Hopnet. 05:16.000 --> 05:18.000 And it's that. 05:18.000 --> 05:21.000 I think the. 05:21.000 --> 05:22.000 It's cropped. 05:22.000 --> 05:23.000 Oh, the side. 05:23.000 --> 05:25.000 The presentation is. 05:26.000 --> 05:28.000 That's. 05:28.000 --> 05:30.000 That's an. 05:30.000 --> 05:33.000 Issues. 05:33.000 --> 05:35.000 What do we have here. 05:35.000 --> 05:37.000 It's hot. 05:37.000 --> 05:38.000 I've seen. 05:38.000 --> 05:39.000 I've seen. 05:39.000 --> 05:40.000 I've seen. 05:40.000 --> 05:41.000 I've seen. 05:41.000 --> 05:42.000 I've seen. 05:42.000 --> 05:43.000 I've seen. 05:43.000 --> 05:44.000 Okay. 05:44.000 --> 05:45.000 And we want. 05:45.000 --> 05:46.000 Probably. 05:46.000 --> 05:50.000 Who does run. 05:50.000 --> 06:00.000 Oh, sorry. 06:00.000 --> 06:05.000 You got to see this one. 06:05.000 --> 06:06.000 Okay. 06:06.000 --> 06:07.000 Thank you. 06:07.000 --> 06:08.000 Thank you. 06:08.000 --> 06:09.000 Okay. 06:09.000 --> 06:10.000 Thank you. 06:10.000 --> 06:11.000 Okay. 06:11.000 --> 06:15.000 So this is something I've been working on for a while. 06:15.000 --> 06:17.000 But I haven't previewed it. 06:17.000 --> 06:20.000 Yeah. 06:20.000 --> 06:21.000 So I call it Hopnet. 06:21.000 --> 06:26.000 And the basic idea behind this is you install it on any device and organization or group. 06:26.000 --> 06:28.000 And the device contribute storage to the shared pool. 06:28.000 --> 06:31.000 Maybe you've heard this before in distributed storage. 06:31.000 --> 06:35.000 And the key difference here is you interact with your files just like Dropbox or Google Drive. 06:35.000 --> 06:38.000 And there's intimate encryption, which is two things that are not really taken. 06:38.000 --> 06:42.000 As design considerations and a lot of other systems like this. 06:42.000 --> 06:44.000 So just to give you an example of what that looks like. 06:44.000 --> 06:48.000 We have a web server that you can use by Dropbox if you want to download the files. 06:48.000 --> 06:50.000 But also, crucially, the OS integration. 06:50.000 --> 06:57.000 So we use the Apple file provider API, which is sort of very indefinitely integrated with the operating system and materialized as files. 06:57.000 --> 07:02.000 With APFS, thin copy is without sort of you needing to think about what is on the device. 07:02.000 --> 07:04.000 This is not in course being distributed. 07:04.000 --> 07:05.000 It's very high speed as well. 07:05.000 --> 07:07.000 So you can quickly download things. 07:07.000 --> 07:10.000 It's also an Android version of this integration and an iOS version. 07:10.000 --> 07:15.000 And I'm going to be working on an FA Notified hook for extension to Linux, which I'll give you a bit later. 07:15.000 --> 07:21.000 So the overall vision is you have to load your data in one place and one device download it somewhere else. 07:21.000 --> 07:26.000 And you can just access it in your finder and whatever explorer you use depending on your operating system. 07:26.000 --> 07:27.000 Just like Dropbox. 07:27.000 --> 07:29.000 It's very, very convenient. 07:29.000 --> 07:35.000 And also programmatic access, which not currently as incompatible, but something like that eventually. 07:35.000 --> 07:38.000 And so the redundancy design for this, it's chunk to read Solomon. 07:38.000 --> 07:40.000 We have streamed uploads and downloads. 07:40.000 --> 07:42.000 And if you have used read Solomon, you know that it's kind of difficult. 07:42.000 --> 07:44.000 You need to get all if you lose the original fragments. 07:44.000 --> 07:47.000 You need to get at least the size of the file to recover things. 07:47.000 --> 07:49.000 So we split it up into chunks. 07:49.000 --> 07:52.000 The max chunks I was 14 megabytes and inside each chunk. 07:52.000 --> 07:54.000 Then split into 10 fragments. 07:54.000 --> 07:56.000 10 original fragments and 20 recovery fragments. 07:56.000 --> 07:59.000 So that's four megabytes of max recovery for fragments. 07:59.000 --> 08:00.000 If you're doing the math there. 08:00.000 --> 08:03.000 And then distribute them with each fragment index i, 08:03.000 --> 08:05.000 a place in the same node for all chunks here to n. 08:05.000 --> 08:07.000 So that means that you get the same redundancy characteristics. 08:07.000 --> 08:09.000 As you go with full file read Solomon. 08:09.000 --> 08:11.000 Which guarantees, you know, one in free. 08:11.000 --> 08:18.000 If you have a free note network value, a maximum of 20 failures with this number of fragments hot-coated. 08:18.000 --> 08:22.000 And so that enables streaming file access even if original file fragments are lost. 08:22.000 --> 08:26.000 And this is really important when you're using things like the file provider API. 08:26.000 --> 08:29.000 Because it does provide like a posics compatible API there. 08:29.000 --> 08:32.000 If you're going to terminal and you type like cap a really big file, 08:32.000 --> 08:35.000 it will just start to output it and it will just keep dumping to the terminal. 08:35.000 --> 08:38.000 As it downloads from the other devices in the network. 08:38.000 --> 08:40.000 So you get super high speed performance. 08:40.000 --> 08:43.000 If you've got like a 70 gig video in there, you can just stop playing it back immediately. 08:43.000 --> 08:46.000 And yeah, you want to need that first chunk to stream the file. 08:46.000 --> 08:49.000 So even if you lose some of the original fragments, 08:49.000 --> 08:51.000 you just occur a maximum of 14 megabytes. 08:51.000 --> 08:53.000 Time to first bite out of the system. 08:53.000 --> 08:55.000 And it also scales quite nicely. 08:55.000 --> 08:56.000 These hot-coated number of fragments. 08:56.000 --> 08:58.000 Free node network, one in free to survive. 08:58.000 --> 08:59.000 20 nodes max value. 08:59.000 --> 09:04.000 It was probably okay that hot-coated 20 recovery fragments, even large network. 09:04.000 --> 09:06.000 We've regards how this all works. 09:06.000 --> 09:08.000 Synchronization wires. 09:08.000 --> 09:11.000 It's got a two-phase Byzantine fault tolerant consensus state machine. 09:11.000 --> 09:13.000 So it's a derivative of hot stuff too. 09:13.000 --> 09:16.000 If you're familiar with distributed systems there. 09:16.000 --> 09:19.000 But it has a dynamic Byzantine fault tolerance approach. 09:19.000 --> 09:23.000 So of course the start-up problem is really complex in BFT systems, 09:23.000 --> 09:25.000 where if you only have less than say seven nodes, 09:25.000 --> 09:29.000 which is the requirement for like two-end customer recovery, 09:29.000 --> 09:31.000 you need to get that many nodes. 09:31.000 --> 09:34.000 It doesn't work very well with consumer hardware. 09:34.000 --> 09:38.000 This allows us to fall back to majority rules that we have less than seven nodes. 09:38.000 --> 09:41.000 And then you get those BFT safety guarantees above seven nodes. 09:41.000 --> 09:43.000 And it also has a dynamic validator set. 09:43.000 --> 09:46.000 You can notice what automatically votes out and vote back in. 09:46.000 --> 09:47.000 Nones that go offline. 09:47.000 --> 09:49.000 So if you have roaming hardware like laptops, 09:49.000 --> 09:50.000 really good for that. 09:50.000 --> 09:54.000 Of course, there are a lot of security considerations that we've regards to DDS 09:54.000 --> 09:58.000 and that kind of thing, which is something that is still being worked on that. 09:58.000 --> 10:02.000 And per node state, the consensus is decoupled from file operations. 10:02.000 --> 10:06.000 So basically if you upload a new file or a modification to a file, 10:06.000 --> 10:08.000 the hash gets propagated to, you know, 10:08.000 --> 10:11.000 if it's consensus system before the fragments actually finish the distribution. 10:11.000 --> 10:14.000 So that happens to be synchronously from the actual state machine progression. 10:14.000 --> 10:16.000 So it's a good for highly concurrent uses. 10:16.000 --> 10:20.000 If I upload, if I update a file and someone else hasn't yet sort of seen, 10:20.000 --> 10:22.000 or fetched the fragments of that change, 10:22.000 --> 10:24.000 they know immediately that the change has happened. 10:24.000 --> 10:26.000 And their device, when they double click it, 10:26.000 --> 10:29.000 will, you know, make the call of, you know, send calls to other nodes, 10:29.000 --> 10:32.000 APIs, to fetch the fragments from them to reconstruct the file, 10:32.000 --> 10:34.000 rather than them working with an outdated file. 10:34.000 --> 10:40.000 Each node maintains a WDB representation of the global file system state. 10:40.000 --> 10:44.000 And the consensus is basically just tracking transactions against that database. 10:44.000 --> 10:48.000 And so we've regards the encryption security architecture, 10:48.000 --> 10:52.000 file paths are encrypted with ASSIV, which gives us deterministic encryption. 10:52.000 --> 10:56.000 So at each level, you can basically use, like, a find where in this encryption level, 10:56.000 --> 10:58.000 if you want to find all the files in a path without having to do, 10:58.000 --> 11:02.000 you know, really slow, treat reversals for things to find what is in this path. 11:02.000 --> 11:06.000 And that key also is just tied to the users, 11:06.000 --> 11:08.000 ED25519 identity. 11:08.000 --> 11:10.000 So you just roam with this one thing. 11:10.000 --> 11:12.000 I've been very interested in web crypto. 11:12.000 --> 11:15.000 I've rolled out some ED25519 sort of support recently. 11:15.000 --> 11:19.000 So, you know, that has some interesting things for, like, web architecture, 11:19.000 --> 11:20.000 of decryption. 11:20.000 --> 11:22.000 They keep going, um, no. 11:22.000 --> 11:23.000 That's the rule. 11:23.000 --> 11:24.000 OK. 11:24.000 --> 11:26.000 I'm going to pause the talk next year. 11:26.000 --> 11:27.000 Yeah. 11:27.000 --> 11:28.000 Sounds good. 11:28.000 --> 11:29.000 Thank you. 11:29.000 --> 11:30.000 Thank you. 11:36.000 --> 11:37.000 All right. 11:41.000 --> 11:43.000 We have... 11:43.000 --> 11:44.000 Joe. 11:44.000 --> 11:45.000 Do we have Joe? 11:45.000 --> 11:46.000 Yeah. 11:52.000 --> 11:53.000 Of course. 11:53.000 --> 11:54.000 Of course. 12:01.000 --> 12:02.000 All right. 12:06.000 --> 12:09.000 So, does anyone here have heard about Solida? 12:09.000 --> 12:10.000 No. 12:10.000 --> 12:11.000 No. 12:11.000 --> 12:12.000 No. 12:12.000 --> 12:13.000 No. 12:13.000 --> 12:14.000 No. 12:14.000 --> 12:15.000 No. 12:15.000 --> 12:16.000 I've heard everybody. 12:16.000 --> 12:17.000 Oh, yes. 12:17.000 --> 12:20.000 Can you get the microphone for you? 12:20.000 --> 12:21.000 Oh, yes. 12:21.000 --> 12:22.000 Sure. 12:22.000 --> 12:23.000 OK. 12:23.000 --> 12:24.000 Yeah. 12:24.000 --> 12:27.000 There is a lot of name for Sol. 12:27.000 --> 12:29.000 So now, it's my turn to do some, 12:29.000 --> 12:31.000 X-Render magic. 12:31.000 --> 12:33.000 I have a script for that, Molly. 12:33.000 --> 12:36.000 Probably won't work. 12:36.000 --> 12:38.000 Uh. 12:38.000 --> 12:42.000 Oh, wow. 12:42.000 --> 12:45.000 OK. 12:45.000 --> 12:46.000 Yes. 12:46.000 --> 12:54.000 So, I'm going to present Solida as fast as I can. 12:54.000 --> 12:57.000 So, basically, Solida stands for social link data, 12:57.000 --> 13:00.000 and it's a project initiated by Tim Berners-Lee, 13:00.000 --> 13:02.000 the inventor of the web, 13:02.000 --> 13:06.000 who are like, I build this web for like, 13:06.000 --> 13:08.000 a utopia of share, 13:08.000 --> 13:10.000 a decentralized share knowledge, 13:10.000 --> 13:14.000 and why it becomes this dystopian of capitalism of surveillance. 13:14.000 --> 13:18.000 And he's like, a bit sad of what his invention has become, 13:18.000 --> 13:20.000 like, like, for understanding a little bit. 13:20.000 --> 13:24.000 So, he was like, how can we solve it at a design level? 13:24.000 --> 13:27.000 What, what when the book in the architecture of the web? 13:27.000 --> 13:31.000 Uh, and his idea is that when you use the web web app, 13:31.000 --> 13:34.000 it's always application who stores the data. 13:34.000 --> 13:36.000 And, and this is what went wrong because it, 13:36.000 --> 13:39.000 it allows the app to capitalize on data. 13:39.000 --> 13:41.000 And this is the new goal today, right? 13:41.000 --> 13:44.000 And the most, uh, richest company are based on user data. 13:44.000 --> 13:47.000 So, he's like, maybe we should allow the, 13:47.000 --> 13:49.000 the, the, the user to store the data where, 13:49.000 --> 13:51.000 where they want and to have those app that we can call, 13:51.000 --> 13:54.000 like, zero data apps that just like fetch the data, 13:54.000 --> 13:56.000 do whatever they want, 13:56.000 --> 13:59.000 and then put it back where's the user wants. 13:59.000 --> 14:00.000 So, that's the idea. 14:00.000 --> 14:03.000 Uh, it's based on W3C's standard, 14:03.000 --> 14:06.000 and it's just like a extension of web standards, 14:06.000 --> 14:09.000 like HTTP. 14:09.000 --> 14:11.000 It's based on link data. 14:11.000 --> 14:12.000 So, basically, link data, 14:12.000 --> 14:15.000 it's a way of storing data in triples, 14:15.000 --> 14:18.000 where you, uh, every, uh, 14:18.000 --> 14:20.000 item is a full URL, 14:20.000 --> 14:22.000 and you define relation between data. 14:22.000 --> 14:24.000 So, for example, if you have, uh, 14:24.000 --> 14:26.000 artist called Mona Lisa, 14:26.000 --> 14:29.000 you give it, uh, this is your subject. 14:29.000 --> 14:30.000 You give it a predicate, 14:30.000 --> 14:32.000 which is like, which, like, the artist. 14:32.000 --> 14:34.000 So, who created this, this, this, 14:35.000 --> 14:37.000 the, the, the, the art, 14:37.000 --> 14:40.000 and then the object is like Leonardo da Vinci, 14:40.000 --> 14:41.000 and it's allow you to, 14:41.000 --> 14:44.000 to have to create this massive graph of knowledge, 14:44.000 --> 14:47.000 and it's really cool to, um, 14:47.000 --> 14:50.000 it's a really cool way to store data, 14:50.000 --> 14:53.000 and it also allow to have, uh, 14:53.000 --> 14:54.000 interoperability, 14:54.000 --> 14:57.000 which is essential in the solid project. 14:59.000 --> 15:00.000 Uh, so, yeah. 15:00.000 --> 15:03.000 So, the goal is to give every user, 15:03.000 --> 15:06.000 a pod, which is a personal online data store, 15:06.000 --> 15:08.000 and you see it as a third-party database 15:08.000 --> 15:10.000 that every user have, 15:10.000 --> 15:13.000 and, and, and can connect to application. 15:13.000 --> 15:15.000 And the application will, 15:15.000 --> 15:18.000 will store the user data in a pod, uh, 15:18.000 --> 15:20.000 in a link data format. 15:20.000 --> 15:22.000 Why in a link data format? 15:22.000 --> 15:24.000 Because this allow, 15:24.000 --> 15:27.000 well, I went a little bit, uh, high energy. 15:27.000 --> 15:29.000 Uh, it allow, um, 15:29.000 --> 15:30.000 so for example, 15:30.000 --> 15:32.000 if you, like, in a solid world, 15:32.000 --> 15:34.000 if you want to switch, uh, 15:34.000 --> 15:36.000 from Gmail to Potomale, 15:36.000 --> 15:38.000 um, and, and assuming like, 15:38.000 --> 15:39.000 all user has a pod, 15:39.000 --> 15:41.000 you just, uh, 15:41.000 --> 15:43.000 remove access from Gmail 15:43.000 --> 15:45.000 to your mail folder, 15:45.000 --> 15:46.000 and you contact folder, 15:46.000 --> 15:48.000 and you allow Potomale to have access 15:48.000 --> 15:50.000 to your pods, um, 15:50.000 --> 15:51.000 to your pod, 15:51.000 --> 15:53.000 a mail and contact folder. 15:53.000 --> 15:55.000 So this is really cool, uh, 15:55.000 --> 15:56.000 because you just, 15:56.000 --> 15:57.000 handle, 15:57.000 --> 15:58.000 and then, on Potomale, 15:58.000 --> 15:59.000 you have all your contact, 15:59.000 --> 16:01.000 all your mail, you have all your data exactly the same. 16:02.000 --> 16:04.000 Because they are stored in the same place, 16:04.000 --> 16:06.000 and also because they are stored in 16:06.000 --> 16:09.000 link data, which allows this interoperability. 16:09.000 --> 16:13.000 Okay, we don't care about this, uh, 16:13.000 --> 16:14.000 uh, yeah. 16:14.000 --> 16:16.000 So how does it look? 16:16.000 --> 16:17.000 Uh, that's the workflow. 16:17.000 --> 16:18.000 So on the left, 16:18.000 --> 16:19.000 we have a, uh, 16:19.000 --> 16:22.000 that doesn't store any data, 16:22.000 --> 16:23.000 and on the right, 16:23.000 --> 16:24.000 we have a solid server, 16:24.000 --> 16:26.000 which both has the database, 16:26.000 --> 16:28.000 the user database, 16:28.000 --> 16:30.000 and the identity provider. 16:31.000 --> 16:33.000 Uh, 16:33.000 --> 16:34.000 you as a user to sign in, 16:34.000 --> 16:38.000 it gets redirected to the identity provider of the solid server. 16:38.000 --> 16:40.000 The user identify, 16:40.000 --> 16:41.000 uh, 16:41.000 --> 16:42.000 and then the app has, 16:42.000 --> 16:43.000 like, 16:43.000 --> 16:44.000 all the, 16:44.000 --> 16:45.000 the permission, 16:45.000 --> 16:48.000 it needs to fetch the data. 16:48.000 --> 16:50.000 So now we are assumes that in the, 16:50.000 --> 16:51.000 in the user pod, 16:51.000 --> 16:53.000 there is some task, 16:53.000 --> 16:55.000 and it will know with some, 16:55.000 --> 16:56.000 uh, 16:56.000 --> 16:57.000 standard, 16:57.000 --> 16:58.000 uh, 16:58.000 --> 16:59.000 like, 16:59.000 --> 17:01.000 it will know where to find the task, 17:01.000 --> 17:02.000 and it will, 17:02.000 --> 17:03.000 uh, 17:03.000 --> 17:04.000 return it in the, 17:04.000 --> 17:05.000 in the app. 17:05.000 --> 17:06.000 And, uh, 17:06.000 --> 17:07.000 yeah, 17:07.000 --> 17:08.000 I think the, 17:08.000 --> 17:09.000 I, I just, 17:09.000 --> 17:10.000 build this, 17:10.000 --> 17:11.000 uh, 17:11.000 --> 17:12.000 last minute. 17:12.000 --> 17:13.000 So, uh, 17:13.000 --> 17:15.000 this is a presentation for something else. 17:15.000 --> 17:17.000 I think I'm done with my points. 17:17.000 --> 17:18.000 Uh, 17:18.000 --> 17:19.000 if I have a few minutes remaining, 17:19.000 --> 17:20.000 I don't know what to talk about. 17:20.000 --> 17:21.000 30 seconds. 17:21.000 --> 17:22.000 30 seconds. 17:22.000 --> 17:23.000 All right. 17:23.000 --> 17:24.000 Well, uh, 17:24.000 --> 17:25.000 thank you for, uh, 17:25.000 --> 17:26.000 for listening, 17:26.000 --> 17:28.000 if you are excited about this, 17:28.000 --> 17:29.000 as much as I am, 17:29.000 --> 17:31.000 because it's really cool as a web developer 17:31.000 --> 17:32.000 to program with solid, 17:32.000 --> 17:34.000 because basically the user come with, 17:34.000 --> 17:35.000 with, with a, 17:35.000 --> 17:36.000 with a full, 17:36.000 --> 17:38.000 like it's like an abstraction of a, 17:38.000 --> 17:39.000 of a back, 17:39.000 --> 17:40.000 and you can see it, right? 17:40.000 --> 17:41.000 So you just have to build a front and up, 17:41.000 --> 17:43.000 and you imagine that the user already, 17:43.000 --> 17:44.000 you already have authentication, 17:44.000 --> 17:45.000 and data storage. 17:45.000 --> 17:46.000 So, 17:46.000 --> 17:47.000 it, 17:47.000 --> 17:48.000 as a web developer, 17:48.000 --> 17:49.000 I think it's super excited to, 17:49.000 --> 17:50.000 to have a web where we, 17:50.000 --> 17:51.000 we can, 17:51.000 --> 17:52.000 we can have that, 17:52.000 --> 17:53.000 and, 17:53.000 --> 17:54.000 all right. 17:54.000 --> 17:55.000 Thank you for listening. 17:55.000 --> 17:57.000 All right. 17:57.000 --> 18:10.000 Yeah. 18:10.000 --> 18:16.000 Did you put yourself in the document, 18:16.000 --> 18:17.000 I think? 18:17.000 --> 18:18.000 Oh, okay. 18:18.000 --> 18:19.000 Sorry. 18:19.000 --> 18:20.000 Okay. 18:20.000 --> 18:23.000 So then, 18:24.000 --> 18:25.000 the size of the web developer? 18:25.000 --> 18:26.000 Demo? 18:26.000 --> 18:27.000 Demo? 18:27.000 --> 18:28.000 Demo? 18:28.000 --> 18:30.000 Demo? 18:30.000 --> 18:32.000 I think that's not really lighting. 18:32.000 --> 18:34.000 All right. 18:34.000 --> 18:35.000 All right then. 18:35.000 --> 18:37.000 Hopefully this goes quite quick. 18:37.000 --> 18:39.000 But, 18:39.000 --> 18:40.000 hello. 18:40.000 --> 18:41.000 Hello. 18:41.000 --> 18:42.000 Hello. 18:42.000 --> 18:44.000 I'm glad you could hear me. 18:44.000 --> 18:45.000 So, 18:45.000 --> 18:52.000 this is based on the talk that I have given a couple of times before. 18:52.000 --> 19:01.080 the time is before. Hopefully this works out. Hello, my name is Gwendoz. I work for the University 19:01.080 --> 19:08.760 of Cambridge and I do Luster. Luster, it's... Oh, oh, Cracky. Let me grab my laptop. 19:08.760 --> 19:13.760 Huh? I'll see if it'll be starting to fall right now. 19:13.760 --> 19:15.760 No. 19:15.760 --> 19:17.760 Oh, I did it. 19:17.760 --> 19:23.760 Set this wax. 19:23.760 --> 19:30.760 Okay. 19:30.760 --> 19:34.760 I'm parking. 19:34.760 --> 19:43.760 That should work, maybe. 19:43.760 --> 19:50.760 Is that going to work? I don't know. Let's see, shall we? 19:50.760 --> 20:01.760 It's certainly maybe I can do the thing. 20:01.760 --> 20:05.760 Oh, that's annoying. 20:05.760 --> 20:15.760 That's encouraging. Excellent. Come on. Come on. 20:16.760 --> 20:19.760 What's green? Can you do it? 20:19.760 --> 20:25.760 Go on. Stupid laptop. No. 20:25.760 --> 20:28.760 Oh, bloody thing. 20:28.760 --> 20:30.760 I hate this machine. 20:30.760 --> 20:33.760 It is. 20:33.760 --> 20:37.760 I need to get out of my solid surface otherwise the mouse is quite properly. 20:37.760 --> 20:40.760 Come on. Come on. 20:40.760 --> 20:44.760 You know, I'm time now. 20:44.760 --> 20:47.760 That's what I'm going to say if I can get it to. 20:47.760 --> 20:50.760 No. If I've all screened, it doesn't work. 20:50.760 --> 20:54.760 It's probably the zero zero on that screen. 20:54.760 --> 20:56.760 Otherwise it thinks it's still on the other. 20:56.760 --> 20:59.760 The top left corner. 20:59.760 --> 21:01.760 What are you talking about? 21:01.760 --> 21:05.760 Try to top left corner. The window needs to be on the external screen. 21:05.760 --> 21:06.760 Oh, I see. Yes. 21:06.760 --> 21:09.760 So it's the top of the way to get on the screen. 21:09.760 --> 21:10.760 No, I saw it. 21:10.760 --> 21:11.760 Not that. 21:11.760 --> 21:14.760 Because it takes a moment for a reason. 21:14.760 --> 21:17.760 It's then you don't have to deal with that. 21:17.760 --> 21:19.760 Yeah, tell me about it. 21:19.760 --> 21:21.760 This is so awful. 21:21.760 --> 21:23.760 I really hate this machine. 21:23.760 --> 21:27.760 I'm hoping I can successfully manage to get a nice one soon. 21:27.760 --> 21:31.760 Otherwise, you can press the windows button to shift with it. 21:31.760 --> 21:33.760 And then let the right. 21:33.760 --> 21:35.760 We have those. 21:35.760 --> 21:37.760 Nice try. 21:38.760 --> 21:40.760 Oh, this is annoying. 21:40.760 --> 21:43.760 So I can get this work again. 21:43.760 --> 21:45.760 How? How annoying. 21:45.760 --> 21:47.760 I do indeed. 21:49.760 --> 21:51.760 That you're so so irritating. 21:51.760 --> 21:53.760 I really don't read them to us. 21:53.760 --> 21:55.760 I need to get a replacement laptop. 21:55.760 --> 21:58.760 Yes, of course. 21:58.760 --> 21:59.760 Yes, of course. 21:59.760 --> 22:01.760 So fine. 22:01.760 --> 22:03.760 Fine, fine, fine, fine, fine. 22:03.760 --> 22:05.760 So hello. 22:05.760 --> 22:06.760 Hello, I do lost it. 22:07.760 --> 22:10.760 Luster is a also soft and fine storage. 22:10.760 --> 22:12.760 But Luster is built quite differently. 22:12.760 --> 22:16.760 It has very little away of software defined resilience. 22:16.760 --> 22:22.760 It primarily works on having all of that resilience put on to its hardware level, 22:22.760 --> 22:26.760 which is great if you want really serious performance. 22:26.760 --> 22:29.760 I have some really serious performance numbers. 22:29.760 --> 22:30.760 Can't show them to you. 22:30.760 --> 22:31.760 It's going to get the slides to work. 22:31.760 --> 22:33.760 Because I might have to open that great. 22:33.760 --> 22:43.760 So I'm I'm part of being administering a door, which is one of the UK's super computers. 22:43.760 --> 22:48.760 We've been working on the big Luster file system for it. 22:48.760 --> 22:52.760 So we can provide storage to AI workloads. 22:52.760 --> 22:57.760 AI workloads need lots of performance and very low latency. 22:57.760 --> 23:00.760 And basically as much as you can throw as it. 23:00.760 --> 23:02.760 How do we do this? 23:02.760 --> 23:08.760 Well, we use a large quantity of NDMAs to be able to provide the actual base storage layer. 23:08.760 --> 23:13.760 But of course most NDMAs that about these days have no resilience at all. 23:13.760 --> 23:18.760 So combination of software that doesn't provide any resilience and hardware that doesn't provide any resilience. 23:18.760 --> 23:20.760 It's kind of a bad time. 23:20.760 --> 23:24.760 So we've put some extra software on top of it to be able to. 23:24.760 --> 23:35.760 To provide that storage in a way that is able to deal with the blast radius of users to make sure that it's suitably sort of handled to them. 23:35.760 --> 23:38.760 So we we use slum because we I'm HPC. 23:38.760 --> 23:44.760 So slums are scheduler and as a scheduler that means we can control where I use this. 23:44.760 --> 23:51.760 But the data and we make sure that I the usage of our data relates to how much they can lose. 23:51.760 --> 23:58.760 So we have a carefully crafted construction to make sure that it's actually capable of handling the lack of resilience. 23:58.760 --> 24:03.760 And that's yeah that there's something that we can translate to our users. 24:03.760 --> 24:10.760 What's it's kind of difficult because everyone sees the posit's files system and thinks that every posit's files system is going to act the same way. 24:10.760 --> 24:13.760 And they don't they very much do not, which is kind of fun. 24:13.760 --> 24:16.760 And really difficult to describe to users. 24:17.760 --> 24:20.760 But doesn't go fast yes it goes fast. 24:20.760 --> 24:23.760 If you treat it the right way around. 24:23.760 --> 24:26.760 The fundamental problem is. 24:26.760 --> 24:27.760 The. 24:27.760 --> 24:28.760 Correct you. 24:28.760 --> 24:30.760 It's in my slides away. 24:30.760 --> 24:32.760 If you do not. 24:32.760 --> 24:35.760 If you run through the page cache. 24:35.760 --> 24:38.760 You we actually find winning it about 20% performance. 24:38.760 --> 24:45.760 So we have potentially 100 gigabytes per second on these machines and that's per note. 24:45.760 --> 24:50.760 If we don't if we actually if we don't use O direct so we use the page cache we only get about 20. 24:50.760 --> 24:54.760 But we can get it to about 85 gigabytes per second. 24:54.760 --> 24:57.760 If we turn off the page cache and use O direct instead. 24:57.760 --> 25:02.760 And it turns out then in last 2016 there's a thing called hybrid I owe that does that automatically for you. 25:02.760 --> 25:06.760 So you don't even have to get the users to understand what O direct even means. 25:06.760 --> 25:07.760 This isn't that nice. 25:07.760 --> 25:10.760 So in a nutshell without my slides. 25:10.760 --> 25:14.760 That's pretty much the subject that had isn't that nice. 25:14.760 --> 25:23.760 All right. 25:23.760 --> 25:28.760 Anybody else interested in coming up here for five minutes. 25:28.760 --> 25:29.760 I guess not. 25:29.760 --> 25:30.760 Well then thanks everybody. 25:30.760 --> 25:32.760 Hope to see you next year.