WEBVTT 00:00.000 --> 00:12.000 Yes, excellent. Hello, welcome to our bedroom. Thank you all very much to the up. This 00:12.000 --> 00:17.000 is talking about Ellen Webb, which I'm hoping everybody knows what Ellen Webb is. I don't 00:17.000 --> 00:23.000 need to end yet. Good. Yep. Okay. One of the clients that Matthew just demonstrated 00:23.000 --> 00:32.000 in his talk. So what I'm going to talk about today is basically what Ellen Webb is, 00:32.000 --> 00:39.560 how we got to where we are now, and what we're aiming to get to in the future, and most 00:39.560 --> 00:45.280 importantly, how we're trying to get there. And then I'm going to pass over to Michael 00:45.280 --> 00:50.440 Lee Florian, who's going to do a slightly deeper dive into what the technicals of what I've talked 00:50.440 --> 00:55.440 about, because he's the one doing, frankly, most of the work at the moment on our shared components. 00:55.440 --> 01:01.440 So don't tell you about it. We're going to do some demos, and have some questions. Who are we? 01:01.440 --> 01:06.440 My name is Dave Baker. I'm a staff software engineer at Elements, also on the Matrix SpectCorting. 01:06.440 --> 01:12.440 I've had the great privilege of being able to work on the Elements full time for over 01:12.440 --> 01:20.440 10 years, basically the life of Matrix now. You find me on Dave Matrix at all. This is Florian. 01:20.440 --> 01:27.440 It's also now working on today's shared components, and also works on our full time. 01:27.440 --> 01:34.440 I'm in previous incarnations have worked on all sorts of Matrix areas, also with the point team 01:34.440 --> 01:40.440 who are out next. That's going to be really fun to talk to miss that. I've seen them hacking on their demos. 01:40.440 --> 01:49.440 I'm back to Elements Web. How do we get to where we are now? That's probably very familiar to everybody in this room yet. 01:49.440 --> 01:56.440 If you've used Elements Web, that's what it looks like now. It's reasonably fancy. We have designers now, and it looks quite good. 01:56.440 --> 02:01.440 Didn't always look like that. One day it looked like that. 02:02.440 --> 02:12.440 But back in the days when it looks like that, boy, it was fast. That was our first prototype. 02:12.440 --> 02:22.440 It was in React. It was quite small. Not too many lines of code. It was quite snappy. You could change rooms pretty much instantly. 02:22.440 --> 02:33.440 But yeah, it had no features. We started out in 2015. It was basically alongside JS SDK, JS SDK. It was built for Elements Web. 02:33.440 --> 02:40.440 It was this sort of flux model, so you dispatch all the way up to the top of the app, and then all the way. 02:40.440 --> 02:47.440 And then it bubbles down again to the views. That was the theory. We sort of used it very loosely. 02:47.440 --> 02:57.440 And it's led to our code quality being that there's not the most consistent. 02:57.440 --> 03:07.440 It was always intended. If you ever dive into the internals of Elements Web, you will have seen that it's mostly backed by a project called Matrix React SDK. 03:07.440 --> 03:11.440 That's where most of the code was, not anymore, because we got rid of it. 03:11.440 --> 03:19.440 Because the idea was that you would have this reusable base of components that you could use for Elements Web or any other chat up. 03:19.440 --> 03:23.440 But that was kind of a theory, and it never actually really worked. 03:23.440 --> 03:31.440 We learned, I think, quite a lot from that of how to do this or how to not do this at least. 03:31.440 --> 03:38.440 Also, there was quite a lot of logic in our components, which is not a really good thing from a software design point of view. 03:38.440 --> 03:44.440 You won't logic in your components. You won't just want your view code in your views. 03:44.440 --> 03:56.440 It's an open source project. We've had contributions from external contributors. That means you have to manage that or your for your code quality. 03:56.440 --> 04:01.440 And if you want your code quality to be consistent, we didn't always do that particularly well. 04:01.440 --> 04:05.440 We've put more and more features on over the years. 04:05.440 --> 04:10.440 Like, into integration, for example, didn't exist in that early prototype. 04:10.440 --> 04:16.440 That's all gone on afterwards. Spaces didn't exist. 04:16.440 --> 04:22.440 And frankly, technology standards have moved on a lot in the last decade on the web. 04:22.440 --> 04:27.440 React is a completely different place to where it was a decade ago. 04:27.440 --> 04:33.440 Classes look vastly different. Why is this important? 04:33.440 --> 04:41.440 I think at least, and certainly we aspire to be reading matrix on the web and on the desktop. 04:41.440 --> 04:45.440 And we're pretty proud of that. We're with the first clients. 04:45.440 --> 04:53.440 It's deployed pretty widely by open code by the Bundesmessinger in Germany, chat, which Matthew and Andy mentioned earlier. 04:53.440 --> 04:57.440 That's luck, chat, in Luxembourg. And that's just a smattering of the government. 04:57.440 --> 05:03.440 It's not including some of those of folks, but there's other folks. There's a whole other deployments. 05:03.440 --> 05:11.440 It's a lot of people use our own web, and it's setting the standards, kind of. 05:11.440 --> 05:18.440 And that's sort of the point. We really believe that if decentralized communication and chat is going to succeed, 05:18.440 --> 05:28.440 it needs something that's fast and reliable, and most importantly, as fast and reliable as the closed source non-federated competitors. 05:28.440 --> 05:34.440 We can't, nobody's going to use it if Discord's just a better user experience, right? 05:34.440 --> 05:40.440 There's only people in this room. You probably will use it, because you understand why that's good. 05:40.440 --> 05:47.440 And you're willing to tolerate it being maybe not as good user experience, but your friends and family probably aren't. 05:47.440 --> 05:52.440 So where do we want to get? 05:52.440 --> 06:01.440 We want to get the Russes to get, basically. If you saw Matthew talking about that earlier, it's, why is it good? 06:01.440 --> 06:06.440 Well, both the new mobile app powered by it. It's a bunch faster. 06:06.440 --> 06:12.440 It's got a sliding sink, which very briefly there's the old sink, which pulls in a lot of data. 06:12.440 --> 06:17.440 It's slower, sliding sink, newer sink, faster, two different protocols. 06:17.440 --> 06:23.440 Russes decay loads more memory efficient. E2E's built in right from the start. It's scalable. 06:23.440 --> 06:28.440 The models are all shared with the project called Ruma, so that's all. 06:28.440 --> 06:39.440 And then you get much more cross-platform consistency if you're, if all the, when we are element as a company, it will make a lot more sense of all our clients use the same codebase under the hood. 06:40.440 --> 06:54.440 So this is why we're talking about element web X. Can we do this? Can we run the Russes to get in web assembly and not new to write everything twice and reused crypto parts? 06:54.440 --> 07:00.440 So how, how are we going to do that? 07:00.440 --> 07:10.440 The element X web mobile app are so much better now versus the legacy ones, but I did somebody came up to me at the booth yesterday and said, 07:10.440 --> 07:18.440 I used element X because what used element legacy because everyone X didn't have X feature that I needed. 07:18.440 --> 07:26.440 So I think that was months ago that happened, but we're still not quite at that point where the mobile app's X app's overtaken. 07:26.440 --> 07:33.440 We don't want that with element web. We don't want to start a whole rewrite because it's so painful. 07:33.440 --> 07:44.440 Can we iterate on it and take the replace the engine of the ship while the ship is still sailing? That's the goal. 07:44.440 --> 07:53.440 So the idea is a break element web into this thing called shared components, which are reusable, very opinionated. 07:53.440 --> 08:00.440 So you're not probably going to be able to use them to build a generic chat client. It's going to look like elements. 08:00.440 --> 08:12.440 But the idea is that they are reusable and we do in fact today reused some of these shared components in element web modules, which is a different thing. 08:12.440 --> 08:20.440 I'm not quite going to talk about, but basically we can add functionality to element web and it's a different code base and the components can be reused in both. 08:20.440 --> 08:31.440 The components are agnostic of any matrix SDK. They don't have matrix logic in it. You just tell them what to display and they display it. They are UI code and nothing else. 08:31.440 --> 08:39.440 We've done a few small components so far. We're currently working on doing the room list and the timeline tiles. That's next. 08:39.440 --> 08:48.440 Then we are after that's done. The timeline is going to be a big one. Then we'll probably move on to doing the right panel, the space panel. 08:48.440 --> 08:53.440 That's the one to the very left if you saw that and then the login registration views. 08:54.440 --> 09:04.440 Most importantly, what we didn't do with react SDK, we want to actually prove that these components are reusable by reusing them in another app. 09:04.440 --> 09:09.440 That's a bit of a teaser for a demo later. 09:10.440 --> 09:17.440 In the long term, we want to make sure that these things are completely decoupled with really really well-defined interfaces. 09:17.440 --> 09:23.440 So it's completely easy to replace the code that actually drives them. They are just delivery. 09:23.440 --> 09:29.440 So saying earlier, you just tell them what to display and they display it. They don't really know about matrix at all. 09:29.440 --> 09:37.440 Then what's we've got that and then we can replace the bit underneath them to speak the rust SDK. 09:37.440 --> 09:45.440 At least that's the idea. They're very least we have this base of share component and it splits out our UI logic. 09:45.440 --> 09:48.440 And with that, I'm going to hand over to Florian. 09:52.440 --> 09:54.440 Is it good? Perfect. 09:59.440 --> 10:05.440 So first, before talking about the share components, we talk about in VVM. 10:05.440 --> 10:09.440 If you like the part-time, this is a description from Wikipedia. 10:09.440 --> 10:14.440 So VVM facet is a separation of the development of a graphical user. 10:14.440 --> 10:17.440 And it's a phrase from the development of the business logic. 10:17.440 --> 10:20.440 Such as the view is not dependent upon any specific model platform. 10:20.440 --> 10:28.440 So we want that platform is the RSA-ZK, the RSA-ZK, and the view to be our share components. 10:29.440 --> 10:34.440 So this is kind of a graphical view. So we have a model. 10:34.440 --> 10:41.440 So the model can be the RSA-ZK, the RSA-ZK, or stores, for example setting stores, or Romy store, whatever you want. 10:41.440 --> 10:44.440 The view is basically purely UI stuff. 10:44.440 --> 10:47.440 That would be in the share components. 10:47.440 --> 10:54.440 And the view model is kind of things that we bring, we take the data from the model, 10:54.440 --> 10:59.440 melt it in a certain interface. 10:59.440 --> 11:06.440 So the view can consume the data, and the view can also perform some actions on the view model. 11:06.440 --> 11:10.440 So as I say, the view leaves with the share components. 11:10.440 --> 11:13.440 The share components define the interface. 11:13.440 --> 11:16.440 Like I want this data, I want to display this kind of data. 11:16.440 --> 11:20.440 I want to call this kind of actions on the view model. 11:20.440 --> 11:27.440 The view model is in the application, like for example, in an element web, in element modules, 11:27.440 --> 11:34.440 on an Aurora or kind of new client playground to play with the RSA-ZK in web. 11:34.440 --> 11:39.440 And which is interesting, because the view model is provided by the application. 11:39.440 --> 11:44.440 We can have a bit of business logic, and we can use what we want as a back end. 11:44.440 --> 11:47.440 And it turned out for the right users. 11:47.440 --> 11:50.440 The view model is used to react, sync it in a store. 11:50.440 --> 11:54.440 So basically, a few models will implement the interface of the internet store. 11:54.440 --> 12:02.440 And it will produce some snapshots that the share components will consume. 12:02.440 --> 12:06.440 So a bit of borrowed play, a bit of code, just to see. 12:06.440 --> 12:08.440 Like, here have a view. 12:08.440 --> 12:14.440 As it's up, I've defined the snapshots, so the data I want to display. 12:14.440 --> 12:19.440 After the actions, so basically it's a button, so I want to click on the button. 12:19.440 --> 12:21.440 So I'm clicking on the button. 12:21.440 --> 12:23.440 The view model will do something, like, I don't know. 12:23.440 --> 12:25.440 I'm clicking on the button, so do whatever you want. 12:25.440 --> 12:28.440 It's your duty. 12:28.440 --> 12:35.440 After that, as a borrowed play, something while you're in takes a great moment. 12:35.440 --> 12:38.440 Here, I have a view model. 12:38.440 --> 12:43.440 So basically, implementing, like, the snapshots, I can see. 12:43.440 --> 12:45.440 I have, like, some codes. 12:45.440 --> 12:47.440 Like, they do models, like, a class. 12:47.440 --> 12:50.440 We are putting a lot of stuff that we need to be able to duplicate the code. 12:50.440 --> 12:55.440 I'm implementing this interface. 12:55.440 --> 12:58.440 I've playbed, which is my snapshots. 12:58.440 --> 13:04.440 And after that, I've done a click, which is the actions that I've defined in my view. 13:04.440 --> 13:08.440 So, sorry. 13:08.440 --> 13:09.440 Okay. 13:09.440 --> 13:13.440 So, as we can see, we decop our share components from the app logic. 13:13.440 --> 13:15.440 There is no dependency from L upon web. 13:15.440 --> 13:21.440 When I define a view, we don't use any components from element web. 13:21.440 --> 13:24.440 We don't use any logic from element web. 13:24.440 --> 13:28.440 If there's some basic logic previously, we put it in a view model. 13:28.440 --> 13:31.440 And if we need a component from element web, we will, as a rewrite it, 13:31.440 --> 13:33.440 and put it in share components. 13:33.440 --> 13:39.440 Just notes, share components is using component for share components, 13:39.440 --> 13:40.440 or from compound. 13:40.440 --> 13:44.440 Component is a law or design system, whether it's like some basic components, 13:44.440 --> 13:47.440 like buttons, drop the list. 13:47.440 --> 13:51.440 So, it's kind of, I end components that we have in share components. 13:51.440 --> 13:55.440 We try to use share components as early as possible in other apps, 13:55.440 --> 13:58.440 like, for example, in Aurora or in our modules. 13:59.440 --> 14:03.440 And most of all, when we bring new things in element web, 14:03.440 --> 14:05.440 we put it in share components. 14:05.440 --> 14:07.440 So, when we open the new UI, or we put it in some UI, 14:07.440 --> 14:10.440 we take it effort like move it to this new part then, 14:10.440 --> 14:15.440 and also we're using our Zen system and improving our accessibility. 14:15.440 --> 14:19.440 And it's also an opportunity to improve our tooling, 14:19.440 --> 14:23.440 because, for example, where element web still use webback. 14:23.440 --> 14:26.440 And so, in share components, we use vex, playtest, 14:26.440 --> 14:28.440 we use CSS, modules, and storybook. 14:28.440 --> 14:31.440 The part about storybook is important for us, 14:31.440 --> 14:33.440 because when we use this storybook, 14:33.440 --> 14:37.440 we can do some visual, visual, screenshot tests. 14:37.440 --> 14:41.440 We can also have light team tests, dark team tests, 14:41.440 --> 14:44.440 icon test system, and also some accessibility tests. 14:44.440 --> 14:47.440 So, we are also improving the accessibility, 14:47.440 --> 14:53.440 and the non-regression of element web. 14:54.440 --> 14:58.440 I have a demo about Aurora. 14:58.440 --> 15:00.440 So, just a bit thing about Aurora. 15:00.440 --> 15:03.440 So, it was it appears in our account. 15:03.440 --> 15:07.440 I think last year, it was at the beginning, 15:07.440 --> 15:09.440 developed by the story, 15:09.440 --> 15:11.440 but we went to web to use the rest SDK, 15:11.440 --> 15:12.440 in WebAssembly. 15:12.440 --> 15:16.440 So, we put some wasm, and we consume it in the front end. 15:16.440 --> 15:18.440 And at the beginning, we started that. 15:18.440 --> 15:21.440 We have the rest SDK, but we have to copy paste 15:21.440 --> 15:24.440 the component from element web, which is not really great, 15:24.440 --> 15:28.440 as they've said, because if you want to continue 15:28.440 --> 15:30.440 to iterate over element web, 15:30.440 --> 15:32.440 and we want that to try something else, 15:32.440 --> 15:34.440 we don't have to copy paste stuff, 15:34.440 --> 15:37.440 and of course, if a copy paste thing 15:37.440 --> 15:40.440 or something conflict, it would be a relatively good 15:40.440 --> 15:41.440 to maintain the skin. 15:44.440 --> 15:48.440 So, I will show you what Aurora looks for. 15:48.440 --> 15:55.440 Yeah. So, this is a very simple client conflict, 15:55.440 --> 15:58.440 but it's using the rest SDK, right? 15:58.440 --> 16:03.440 So, in this case, all the top left of Aurora 16:03.440 --> 16:05.440 is using component from element web. 16:05.440 --> 16:07.440 So, this is search sections, 16:07.440 --> 16:10.440 and this either of these buttons, second-hand ER, 16:10.440 --> 16:15.440 are from an initial component. 16:15.440 --> 16:17.440 So, also used by element web. 16:18.440 --> 16:21.440 And, normally, the next which we will have, like, 16:21.440 --> 16:24.440 or the room list, which will be the same component 16:24.440 --> 16:25.440 as an element web. 16:25.440 --> 16:29.440 So, when we do improvement as a room list on the accessibility, 16:29.440 --> 16:31.440 or some new design, 16:31.440 --> 16:33.440 it will be, we are just have to update 16:33.440 --> 16:36.440 elements of the dependency now in Aurora. 16:36.440 --> 16:39.440 And, maybe, why you are something in the room, 16:39.440 --> 16:41.440 in the room, or if there is new interface, 16:41.440 --> 16:46.440 by the view, but it will be automatically in Aurora. 16:48.440 --> 16:51.440 And, questions. 17:04.440 --> 17:05.440 Nice. 17:05.440 --> 17:06.440 Perfect. 17:06.440 --> 17:07.440 No. 17:07.440 --> 17:09.440 I don't want over there. 17:09.440 --> 17:14.440 If you look into other chat UI frameworks, 17:14.440 --> 17:17.440 when you can say, I like this UI, 17:17.440 --> 17:19.440 and then I like it. 17:19.440 --> 17:21.440 I like the question. 17:21.440 --> 17:22.440 Yeah. 17:22.440 --> 17:24.440 And, for example, yeah, what we choose, 17:24.440 --> 17:26.440 the email PM as a partner, right? 17:26.440 --> 17:27.440 Yeah. 17:27.440 --> 17:28.440 Yeah. 17:28.440 --> 17:29.440 Because, also, as an element, 17:29.440 --> 17:31.440 X application, using the email PM pattern, 17:31.440 --> 17:33.440 so they already, I, 17:33.440 --> 17:35.440 explain them, they are the knowledge, 17:35.440 --> 17:37.440 so they bridge the new application with them, 17:37.440 --> 17:39.440 where they are good feedback from the team, 17:39.440 --> 17:40.440 from the mobile team. 17:40.440 --> 17:43.440 So, we choose to go to the same direction. 17:44.440 --> 17:46.440 So, so why? 17:46.440 --> 17:47.440 This is not to oneself. 17:47.440 --> 17:48.440 Yeah, we've picked it for. 17:48.440 --> 17:49.440 Yeah. 17:49.440 --> 17:52.440 So, there's something like a chat scope, 17:52.440 --> 17:55.440 there's just a UI for chat. 17:55.440 --> 17:56.440 There has. 17:56.440 --> 17:58.440 And then the question is, can we take this, 17:58.440 --> 18:02.440 and put the metrics and the needs, 18:02.440 --> 18:05.440 and then have a metrics client? 18:05.440 --> 18:07.440 Yeah. 18:07.440 --> 18:08.440 I put the link in the chat. 18:08.440 --> 18:09.440 Okay. 18:09.440 --> 18:10.440 Perfect. 18:10.440 --> 18:11.440 Thank you. 18:14.440 --> 18:15.440 Yeah. 18:15.440 --> 18:16.440 I may have missed this, 18:16.440 --> 18:18.440 but do you have any sort of timeline, 18:18.440 --> 18:19.440 do you, when do you think, 18:19.440 --> 18:21.440 obviously, difficult? 18:21.440 --> 18:22.440 Yeah. 18:22.440 --> 18:23.440 And it's, you know, 18:23.440 --> 18:24.440 feedback framework, so, 18:24.440 --> 18:25.440 but I wanted to do, 18:25.440 --> 18:27.440 you've had any sort of timeline 18:27.440 --> 18:29.440 to just finally sunset the, 18:29.440 --> 18:31.440 the JS SDK. 18:31.440 --> 18:32.440 Yeah. 18:32.440 --> 18:36.440 So, the question was about, 18:36.440 --> 18:38.440 time lines, 18:38.440 --> 18:39.440 and when we eventually, 18:39.440 --> 18:42.440 it's expected sunset the JS SDK. 18:43.440 --> 18:45.440 I guess, firstly, 18:45.440 --> 18:48.440 we're not probably going to entirely sunset the JS SDK, 18:48.440 --> 18:51.440 because we realize that having a matrix JS SDK 18:51.440 --> 18:54.440 is obviously a super valuable thing for people to use. 18:54.440 --> 18:55.440 So, we're likely, 18:55.440 --> 18:57.440 we haven't fought a great deal about this yet, 18:57.440 --> 18:58.440 but we're likely to, 18:58.440 --> 19:01.440 if there's not a way of using the Russ SDK 19:01.440 --> 19:02.440 and the web, 19:02.440 --> 19:04.440 then provide a higher level wrapper for doing that, 19:04.440 --> 19:06.440 and then the matrix JS SDK will move to that. 19:06.440 --> 19:08.440 But yes, that probably wasn't really the question, 19:08.440 --> 19:10.440 the question was when, 19:10.440 --> 19:11.440 and yeah, it's, 19:11.440 --> 19:12.440 at the moment, we're thinking, 19:12.440 --> 19:13.440 basically, 19:13.440 --> 19:15.440 year plus at least, 19:15.440 --> 19:16.440 I think it for this, 19:16.440 --> 19:20.440 like we know it's going to take a while to move the shared components over. 19:20.440 --> 19:22.440 There's a lot of them, 19:22.440 --> 19:24.440 and, 19:24.440 --> 19:25.440 well, 19:25.440 --> 19:26.440 so elements, 19:26.440 --> 19:27.440 web now, 19:27.440 --> 19:29.440 is using the dozen maps, 19:29.440 --> 19:30.440 which Mattie mentioned earlier, 19:30.440 --> 19:31.440 the rest part, 19:31.440 --> 19:33.440 the crypto part of the Russ SDK, 19:33.440 --> 19:35.440 that migration took, 19:35.440 --> 19:38.440 I think, about three times longer than we were thinking, 19:38.440 --> 19:39.440 it was just, 19:39.440 --> 19:41.440 they've complexity just spiraled, 19:41.440 --> 19:42.440 and, of course, 19:42.440 --> 19:44.440 this is another level of complexity from that, 19:44.440 --> 19:47.440 so it's not to be underestimated. 19:47.440 --> 19:51.440 I can add a lot to the beauty, 19:51.440 --> 19:52.440 all right. 19:52.440 --> 19:53.440 Thank you. 19:53.440 --> 19:54.440 As so, 19:54.440 --> 19:55.440 because our, 19:55.440 --> 19:56.440 the current, 19:56.440 --> 19:58.440 a co-stack of an amount of web, 19:58.440 --> 19:59.440 there's a lot of, 19:59.440 --> 20:00.440 a lot of, 20:00.440 --> 20:01.440 a lot of, 20:01.440 --> 20:02.440 a lot of, 20:02.440 --> 20:03.440 a lot of, 20:03.440 --> 20:04.440 a lot of, 20:04.440 --> 20:05.440 a lot of, 20:05.440 --> 20:06.440 a lot of, 20:06.440 --> 20:07.440 a lot of, 20:07.440 --> 20:08.440 a lot of, 20:08.440 --> 20:09.440 a lot of, 20:09.440 --> 20:10.440 a lot of, 20:10.440 --> 20:11.440 a lot of, 20:11.440 --> 20:12.440 a lot of, 20:12.440 --> 20:13.440 a lot of, 20:13.440 --> 20:14.440 to do, 20:14.440 --> 20:15.440 and you have stuff, 20:15.440 --> 20:16.440 you have stuff, 20:16.440 --> 20:18.440 which is linked to business stuff, 20:18.440 --> 20:19.440 which is, 20:19.440 --> 20:20.440 a nightmare, 20:20.440 --> 20:21.440 one, two, 20:21.440 --> 20:22.440 one, two, 20:22.440 --> 20:23.440 and me, right? 20:23.440 --> 20:25.440 So that's why we take, 20:25.440 --> 20:26.440 this road to first. 20:26.440 --> 20:28.440 We can re-build you, 20:28.440 --> 20:31.440 so we can separate the UI from the business project, 20:31.440 --> 20:32.440 and after that, 20:32.440 --> 20:34.440 we can change the business project, 20:34.440 --> 20:35.440 so moving to the Russ SDK, 20:35.440 --> 20:38.880 And what are the performances in these new limitations? 20:38.880 --> 20:42.400 You have some people there. 20:42.400 --> 20:48.240 Question was, what's the performance like in the New England Foundation? 20:48.240 --> 20:50.240 Do you mean Aurora? 20:50.240 --> 20:56.120 Oh yeah, you mentioned in the beginning that the first thing I remember was Bob then probably not so far for you. 20:56.120 --> 21:05.120 As a year, very very first, I don't know, it was, well, one big differentiator was that none of us had very big accounts back then. 21:05.120 --> 21:14.120 So it was also slightly cheating because they're just weren't very many rooms, but yeah, when you've got a few rooms, it obviously loads very fast. 21:14.120 --> 21:32.120 Slighting sink came about as a problem that once you've got thousands and thousands maybe of rooms, like someone like Matthew has, even my accounts takes a couple of minutes to load on regular non-slighting sink. 21:32.120 --> 21:42.120 But we're sliding sink it's much, much faster, but yeah, back then I was in, I don't know, what 20 rooms and it logged in pretty much instantly, I think, even on non-slighting sink. 21:42.120 --> 21:55.120 And the most noticeable thing was when you change between rooms, there was no delay of things slowly loading in, you clicked it and the room was there. 21:55.120 --> 21:59.120 That was kind of one of the metrics that we measured. 22:00.120 --> 22:14.120 There was other things interestingly that make element feels slightly less snappy, but actually can be your server responding slower, which is that we don't show, or how we show messages being sent, which makes the app feel sluggish. 22:14.120 --> 22:20.120 If you're server is taking a while to actually send the message because we used to show it grey for a little while. 22:20.120 --> 22:28.120 And nowadays we put a little tick to the right hand side, which is a bit, makes it feel a bit less sluggish if that tick takes a while to appear. 22:28.120 --> 22:34.120 It's a bit less obvious than it going, spending ages being grey and then going black. 22:34.120 --> 22:36.120 Hopefully that answer the question. 22:36.120 --> 22:44.120 Very quickly, a concrete data point in, which isn't my personal account on normal element web uses about 2.4 gigs of RAM. 22:44.120 --> 22:51.120 Which is a problem because V8 limits you to about 1.4 gigs of RAM, and so it almost immediately out of memory is when I know them. 22:51.120 --> 22:58.120 So I have to run a hacks element desktop that removes half of the sink response specifically read receipts, so I can load it a tool. 22:58.120 --> 23:05.120 Same account on Aurora uses 80 meg of RAM, so that's the kind of difference between chair system and rust testing. 23:05.120 --> 23:07.120 Thank you. 23:07.120 --> 23:13.120 Yeah, so that was round or applause entirely goes to rust test decating, not me. 23:13.120 --> 23:15.120 Any other questions? 23:15.120 --> 23:22.120 So if understood correctly your plan is to replace one UI component at a time, basically. 23:22.120 --> 23:29.120 So the way it makes sense to have the replacement let's say one with use case at the time. 23:29.120 --> 23:38.120 For example, if some of those forks or public sector service use only as mol set of the features of element web. 23:38.120 --> 23:45.120 So maybe they could put them at behind the feature flag and start from, that's mol set of features that that could actually care. 23:45.120 --> 23:47.120 Does this make any sense? 23:47.120 --> 23:48.120 Yeah. 23:48.120 --> 23:50.120 Where is everyone using all the features? 23:50.120 --> 23:57.120 So the question was can we sort of migrate rather than component wise more feature wise if certain servers are using certain features? 23:57.120 --> 23:59.120 I think that's an interesting one. 23:59.120 --> 24:15.120 Yeah, because there are a bunch of features that probably a lot of people don't use and yeah, I think they might actually align because a lot of components will be will only be used in if you turn on, I don't know, whatever you want to use this space is that's a bad example. 24:15.120 --> 24:25.120 But if you turn on something else that will only use certain UI components, we might end up doing something probably very similar. 24:25.120 --> 24:31.120 So the core experience of just going log in chat, log out again. 24:31.120 --> 24:44.120 Yeah, I will probably concentrate on first and then other things like adding rooms to spaces or something is more esoteric functionality will be left to a bit later. 24:44.120 --> 24:49.120 What about that? 24:49.120 --> 24:51.120 This is not a question I guess about the component. 24:51.120 --> 24:53.120 The signature brought up sliding sink. 24:53.120 --> 25:00.120 Does this mean that the experimental sliding sink, the jazz implementation is kind of can happen for now? 25:00.120 --> 25:12.120 Does this mean that the experimental jazz SDK sliding sink implementation is can kind of, yeah, they only problem with, there's a specific reason why we didn't launch it. 25:12.120 --> 25:21.120 And that is essentially because we in element web rely on a couple of features that sliding sink doesn't implement yet. 25:21.120 --> 25:27.120 One is the element web implements presence, which is in sliding sink yet. 25:27.120 --> 25:34.120 There's one other that slips on I right now, but yeah, there's specific things that aren't implemented, which is really annoying. 25:34.120 --> 25:40.120 Obviously, the kicker is that we will need those implemented in sliding sink if we're going to migrate. 25:40.120 --> 25:44.120 So we're going to need the same thing on the protocol level. 25:44.120 --> 25:51.120 But if we're going to need more time to do that, we may as well do the thing properly, if you like. 25:51.120 --> 25:53.120 That was why. 25:53.120 --> 25:54.120 Another question. 25:54.120 --> 25:55.120 No, no. 25:55.120 --> 25:56.120 The thing's in reals. 25:56.120 --> 25:58.120 Last question. 25:58.120 --> 26:02.120 I don't think there was anyone else. 26:02.120 --> 26:04.120 I guess the question there is. 26:04.120 --> 26:09.120 If the jazz SDK is going to continue living, does that mean that the sliding sink will eventually get rich? 26:09.120 --> 26:16.120 It's having a nice decay without the sink. 26:16.120 --> 26:23.120 If the jazz SDK is going away, does that mean we'll kill legacy sink? 26:23.120 --> 26:26.120 It's more about if the jazz SDK isn't going away. 26:26.120 --> 26:27.120 Oh, yes, sorry. 26:27.120 --> 26:31.120 If the jazz is not going away, yeah, we'll have to maintain the thing. 26:32.120 --> 26:36.120 Yeah, if we keep the jazz SDK around it's current form. 26:36.120 --> 26:42.120 And now I think we would either way we would probably aim to get rid of non-slighting sink eventually. 26:42.120 --> 26:48.120 It's not a sum at so much of a jazz SDK restriction as an element web one really. 26:48.120 --> 26:52.120 I think the jazz SDK is quite happy supporting sliding sink. 26:52.120 --> 26:55.120 It's just that we happen to use features in element web. 26:56.120 --> 27:03.120 But yeah, I think the idea what I would like to do is move the jazz SDK over to sliding sink and then just use that. 27:03.120 --> 27:08.120 And then eventually the old version of sink goes away completely. 27:08.120 --> 27:10.120 And I think that's what we have time for. 27:10.120 --> 27:13.120 Thank you very much.