WEBVTT 00:00.000 --> 00:15.480 This is coming to an end, this is the problem, and then just another one, so some other 00:15.480 --> 00:19.980 announcements for me. In case you don't have enough, you're going to get me a time-powered 00:19.980 --> 00:27.660 and a bit more than a month's time, it will be a pilot, that's the reason why we're 00:27.660 --> 00:35.580 keeping the matrix between the pilot, it's the first eight years, and I just got a check 00:35.580 --> 00:40.500 a few days ago, there will be a matrix instead, so if you want to purchase a big 00:40.500 --> 00:45.460 there and just get to touch with me or just give me, we will be there and try to open 00:45.700 --> 00:57.540 something more matrix for related, and now the stage goes for Kevin, you will talk us through 00:57.540 --> 01:04.340 Rob Briggs, is it Rob Briggs? Yeah, Rob Briggs. Yeah, give him a warm welcome and let's learn 01:04.340 --> 01:14.900 about Rob Briggs as a future of last time, thank you all. Thanks very much, so yeah, I'll introduce 01:14.900 --> 01:18.900 myself first since I'm relatively new to the community, I started using matrix only about a year 01:18.900 --> 01:24.820 ago, and we've been working on the parent project of this for just about a year, so it's 01:24.820 --> 01:31.460 everything to do with rust-apped across multiple platforms, so my background is in academia, so 01:31.460 --> 01:36.580 I'm relatively new, in fact this is my first fossil, so I'm happy to be here. But yeah, thanks 01:36.580 --> 01:41.220 thanks for sticking around to the afternoon, so what is Rob Briggs? Rob Briggs is a new matrix 01:42.020 --> 01:46.980 we hope to make it a lot more than just matrix, but that's kind of the beginning of the story. 01:47.700 --> 01:52.580 So these are some old screenshots I'm purposefully keeping the old ones here, so I'll reveal the new ones 01:52.580 --> 01:58.660 coming up soon, but basically we have a single code base that runs pretty seamlessly across all the 01:58.660 --> 02:06.020 major platforms, that's Lenin's Windows, Mac OS, Android, iOS, and Web, although it doesn't yet run 02:06.020 --> 02:10.100 on Web because I didn't even know that the matrix has to be a supported Web, I thought it was still 02:10.100 --> 02:16.180 broken, until I saw T-Most talk this afternoon, so I'm very excited about that, but yeah, that's kind 02:16.180 --> 02:22.020 of the elevator pitch, so I do need to give some background information about what Rob Briggs is 02:22.020 --> 02:27.380 and what the project overall is, so about a year, maybe a year and a quarter ago, we started 02:27.380 --> 02:34.500 project Robius, which is kind of a large community endeavor to make multi-platform, active, 02:34.500 --> 02:39.860 experience fully and rust happen, and to make it happen easily. So the idea is that developers 02:39.860 --> 02:44.260 can do things like leverage the features of rust that everyone's familiar with and that we all like, 02:44.900 --> 02:50.980 we don't have to do with multiple languages or different environments, it's just all rust all the 02:50.980 --> 02:56.340 time, and you never have to write a single line of platform specific code, so yeah, come on. 02:57.540 --> 03:02.660 And then the secondary goal here was to make mobile systems, iOS and Android namely kind of a 03:02.740 --> 03:07.060 first class concern and a first class citizen within the Rust community, because historically, 03:07.060 --> 03:12.180 it hasn't really been that targeted. So that's kind of a little bit of the parent project here. 03:14.180 --> 03:19.940 Like matrix, Robius is fully open source, decentralized and community driven, we have a bunch of 03:19.940 --> 03:23.700 different independent collaborators, some of who are funded by future ways, some of who are 03:23.700 --> 03:30.740 funded independently, and some of who are just open source contributors at large across the whole 03:30.820 --> 03:36.820 globe, and everything is written in Rust. So you may be asking if you're familiar with some of 03:36.820 --> 03:41.860 the Rust community's long-standing GUI efforts, like why do we need Robius, right? There's already 03:41.860 --> 03:47.300 a lot of great Rust UI toolkits, things like dioxys was already mentioned, there's things like 03:47.300 --> 03:53.620 Igui and Iist, Laptos, Torian, and Makedhead, which we're using, and then the Lyme Banner crew has their own 03:54.820 --> 03:59.780 framework called Zylam, and a bunch of others, packs is not on here, but the thing is there's a lot 03:59.780 --> 04:07.620 more development and application, as many of you will know than just drawing a GUI interface, right? 04:08.340 --> 04:14.020 So traditionally, a lot of Rust apps, like signal or something, have been more about the other 04:14.020 --> 04:19.620 code, and less about the Rust code, where you have a lot of different platform specific or language 04:19.620 --> 04:24.340 specific wrappers around a single core of Rust. So this is definitely not that, this is the 04:24.420 --> 04:28.900 inverse, and it's almost also the inverse of what T-mo showed, which I'll get to later in 04:28.900 --> 04:34.420 his talk about with assembly. So then why robrics? Why do we need another matrix client? 04:34.420 --> 04:38.660 Well, I don't think that we've done this yesterday, do we need another matrix client, but we've 04:38.660 --> 04:44.180 done it anyway. The original motivation behind this was that we needed some kind of key or killer 04:44.180 --> 04:48.660 app to drive the development of all these different robius components, right? So all the platform 04:48.660 --> 04:53.860 integration, build tooling, all that stuff that the GUI's don't typically handle in the Rust space. 04:55.300 --> 04:59.460 So I was scratching my brains again, you know, what kind of thing is highly demanding, 04:59.460 --> 05:05.460 specifically for UI and for platform abstractions, and we settled on a modern chat client, right? 05:05.460 --> 05:09.460 So as some of the other presenters have said today, there's a lot of additional features that 05:09.460 --> 05:16.100 chat has come to encompass over the last 10, 20 years. So it is really quite demanding of the platform. 05:16.100 --> 05:20.020 So these are just, you know, a small list of some of the things that you need to support. 05:20.980 --> 05:25.300 All right, and then you may be also wondering why do we pick matrix? Well, I think as I already 05:25.300 --> 05:29.700 alluded to it, shares our views, shares our values very nicely, open source decentralized community 05:29.700 --> 05:35.460 driven, and as a bonus, it seems like a lot of the matrix ecosystem is moving towards Rust or at least 05:35.460 --> 05:40.180 focusing on it in a future-looking way. So we're also doing that. I'm very excited to see all the 05:40.180 --> 05:48.420 Rust to use here because I've been a Rust contributor for many years now. So then, oh, sorry. 05:49.380 --> 05:53.460 So then, once we have that, once we settled on writing a matrix client with thought, you know, 05:53.460 --> 05:57.620 okay, I've written this client, it's pretty decent. There's still a long way to go, as you'll see, 05:57.620 --> 06:02.580 we're not by no means complete. But looking forward, you know, what else could we do? I think we can go further, 06:02.580 --> 06:08.100 right? Could we make a more unique client for power users or productivity sake? And by that, 06:08.100 --> 06:14.100 I mean, something that I would like to see. Can we do more things with the application, 06:14.100 --> 06:18.660 rather than just a matrix client, perhaps make it a central hub for a bunch of different 06:18.660 --> 06:24.660 federated services? With focus on the needs for the open source developer community, like myself, 06:24.660 --> 06:29.380 again, this is mostly about what I want. And then, you know, combine a bunch of different 06:29.380 --> 06:35.540 other federated services and things that open source communities use and sort of a unique way. 06:35.540 --> 06:41.220 So I'll talk about that later. The idea here is if we are able to create a very nice app, 06:41.220 --> 06:47.380 we can make a stronger case for Rust app dev and then also a strong case for matrix being the core of all of this. 06:48.980 --> 06:54.900 Okay, so just a little bit of boilerplate still. Let's talk about the goals of project rubius. 06:54.900 --> 06:59.860 So our main goal is to create a reference design, sort of a full system stack here for all the 06:59.860 --> 07:05.140 different components that you would need to create apps across multiple platforms purely and Rust. 07:05.140 --> 07:09.220 Right? So the UI, just the orange part, that's kind of everything that we don't deal with. 07:09.220 --> 07:13.780 I do, although I do contribute significantly to UI frameworks, like makepad and diaxis. 07:13.780 --> 07:18.180 I would be, you know, everything else you see here, primarily in purple, but also in red. 07:18.180 --> 07:23.700 So I don't need to get into this at all have time, but this is kind of what the current 07:23.700 --> 07:28.020 architecture of the rubrics app looks like. It's the same sort of diagram just a bunch of 07:28.020 --> 07:33.940 different details filled in. And basically, this is just a show that through developing rubrics, 07:34.020 --> 07:40.740 we have allowed that to guide the development of project rubius components and also of the UI toolkits, 07:40.740 --> 07:45.540 like makepad. We've had quite a lot of features there. So doing this has forced us to 07:45.540 --> 07:51.140 dog food the components and kind of an interesting and barely digestible manner in some cases. 07:52.100 --> 07:58.900 And we have made a lot of new contributions to, I think, the Rust UI space and the Rust app dev space in general. 07:59.860 --> 08:04.500 So again, I don't really want to bore you with the details here, but this is kind of our road map 08:04.500 --> 08:10.260 for the project. So we're just at the end of stage one here, which was basically to publish an app 08:10.260 --> 08:15.460 with all the basic fundamental matrix client features that you would expect. So messaging login, 08:15.460 --> 08:22.580 app resistance, and encryption. And then kind of while doing that, flush out the rest of the 08:22.580 --> 08:28.500 ecosystem that we need to make this possible. In stage two, we plan to add a little bit more 08:28.500 --> 08:35.860 functionality, perhaps integrating some local AI toolkits, AI tools, with an LLM runtime that was 08:35.860 --> 08:41.540 one of our other flagship app projects under the Rubius organization. And then have some additional 08:41.540 --> 08:47.540 things, which I'll show off in a demo shortly. So we hope to finish that thing by around the fall 08:47.620 --> 08:54.100 of this here. And then the future looking stage three is the more of the combination of different 08:54.100 --> 08:59.860 services here. And I'll talk about this a little bit if I have time. I'm not sure. I think I made 08:59.860 --> 09:07.540 my presentation too long. So in stage one, so far we've pretty much finished all the basics here. 09:07.540 --> 09:14.100 The only thing I didn't get a chance to do before this presentation was to implement editing message 09:14.100 --> 09:19.300 support. But we have all the the major stuff that you would expect. So you can use it. And I 09:19.300 --> 09:24.180 have been daily driving robots for about three or so months. Doesn't support a lot of stuff that 09:24.180 --> 09:29.380 you would still expect. Like, you can't join a room yet. So that stuff doesn't support notifications, 09:29.380 --> 09:34.180 which is my other, I think, big blocker. But in order to do that, we have to actually implement 09:34.180 --> 09:40.020 all the platform notifications for all the different platforms. So we have published some pre-alvivations. 09:40.660 --> 09:46.980 I just published a second pre-alpha. And I would like to emphasize pre a lot. So if you try this out, 09:46.980 --> 09:50.980 which I wouldn't encourage you to, and you hit some bugs, know that we are fixing a lot of things, 09:50.980 --> 09:57.860 mostly at the platform layer on a daily basis. And so this required us to kind of develop a lot of 09:57.860 --> 10:02.980 the build tooling for releasing code signing on macOS and Apple, notarizing and packaging up all 10:02.980 --> 10:08.100 these things into an app bundle, which is kind of annoying if you're not using the platform 10:08.100 --> 10:14.100 native build tool chain and language, right? So to do this in Russ is actually a pretty big hurdle to 10:14.100 --> 10:21.780 overcome. Thanks. And then we also spent a long time kind of establishing a nice little framework 10:21.780 --> 10:28.180 within the app, which I want to then abstract away and allow other folks to use it to, for hitting 10:28.180 --> 10:32.980 high performance metrics and efficiency metrics, despite the inherent asynchronous and the 10:32.980 --> 10:39.060 inherent heavy concurrency of something like a client. And the key, which I'll particularly say is 10:39.060 --> 10:42.500 to do nothing on the main third, and I really mean that. So if I have time, I can go into that. 10:43.140 --> 10:47.460 But basically, we don't ever make a single matrix call on the main thread, and everything is done 10:48.260 --> 10:52.020 purely on the back side, because on the back end, because there is absolutely no asynchronous 10:52.740 --> 10:59.300 support on the UI main thread in Macpad, which is our UI toolkit. So yeah, just just to show another 10:59.300 --> 11:03.540 thing, we do have complete platform support from the very beginning. So that was kind of the goal. 11:04.980 --> 11:09.700 And then we're adding, as we add more features, we ensure that we are only doing it once we have 11:09.700 --> 11:15.060 all of the platform support. So there's a slide later on that shows more detail about the platforms, 11:15.060 --> 11:18.900 but this is kind of just an overview. And then these are the, this is our future tracker, a screen 11:18.900 --> 11:23.140 shot that I took. I think a couple of days ago showing that, yes indeed, we have made pretty decent 11:23.140 --> 11:30.260 progress, and we're ready for daily usage. So I mentioned a big part of Project Robias, 11:30.260 --> 11:34.660 which has been driven by Roeberg's The Matrix client, is to develop all these platform 11:34.660 --> 11:39.940 abstractions. I'm not going to go into all of these, but over the last roughly a year, 11:39.940 --> 11:43.700 this is where we're at now. So greenest things that are largely complete, orange, 11:43.700 --> 11:49.460 things that have begun, or are partially complete, but not really ready for production use. 11:50.340 --> 11:54.580 So you can see something like camera support. There's a reason we don't support QR-based 11:54.580 --> 11:58.900 login yet, because I don't have the ability to view a camera on all of the different platforms 11:58.900 --> 12:05.300 in our appative ecosystem. So yeah, that's where we are. Okay, that was a lot of kind of boring 12:05.300 --> 12:12.420 boilerplate stuff. Let's get to a demo. All right, so I'll start off with Android, because this thing 12:12.420 --> 12:18.900 absolutely destroys my computer. The similar, I don't know why it's so blurry. Okay, I think that's 12:18.900 --> 12:28.100 an issue with the, okay, it's fine on my screen. Oh yeah, okay, can't tab. Oh, we also don't support 12:28.100 --> 12:35.940 emoji working on that. That's a UI toolkit issue. Did I miss type my path? Okay, now we're good. 12:36.980 --> 12:42.020 Yeah, we are using the native simplified sliding sync, so I'm happy with that. Okay, this one is 12:42.020 --> 12:46.660 good, so maybe it's just an issue with Android. Okay. Anyways, yeah, you know, you get everything 12:46.740 --> 12:52.420 that you expect. This is iOS. Nothing to particularly, we're here. I didn't verify this session, 12:52.420 --> 12:57.540 so we haven't some kind of errors here. Yeah, I mean, you get rich text formatting, which we 12:57.540 --> 13:03.220 spent a while implementing. Didn't have that. You get, okay, that's not wanted to load. 13:05.780 --> 13:13.700 Oh, there we go. Definitely pre-alpha. So on desktop, it's a lot, I think it's a lot, okay, thank you. 13:14.260 --> 13:19.780 It's a lot more stable. So here is the macOS version. You can see that opening about maybe 200 13:19.780 --> 13:25.140 milliseconds is incredibly fast. So for that, that's basically what we've earned by, you know, 13:25.140 --> 13:28.740 doing our due diligence, writing everything from scratch and rust, making sure we don't have 13:28.740 --> 13:33.780 any garbage collection, we don't have any weird memory safety errors, and we don't, we don't do 13:33.780 --> 13:39.860 anything on the main thread. So one thing that always bothered me with a lot of clients, and this is 13:39.860 --> 13:45.940 not to, you know, shit talk anyone here. But there's a lot of, like, I think, wasted white space. 13:45.940 --> 13:50.820 Right, so my entire life runs on discord, unfortunately, because it seems like a lot of open source 13:50.820 --> 13:54.980 communities use that. I used it for my open source projects as well. One thing that I never 13:54.980 --> 14:00.260 liked about discord, and it's seemingly a lot of other clients is that you can't use the whole 14:00.260 --> 14:04.500 width of your screen. So this screen is not very wide, but if you have 49 and ultra-wide screen, 14:04.580 --> 14:11.220 that's not the case. So we're able to, we're able to have sort of a multi-pain 14:11.780 --> 14:17.460 dockable tab review here, where you can basically emulate kind of what you'd get from an IDE, 14:17.460 --> 14:25.540 and the idea is as we add more widgets. Oh, thanks. I'll take it. I'll take it. I will take it. 14:25.540 --> 14:32.900 So as you add more widgets, and more features, they would continue to be dockable tabs, 14:32.900 --> 14:38.260 just like this. So, yeah, I mean, here it is. You know, generally, okay. I've got some white space 14:38.260 --> 14:43.860 issues there, but that's all right. Okay, thanks. And yeah, I would also like to highlight that 14:43.860 --> 14:51.140 it. It's really quite fast. So I've been easily able to hit 144 FPS on my other screen that supports 14:51.140 --> 14:55.540 that I don't think here we're going to get that because it's probably kept to 60, but hopefully 14:55.540 --> 15:01.220 it's showing off that it's quite responsive. So again, this is due to the the massive amount of 15:01.300 --> 15:06.740 work that we put into the UI toolkit and the platform of fractions underneath. So just to give 15:06.740 --> 15:12.980 an example, I mean, we do have generally support for locations. So here I'll say, hi there. 15:12.980 --> 15:19.460 I'm going to share my location. And let's see if it works. Okay. I don't know what that is, but we'll 15:19.460 --> 15:26.260 find out. So hopefully you guys can see that. And then, you know, we're able to show all these 15:26.260 --> 15:33.300 other nice little widgets here. I don't know. So yeah, if there are any other questions or any 15:33.300 --> 15:37.140 other things you'd like to see, I'm happy to show this off later. You can also install it and try it 15:37.140 --> 15:41.700 out. Not everything is perfect across every platform, but that's sort of just growing pains. 15:41.700 --> 15:47.060 But that, yeah, that's kind of the, I don't know, two second, two minute demo of what's going on 15:47.060 --> 15:54.020 here. So yeah, we have with these nice little table UI. Okay, I think that's good enough for the demo. 15:54.020 --> 16:04.500 Let's go back to the talk. Okay. Great. So as you saw, we have overcome quite a few implementation 16:04.500 --> 16:09.140 challenges to get to that point just to have things basically working. There were a lot of practical 16:09.140 --> 16:14.500 like unexciting UI features that many GUI toolkits don't really focus on, you know, like being able 16:14.500 --> 16:18.980 to show a context menu. Just two weeks ago, I had to re-implement all of our platform of 16:18.980 --> 16:23.300 instruction code, so we could actually differentiate between different mouse buttons, right? 16:23.300 --> 16:27.540 Didn't have that before. So there's a lot of practical, kind of business logic oriented stuff 16:27.540 --> 16:32.660 that we've had to do. One of the things I also mentioned was Rich Text Formatting, so we took 16:32.660 --> 16:38.260 myself and the developer of MakePad Rickerrins took a couple of weeks to write an HTML 16:38.260 --> 16:45.140 parser and then have it render in the MakePad native widget format. So that's what we're able 16:45.140 --> 16:52.580 to get super fast Rich Text Formatting, like hopefully you agree that you saw. Other things 16:52.580 --> 16:58.100 that I've most have been working on are exposing and extracting all these platforms, specific APIs 16:58.100 --> 17:02.420 and OS services, right? So you sell the location one, there's a bunch of others, I've showed 17:02.420 --> 17:07.460 some of those for biometric authentication. So I do plan to shortly add a future for something 17:07.460 --> 17:11.860 like, you know, Mark in a room is private, so you can hide a bit behind a fingerprint or something. 17:12.740 --> 17:17.300 And the only way we can do that is by implementing all of these different platform APIs and 17:17.300 --> 17:21.300 abstracting them. So the rest community I think is pretty good. There's a good amount of stuff in 17:21.300 --> 17:26.340 the rest ecosystem that we've been able to reuse or contribute to. One example is like keychain 17:26.340 --> 17:31.060 and secret storage, so you can take your session key that you get from the Matrix SDK and store it 17:31.060 --> 17:36.580 and if you want to secure storage facility provided by the underlying OS and we need to make that 17:36.580 --> 17:44.340 work across all the five platforms. I mentioned some of the build, multi-step build issues with 17:44.340 --> 17:51.460 dealing with packaging and combining cargo and non-cargo build procedures. All of these things, 17:51.460 --> 17:58.340 I think I'll skip some of the details. And then of course, I think like many rest developers 17:58.340 --> 18:04.820 are main goal is high performance in the face of concurrency. So I alluded to this previously, 18:04.900 --> 18:09.620 do nothing on the main UI thread and I really mean that. So using the Matrix SDK, there's a lot of 18:09.620 --> 18:14.580 things that are async. We explicitly made the choice within MakePad and within our overall 18:14.580 --> 18:21.140 development toolkit. We do support async and offer async APIs for all those platform abstraction 18:21.140 --> 18:27.140 feature crates, but I don't use them generally because I don't think it's necessary and I think 18:27.140 --> 18:31.300 it actually hurts a little bit more than it helps. So if you look at something like Flutter, you can 18:31.300 --> 18:36.420 do asynchronous workloads on the main UI thread and I think they call them like micro-tests. 18:36.420 --> 18:41.780 I forget the exact no-one clature. But if you're not careful, you can actually cause frame 18:41.780 --> 18:47.300 stutters and other things. So we just made the conscious decision to ban that right up at the top. 18:47.300 --> 18:53.140 So everything is routed through the sort of concurrency management framework here, which I don't 18:53.140 --> 18:57.380 think I had a lot of time to go into. But effectively, there's three classes of MakePad 18:57.380 --> 19:02.020 here. It's an concurrency context. One is the UI main thread, which has to do some things 19:02.020 --> 19:06.740 and, fortunately, like Mac OS and some other Apple platforms and I think some others require 19:06.740 --> 19:11.860 certain things to happen on the main thread, which is really annoying. But any time we call 19:11.860 --> 19:16.020 an SDK function because most of them are async, but even the ones that aren't, I've noticed 19:16.020 --> 19:19.620 in digging around in the implementation a lot of them do acquire internal locks, which is 19:19.620 --> 19:25.220 something I do not want to allow in the main UI thread. So we always call out to some sort of 19:25.220 --> 19:29.860 async runtime async thread pool in the background and make sure that we're not ever waiting 19:29.860 --> 19:34.660 for those things on the UI thread. There's a lot of other details. We make copious usage of things 19:34.660 --> 19:40.820 like thread local caches to do things in a lock-free manner that the UI thread can access and hopefully 19:40.820 --> 19:44.420 you know, never be get bogged down or never have hiccups. We're working on moving literally 19:44.420 --> 19:49.700 everything off the main thread, including things like image decoding. That's currently not there, 19:50.420 --> 19:55.060 but it's still fast enough, but we can always go faster. And then we have a bunch of other 19:55.060 --> 19:59.220 techniques that I don't really have time to get into. I only have five minutes. Okay, geez. 20:00.340 --> 20:06.020 So in terms of platform support, this is what's out there currently. I'm excited to support web, 20:06.020 --> 20:11.220 make pad also has native support for web, and most of the platform abstraction 20:11.220 --> 20:15.220 grace that we've implemented also do work there, or you can integrate something like wazzy. 20:15.780 --> 20:19.700 And then we also want to support a lesser known platform called open harmony, which is 20:19.700 --> 20:24.980 sort of like the open source version of Huawei's harmony OS, which is widely used in China, 20:24.980 --> 20:29.060 especially now that they've dropped support for Android on their new devices. So this could potentially 20:29.060 --> 20:36.420 bring matrix to, you know, a billion new users or so. Not sure. Oh, sorry. So I might have to 20:36.420 --> 20:42.500 power through here. So looking forward after, so that was stage one, right? We've we've hit a lot of 20:42.500 --> 20:50.020 the kind of main fundamental features. Some things that I frequently miss or like the ability to, 20:50.020 --> 20:53.620 you know, when I come back from vacation, I have hundreds of discord messages and one of my 20:53.620 --> 20:57.620 things. And I'd love to know like what the hell happened without having to skim through all of them. 20:57.620 --> 21:03.700 So there are some things that elements can help with and I can help with in a limited and 21:03.700 --> 21:08.340 tasteful capacity. So I want to make sure that we we straddle that line and we're not, you know, 21:08.340 --> 21:14.420 going and doing ridiculous stuff like forcing AI down everyone's throats. So okay, I'll skip all 21:14.420 --> 21:21.140 this stuff. So we, where did the multi-paying dock will tab? Yeah. Yeah, so you saw that? Okay, 21:21.140 --> 21:26.260 right. So I think one of the key tenets of matrix as we all know is in encryption and we want to 21:26.260 --> 21:31.060 preserve that. So how can we bring in AI? You obviously don't want to send off your entire encrypted 21:31.060 --> 21:36.180 room, message history up to open AI and upload it to chat, GPT, probably your fellow 21:36.260 --> 21:43.220 room users wouldn't be a fan of that. So how can we do that without, you know, exposing our data? 21:43.220 --> 21:47.300 So the key there is a local large language models, right? And this is definitely easier, 21:47.300 --> 21:53.860 something done on desktop devices, desktop platforms rather than mobile, but there are some models 21:53.860 --> 21:59.940 that are merging that can be run mobile. So we could do some cool features like this and we can 21:59.940 --> 22:04.660 do, you know, maybe some other longer-term goals where we're using matrix once we have this to 22:04.660 --> 22:09.860 share different agent recipes or chatbot demonstrations and help other people configure it through 22:09.860 --> 22:15.460 matrix, all in sort of a seamless manner. But the idea is to leverage one of our other flagship 22:15.460 --> 22:22.500 projects called motion, which is basically a local LLM runtime, if you're familiar with LLM studio, 22:22.500 --> 22:27.300 it's an open source version of this. This is also the same exact thing that you just saw in 22:27.300 --> 22:32.740 Robricks. It's fully entirely enrusted entirely from scratch using makepad and project robis. 22:32.820 --> 22:39.940 So you can see you can have customizable chats with the different LLM models that you have installed 22:39.940 --> 22:44.660 on your device. You can select them. So I think this would be relatively quite straightforward to 22:45.620 --> 22:51.140 integrate into Robricks itself. So I don't have too much time to talk about this. 22:51.140 --> 22:54.980 I also worked on this, you know, packaging it and getting all the platform features there. 22:55.140 --> 23:05.220 Okay. But there's a lot of features that we can use. So work has actually already begun to 23:05.220 --> 23:11.380 separate out all of these different components of motion and modularize them such that we could 23:11.380 --> 23:19.380 just do something like this, where you're able to select a model that you've installed locally. 23:19.460 --> 23:26.580 This will run using the Wasom Edge Wasom runtime, which has a wide variety of models already supported 23:26.580 --> 23:29.380 and is getting updated every day. So deep seek is already available.