Yes, excellent. Hello, welcome to our bedroom. Thank you all very much to the up. This
is talking about Ellen Webb, which I'm hoping everybody knows what Ellen Webb is. I don't
need to end yet. Good. Yep. Okay. One of the clients that Matthew just demonstrated
in his talk. So what I'm going to talk about today is basically what Ellen Webb is,
how we got to where we are now, and what we're aiming to get to in the future, and most
importantly, how we're trying to get there. And then I'm going to pass over to Michael
Lee Florian, who's going to do a slightly deeper dive into what the technicals of what I've talked
about, because he's the one doing, frankly, most of the work at the moment on our shared components.
So don't tell you about it. We're going to do some demos, and have some questions. Who are we?
My name is Dave Baker. I'm a staff software engineer at Elements, also on the Matrix SpectCorting.
I've had the great privilege of being able to work on the Elements full time for over
10 years, basically the life of Matrix now. You find me on Dave Matrix at all. This is Florian.
It's also now working on today's shared components, and also works on our full time.
I'm in previous incarnations have worked on all sorts of Matrix areas, also with the point team
who are out next. That's going to be really fun to talk to miss that. I've seen them hacking on their demos.
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.
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.
Didn't always look like that. One day it looked like that.
But back in the days when it looks like that, boy, it was fast. That was our first prototype.
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.
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.
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.
And then it bubbles down again to the views. That was the theory. We sort of used it very loosely.
And it's led to our code quality being that there's not the most consistent.
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.
That's where most of the code was, not anymore, because we got rid of it.
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.
But that was kind of a theory, and it never actually really worked.
We learned, I think, quite a lot from that of how to do this or how to not do this at least.
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.
You won't logic in your components. You won't just want your view code in your views.
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.
And if you want your code quality to be consistent, we didn't always do that particularly well.
We've put more and more features on over the years.
Like, into integration, for example, didn't exist in that early prototype.
That's all gone on afterwards. Spaces didn't exist.
And frankly, technology standards have moved on a lot in the last decade on the web.
React is a completely different place to where it was a decade ago.
Classes look vastly different. Why is this important?
I think at least, and certainly we aspire to be reading matrix on the web and on the desktop.
And we're pretty proud of that. We're with the first clients.
It's deployed pretty widely by open code by the Bundesmessinger in Germany, chat, which Matthew and Andy mentioned earlier.
That's luck, chat, in Luxembourg. And that's just a smattering of the government.
It's not including some of those of folks, but there's other folks. There's a whole other deployments.
It's a lot of people use our own web, and it's setting the standards, kind of.
And that's sort of the point. We really believe that if decentralized communication and chat is going to succeed,
it needs something that's fast and reliable, and most importantly, as fast and reliable as the closed source non-federated competitors.
We can't, nobody's going to use it if Discord's just a better user experience, right?
There's only people in this room. You probably will use it, because you understand why that's good.
And you're willing to tolerate it being maybe not as good user experience, but your friends and family probably aren't.
So where do we want to get?
We want to get the Russes to get, basically. If you saw Matthew talking about that earlier, it's, why is it good?
Well, both the new mobile app powered by it. It's a bunch faster.
It's got a sliding sink, which very briefly there's the old sink, which pulls in a lot of data.
It's slower, sliding sink, newer sink, faster, two different protocols.
Russes decay loads more memory efficient. E2E's built in right from the start. It's scalable.
The models are all shared with the project called Ruma, so that's all.
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.
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?
So how, how are we going to do that?
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,
I used element X because what used element legacy because everyone X didn't have X feature that I needed.
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.
We don't want that with element web. We don't want to start a whole rewrite because it's so painful.
Can we iterate on it and take the replace the engine of the ship while the ship is still sailing? That's the goal.
So the idea is a break element web into this thing called shared components, which are reusable, very opinionated.
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.
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.
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.
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.
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.
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.
That's the one to the very left if you saw that and then the login registration views.
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.
That's a bit of a teaser for a demo later.
In the long term, we want to make sure that these things are completely decoupled with really really well-defined interfaces.
So it's completely easy to replace the code that actually drives them. They are just delivery.
So saying earlier, you just tell them what to display and they display it. They don't really know about matrix at all.
Then what's we've got that and then we can replace the bit underneath them to speak the rust SDK.
At least that's the idea. They're very least we have this base of share component and it splits out our UI logic.
And with that, I'm going to hand over to Florian.
Is it good? Perfect.
So first, before talking about the share components, we talk about in VVM.
If you like the part-time, this is a description from Wikipedia.
So VVM facet is a separation of the development of a graphical user.
And it's a phrase from the development of the business logic.
Such as the view is not dependent upon any specific model platform.
So we want that platform is the RSA-ZK, the RSA-ZK, and the view to be our share components.
So this is kind of a graphical view. So we have a model.
So the model can be the RSA-ZK, the RSA-ZK, or stores, for example setting stores, or Romy store, whatever you want.
The view is basically purely UI stuff.
That would be in the share components.
And the view model is kind of things that we bring, we take the data from the model,
melt it in a certain interface.
So the view can consume the data, and the view can also perform some actions on the view model.
So as I say, the view leaves with the share components.
The share components define the interface.
Like I want this data, I want to display this kind of data.
I want to call this kind of actions on the view model.
The view model is in the application, like for example, in an element web, in element modules,
on an Aurora or kind of new client playground to play with the RSA-ZK in web.
And which is interesting, because the view model is provided by the application.
We can have a bit of business logic, and we can use what we want as a back end.
And it turned out for the right users.
The view model is used to react, sync it in a store.
So basically, a few models will implement the interface of the internet store.
And it will produce some snapshots that the share components will consume.
So a bit of borrowed play, a bit of code, just to see.
Like, here have a view.
As it's up, I've defined the snapshots, so the data I want to display.
After the actions, so basically it's a button, so I want to click on the button.
So I'm clicking on the button.
The view model will do something, like, I don't know.
I'm clicking on the button, so do whatever you want.
It's your duty.
After that, as a borrowed play, something while you're in takes a great moment.
Here, I have a view model.
So basically, implementing, like, the snapshots, I can see.
I have, like, some codes.
Like, they do models, like, a class.
We are putting a lot of stuff that we need to be able to duplicate the code.
I'm implementing this interface.
I've playbed, which is my snapshots.
And after that, I've done a click, which is the actions that I've defined in my view.
So, sorry.
Okay.
So, as we can see, we decop our share components from the app logic.
There is no dependency from L upon web.
When I define a view, we don't use any components from element web.
We don't use any logic from element web.
If there's some basic logic previously, we put it in a view model.
And if we need a component from element web, we will, as a rewrite it,
and put it in share components.
Just notes, share components is using component for share components,
or from compound.
Component is a law or design system, whether it's like some basic components,
like buttons, drop the list.
So, it's kind of, I end components that we have in share components.
We try to use share components as early as possible in other apps,
like, for example, in Aurora or in our modules.
And most of all, when we bring new things in element web,
we put it in share components.
So, when we open the new UI, or we put it in some UI,
we take it effort like move it to this new part then,
and also we're using our Zen system and improving our accessibility.
And it's also an opportunity to improve our tooling,
because, for example, where element web still use webback.
And so, in share components, we use vex, playtest,
we use CSS, modules, and storybook.
The part about storybook is important for us,
because when we use this storybook,
we can do some visual, visual, screenshot tests.
We can also have light team tests, dark team tests,
icon test system, and also some accessibility tests.
So, we are also improving the accessibility,
and the non-regression of element web.
I have a demo about Aurora.
So, just a bit thing about Aurora.
So, it was it appears in our account.
I think last year, it was at the beginning,
developed by the story,
but we went to web to use the rest SDK,
in WebAssembly.
So, we put some wasm, and we consume it in the front end.
And at the beginning, we started that.
We have the rest SDK, but we have to copy paste
the component from element web, which is not really great,
as they've said, because if you want to continue
to iterate over element web,
and we want that to try something else,
we don't have to copy paste stuff,
and of course, if a copy paste thing
or something conflict, it would be a relatively good
to maintain the skin.
So, I will show you what Aurora looks for.
Yeah. So, this is a very simple client conflict,
but it's using the rest SDK, right?
So, in this case, all the top left of Aurora
is using component from element web.
So, this is search sections,
and this either of these buttons, second-hand ER,
are from an initial component.
So, also used by element web.
And, normally, the next which we will have, like,
or the room list, which will be the same component
as an element web.
So, when we do improvement as a room list on the accessibility,
or some new design,
it will be, we are just have to update
elements of the dependency now in Aurora.
And, maybe, why you are something in the room,
in the room, or if there is new interface,
by the view, but it will be automatically in Aurora.
And, questions.
Nice.
Perfect.
No.
I don't want over there.
If you look into other chat UI frameworks,
when you can say, I like this UI,
and then I like it.
I like the question.
Yeah.
And, for example, yeah, what we choose,
the email PM as a partner, right?
Yeah.
Because, also, as an element,
X application, using the email PM pattern,
so they already, I,
explain them, they are the knowledge,
so they bridge the new application with them,
where they are good feedback from the team,
from the mobile team.
So, we choose to go to the same direction.
So, so why?
This is not to oneself.
Yeah, we've picked it for.
Yeah.
So, there's something like a chat scope,
there's just a UI for chat.
There has.
And then the question is, can we take this,
and put the metrics and the needs,
and then have a metrics client?
Yeah.
I put the link in the chat.
Okay.
Perfect.
Thank you.
Yeah.
I may have missed this,
but do you have any sort of timeline,
do you, when do you think,
obviously, difficult?
Yeah.
And it's, you know,
feedback framework, so,
but I wanted to do,
you've had any sort of timeline
to just finally sunset the,
the JS SDK.
Yeah.
So, the question was about,
time lines,
and when we eventually,
it's expected sunset the JS SDK.
I guess, firstly,
we're not probably going to entirely sunset the JS SDK,
because we realize that having a matrix JS SDK
is obviously a super valuable thing for people to use.
So, we're likely,
we haven't fought a great deal about this yet,
but we're likely to,
if there's not a way of using the Russ SDK
and the web,
then provide a higher level wrapper for doing that,
and then the matrix JS SDK will move to that.
But yes, that probably wasn't really the question,
the question was when,
and yeah, it's,
at the moment, we're thinking,
basically,
year plus at least,
I think it for this,
like we know it's going to take a while to move the shared components over.
There's a lot of them,
and,
well,
so elements,
web now,
is using the dozen maps,
which Mattie mentioned earlier,
the rest part,
the crypto part of the Russ SDK,
that migration took,
I think, about three times longer than we were thinking,
it was just,
they've complexity just spiraled,
and, of course,
this is another level of complexity from that,
so it's not to be underestimated.
I can add a lot to the beauty,
all right.
Thank you.
As so,
because our,
the current,
a co-stack of an amount of web,
there's a lot of,
a lot of,
to do,
and you have stuff,
you have stuff,
which is linked to business stuff,
which is,
a nightmare,
one, two,
and me, right?
So that's why we take,
this road to first.
We can re-build you,
so we can separate the UI from the business project,
and after that,
we can change the business project,
so moving to the Russ SDK,
And what are the performances in these new limitations?
You have some people there.
Question was, what's the performance like in the New England Foundation?
Do you mean Aurora?
Oh yeah, you mentioned in the beginning that the first thing I remember was Bob then probably not so far for you.
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.
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.
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.
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.
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.
That was kind of one of the metrics that we measured.
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.
If you're server is taking a while to actually send the message because we used to show it grey for a little while.
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.
It's a bit less obvious than it going, spending ages being grey and then going black.
Hopefully that answer the question.
Very quickly, a concrete data point in, which isn't my personal account on normal element web uses about 2.4 gigs of RAM.
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.
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.
Same account on Aurora uses 80 meg of RAM, so that's the kind of difference between chair system and rust testing.
Thank you.
Yeah, so that was round or applause entirely goes to rust test decating, not me.
Any other questions?
So if understood correctly your plan is to replace one UI component at a time, basically.
So the way it makes sense to have the replacement let's say one with use case at the time.
For example, if some of those forks or public sector service use only as mol set of the features of element web.
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.
Does this make any sense?
Yeah.
Where is everyone using all the features?
So the question was can we sort of migrate rather than component wise more feature wise if certain servers are using certain features?
I think that's an interesting one.
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.
But if you turn on something else that will only use certain UI components, we might end up doing something probably very similar.
So the core experience of just going log in chat, log out again.
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.
What about that?
This is not a question I guess about the component.
The signature brought up sliding sink.
Does this mean that the experimental sliding sink, the jazz implementation is kind of can happen for now?
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.
And that is essentially because we in element web rely on a couple of features that sliding sink doesn't implement yet.
One is the element web implements presence, which is in sliding sink yet.
There's one other that slips on I right now, but yeah, there's specific things that aren't implemented, which is really annoying.
Obviously, the kicker is that we will need those implemented in sliding sink if we're going to migrate.
So we're going to need the same thing on the protocol level.
But if we're going to need more time to do that, we may as well do the thing properly, if you like.
That was why.
Another question.
No, no.
The thing's in reals.
Last question.
I don't think there was anyone else.
I guess the question there is.
If the jazz SDK is going to continue living, does that mean that the sliding sink will eventually get rich?
It's having a nice decay without the sink.
If the jazz SDK is going away, does that mean we'll kill legacy sink?
It's more about if the jazz SDK isn't going away.
Oh, yes, sorry.
If the jazz is not going away, yeah, we'll have to maintain the thing.
Yeah, if we keep the jazz SDK around it's current form.
And now I think we would either way we would probably aim to get rid of non-slighting sink eventually.
It's not a sum at so much of a jazz SDK restriction as an element web one really.
I think the jazz SDK is quite happy supporting sliding sink.
It's just that we happen to use features in element web.
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.
And then eventually the old version of sink goes away completely.
And I think that's what we have time for.
Thank you very much.