This is ghetto?
Yes.
Okay, perfect.
So, yeah.
If anybody joining on the stream, we talk basically to the points there.
So, yeah, I will repeat all of it, sorry.
And then, yeah, we have those high-level abstractions and we get things like the timeline,
where you can say, I want to send a new event to the timeline,
and it's immediately appearing in this reactive stream.
And then, in the background, putting it into the send queue, if you don't have network,
and then sending the event.
And then, there is a last trait in this Rust SDK monorepo, and that's the FFI layer.
And this is basically just to get Rust compatible with other programming languages.
But it actually does a little bit more than what it would expect, so it actually has
to be more abstractions to make it more accessible for actual developers in Kotlin or Swift.
And it's using UniFFI.
So, basically, the idea is you could just have this one set of instructions,
how Rust code is mapped to other programming languages, and then it's just getting,
it just generates finding for all kinds of languages.
So, as of now, what kind of platform support do we have?
So, as I said, before we have UniFFI with Kotlin and Swift, that's why it works with element X on Android and IRS.
But there are currently no support for TypeScript.
And as I said, or as a title says, like this talks all about getting the Rust SDK running with WebAssembly,
and then building a web client based on the Rust SDK, which, yeah, as of now, didn't really work.
Because most of it, UniFFI doesn't has bindings to TypeScript.
And there is parts of the Rust SDK, which are already used in element web, actually,
and that is the crypto-create.
So, the crypto-create has specific web-assembly bindings, which are not UniFFI because you do your own thing,
and that is what we use in element web, so that parts of element web actually already run on the Rust SDK.
Cool.
So, good, next thing.
So, now I just go to like a very rudimentary introduction to WebAssembly.
So, basically, it's just CPU instructions, as it says, WebAssembly.
So, there is no such thing like a few developers,
that's good.
You have basically the whole browser API, which is almost like an operating system,
and in WebAssembly, you really just have executable code without any environments.
So, you're lacking all the common runtime features.
This goes as far as you don't even have access to like system time,
because it's really just executing code.
So, and you also don't have any dumb access.
So, all those additional things, you would need through some bind generation to some other programming language,
which has native integration with the platform.
There is a performance penalty to it, even though it's pretty performant.
It is not compiled for one specific architecture,
so the assembly format is relatively generic.
Hence, there is a performance penalty.
And if you want to have a dependency, since there is no such thing as like a standard library,
or like a system, like your system integration,
you need to ship all your dependencies inside the WebAssembly.
Love you, you ship.
But it's super versatile, and it is a compilation target.
So, multiple programming languages can be used to then build for this compilation target.
And just to bring this other word, which probably lots of you already have heard,
also introspective.
So, Bazi, which is the Reppes-Emily system interface, then fixes some of those things.
So, basically then, you cannot just have this like executable environment,
but you have a little bit more system interfaces.
So, you need a slightly more complicated container, which can execute Bazi.
And there they try to standardize specific requests to the outside world.
So, they start really slow by just making at least something like system time available,
and define a quasi-container needs to provide a system time API,
and then we could do those kind of things.
So, it needs a more sophisticated host knowing about all those specific API calls.
And then, next slide. So, this is now the core two things we need.
If we want to have the rest SDK run in the web, like entirely up to the UI create,
where we have those really pretty abstractions.
And the one thing is we, of course, first need to get it compiled.
And that is not so trivial, because each compilation target in the rest has its own specificness to it.
And then, the other almost hard of challenge is that we then have to do interfaces
to the web environment. So, we can actually do something with the web browser with it.
And those interfaces exist for the crypto create, and also the first aspect,
compiling, exists for the crypto create.
But if you try to do the full SDK, that doesn't work.
And so, now we are in the section of compiling the SDK to web assembly.
And since we do use things like time for generating standard times and so on and so forth,
those need to be called in JavaScript.
So, we need to have like, just calls or like binding calls to JavaScript to then get the time
and then use that time in the web assembly thing.
And then the web also don't has any parallelism.
It's concurrent, but you don't have multiple threats, except with web brokers.
And since Rust is very highly in the rest of the case, well, build around like actual parallelism.
And there's like lots of centrates and synthrates.
And this is all, it should all be trivial in web assembly, because you don't have this problem,
if you don't have parallelism.
But you still need to get all your code and traits working and you need a lot of config flags
that if it's web assembly, you can treat it as if it would be sent and sync,
even though, yeah, it's not, but you will never run into parallel situations.
So there's just a little bit of work to be done, so it compiles probably to web assembly.
And the cool thing for this is this has happened really recently.
There wasn't too much work involved anymore to get it working, because since the work from the cryptocurrency
already was ported a little bit into the main crates, it weren't too many changes.
Like, time is something I mentioned a lot, and those, like, multi-fetting things.
And even nicer, Jonas, a form element, I'm clearly got funded by filament to then also put it on the main branch of the rest SDK.
So basically using the main branch of the rest SDK also is compatible with compiling it to web assembly, which is super cool, up to the UI layer.
And then the second challenge is the interface challenge.
So as I said, Unifified doesn't support JS and TS.
There will be note later on.
So this is, like, don't take this as a fact, it's just like what it was couple weeks ago.
So currently the web assembly fine-gen needs its own implementation.
So we have the Unifified fine-gen, which is already 10K lines of code.
And for web assembly, we would need to do the same thing again.
And that is, yeah, and then if we do, and that is just what it cryptocurrency,
and then if we would do this for the full SDK, that would be even more work.
So basically building specific web assembly bindings for the full UI trade would be insane,
and the only way would be what that would make sense is through Unifified.
And now I talk about different API cuts.
So at what point do we actually do the transition from the rest SDK to the web bridge?
And here's the example we currently do an element web.
So we have the really big rest SDK isn't even used.
We have the cryptocurrency, that is used and then we have the black box over here,
which is then the binding layer to TypeScript.
And then we have the JS SDK, and this binding layer to the cryptocurrency.
And this is how we build the whole web app, and TypeScript has a direct interface to the browser.
So that just works basically.
So this is basically the architecture we have an element web.
And based on this architecture, I did a couple of more graphs.
So those are possible ways when could think of a solution to do a rest SDK based matrix client in the browser.
So the top one, but it just introduced what element web is doing,
then one could consider just only using the rest SDK, not the UI abstraction.
And do pretty big bindings to a web app, and then build everything in TypeScript without the JS SDK.
The next option would be even harder where you have the cryptocurrency, the rest SDK create,
and then on top you have this UI create abstraction, and then you build really big bindings to then have TypeScript running and the browser.
And the last solution would be that you just don't stop using rest here.
But you would then also build your web app in rest, and represent the targets,
and then to actually communicate to the browser, you use a sophisticated web framework,
which just for its purpose already has all the system calls to the browser.
Yeah, those are the four examples listed on the left.
One of those web frameworks one could use is the access.
And this is then also basically the example I'm bringing to you today.
So this is just like a very short introduction to the access.
It's a rough based browser front or web front and library.
Here's like a little code snaplet from their documentation, which is like their basic example.
It's very inspired by React or at least if your React developer looks familiar.
It's inspired by multiple things.
So you have use signal, which one can think of as use state.
And then as soon as we use this signal object in this RSX, which is the equivalent to JSX,
we subscribe to the signal.
So this block is now subscribed to the state.
And whenever that state changes, it just re-rends the specific RSX.
And here we change the state, and it's all pretty nice.
So in the background, this plus equals operator connects to the signal or sets the signal,
and then emits functions, but it's all very beautifully hidden in this access thing.
And then yeah, this is based on towering.
That's something I still wanted to mention.
And it already includes all the bindings to then taught directly to the browser.
So technically it works that they only have their own weedon,
and then based on that weedon, they just sync the DOM with the browser.
And they also have something pretty cool, which I just wanted to note as a side note.
It's called Blitz, which then uses their weedon and directly render it into their own DOM-like browser.
But it's just GL code, so they don't use any like browser dependency.
They just use their weedon and directly render it in like a native OpenGL canvas.
Okay.
So now we get to the demo, and it seems like I don't even have too much time anymore.
But basically this exact project I did, and it wasn't even that big of a project,
because the I layer is doing so many things already.
So it was mostly hooking this up with the access.
And this is now a matrix client you will see that is using the rest is decay in the browser.
It's not too obvious that this is a browser, because it's like this weed root browser.
But it is.
And then yeah, you can see this is just a basic matrix browser.
This is a client, I'm not even sure what I was planning to show here.
So definitely sending messages.
Yeah, I was in a short way, this isn't closing.
There we go.
So let's say hi.
It's like the first example and it's sending it to the room.
Then you can select different messages and then edit them.
And there's like the really big advantage of using this timeline abstraction.
So if I edit this message, it will update the timeline and it's all pretty easy to develop.
And put it in the send queue and then send it to my other clients or anybody else in the room.
And when I do something in a different client, let's say yeah, this should be like this room over here.
And I say test.
Then I'm also highly benefiting from the reactiveness of the.
Oh, okay, fluent.
So I tell you where we can see that it's immediately updating this one over here.
Also in the timeline, because it's all those reactive primitives from the RSS decay, which is super, super nice.
So this is like, I mean, it's like a project you would advocate as like a one-hour project.
In reality it was more like 15 hours or 10 hours.
But yeah, it's very, very little code.
And I wanted to go and hoping this doesn't like entirely break the.
Break the length of the talk.
I want you to give you like a very short run through in how this code looks like.
Oh, not sure what my.
He's code student here.
Oh, is this a problem?
Oh, you're right.
Okay, I was about to reload the window.
So basically, I just want you to go through a couple of lines of code.
So this is interesting where we set up the timeline events array.
I'm using a.
Get up the signal.
And then.
As the next thing.
Sorry, this is super awkward to work like this.
We have like the main rendering code or sorry, no, the main subscription code.
So we use this dream primitive from the RSS decay.
Which gives us a vector diff.
And then the specter diff just gets applied to the.
Like in this the object we have the timeline events.
It's a little.
Yeah, it's not too easy to read because I gave it such small names.
But we take the diff.
We apply it to our timeline object.
Oh, sorry.
The D object is the diff and the T is the timeline.
And then that's basically all the code we need to do.
And this is all the setup to connect everything to the RSS decay.
And of course, I didn't even mention that this all does encryption and everything.
And then we have this timeline events array.
And with this timeline events array, we then just have to do the rendering.
So here we are in this RSS object.
And the rendering is pretty straight forward.
So we just do.
They are also added a little bit of analysis because I wanted to know what the last message is.
So I'm doing this peekable iterator.
But at the end, it's just going through the iterator.
Mepping the iterator.
Mepping the items to this message shall be which is just a function.
Not even a adaptive component that is just like taking the item object,
which is like a super high, like super easy to work with message item.
And then converting it into HTML.
And then the next bit is just going quickly through how we do editing.
So we have a button on click.
And the on click message then gets connected to this function.
And here we again use this like super high, lot of timeline thing.
And just do timeline.edit.
And pass in the new message.
And the new message we get from composer message.
Like this is also signal.
And then we just read whatever is in the composer.
And that does all the things, like setting up the correct event,
encrypting it, sending it, updating the timeline.
So we have free time feedback and immediately see the updated change.
So the developer experiences super super nice with this.
So yeah, this setup is what I just demoed.
And then there's like this one, this one big elephant in the room,
which I also wanted to show you so basically if we.
I'm trying to, there we go.
So if I do a reload here and we type in wasn't.
Now we can see that this is actually a.
Oh, good.
Oh, no, it is here.
Yeah, actually a almost half a gigabyte web assembly binding.
And that is of course super embarrassing and kind of annoying.
But there are things you can approve this.
So the first is you just don't build debug flags, but you actually do a release.
And do some optimizations on it.
So then you're down to 30 megabytes, which is okay.
And then likely wasn't compresses really well.
So if you just do a zip compression on it, you're down to four megabytes,
which is still not the best.
At least we improved it by 100x compared to the debug symbols.
But it's definitely like with internet nowadays,
it's a reasonable solution and not absolute insanity.
And yeah, this is the deaf experience I actually did the order
on there.
So imagine I would have done the walkthrough through the code now.
And then there's this other really big note.
The news that the UniFFI and BiGen React native is a project,
which tries to do UniFFI, but for React native, hence for TypeScript.
And this makes this also working solution.
So basically we have now three working solution,
how you could use the rest as you can the web.
So this works then that they take the rest as you I,
where you have the really big binding layer for Swift and Kotlin.
And they just expose the same binding layer to TypeScript.
And then you could also use React or any other web front
and based on JavaScript.
And basically have this kind of architecture,
because all the screen stuff, which I first said,
it's like this huge project.
One would take on if you use Basin Bionchen,
you just get for free, through UniFFI.
So the key takeaways do you have time for the key takeaways?
Yes, that's fine.
So it matrix webcline can be built now with the rest SDK using dioxys.
And maybe in a week or I'm not sure what the current publishing state of the UniFFI is.
Also with TypeScript and JavaScript.
And you get lots of benefits from it.
Like it's a very well maintained crypto.
It has key backup.
We have even widget support because of the element call work.
And lots of it, at least, some would still need to be done.
And there's actually something I tried to get into this demo.
But then I just spend huge amount of time
to getting the crypto feature.
As or the widget feature, compile to WebAssembly.
This network, but there were still some other issues.
So lots of time spent there, which didn't improve the slides.
So they still have pretty blank and little colors.
But on the other hand, we do have progress on widget support now with Basin.
So it probably takes me a week or so.
But then there's also would be a thing.
The event question isn't there.
Almost there's no index db adapter.
But that is also something which isn't too hard to do.
And you have matrix RTC support.
There's actually something I can show real quick because that's kind of cool.
So if we look back in here.
And then I take my.
So matrix RTC doesn't mean that calling works.
It just means that it is aware of of calls.
So if I just go here and then call this guy like this account,
it should say at some point.
Yeah, that there's an ongoing call.
So it detects the state and the abstraction we have about
reactively showing the call.
And then think we over, right?
It has simplified sliding sync.
And soon it's also possible to get all the same features with
the unit of the pipeline.
Cool, thanks for listening.