Hello everyone, in this presentation we will talk about the internet open store-out real-time
extensible messaging and presence protocol. We will present the actual ecosystem of the
XMPP as it is today and we'll give a sneak peek about the new features coming soon.
I am Geron, developer on the EJBD server and I am Waze.
Timote or Timor Edelas, I'm a movie developer for client developer and I will show you
a few things in this presentation but I have another one just after if you want to stay,
you will have a bit more information.
So today, XMPP is massively deployed for various use cases ranging from instant
messaging to internet a thing, gaming or social networking and these are just a few examples
of the XMPP deployment that we have currently in production today.
So the XMPP software ecosystem right now, there is five each major XMPP servers
plus smaller ones that can all interpret together because XMPP is a federated protocol
so we have server to server communication. We have more than 20 clients for all of your
mobile desktop web console come online. There is at least one library for your favorite language
and in the heart of that ecosystem, we have the XMPP standard foundation.
But the XMPP is not a central entity that decide the evolution of the protocol
and tell the developers when to implement in a top-down process.
Actually, it is quite the opposite because anyone involved in that ecosystem can propose
a volitional extension of the protocol which are then discussed via the XSF with other actors
and it means that the XSF is more tool to help build the protocol by and for the one
part with it. And this way, the evolution of the protocol will match the needs of the
people who are actually developing or using it.
So a bit more information about the protocol itself. So the XMPP protocol is built on
RFCs. There is a few core RFCs that define the basic feature that you need to connect
to a server and exchange messages. And then we have what we call XAPs. So it is extensions.
It is little document that basically say how to do like one specific thing.
And those are actually the elements that are discussed between the different XMPP projects and
facilitated by the XMPP software foundation. So it is a little preview of the flow.
It is a bit more complex, but as a developer, you can basically present XAP as an experimental
and try to do like some hack in your software and then talk with other developers.
We will show you later how it actually is done. And you can talk also with server developer.
And then your XAP is proposed. And there is a whole process to know how it integrates quite well
or not, which we need to fix things. And then it goes to final for some of them or goes back
if there is more to discuss.
Yeah. So basically the core of XMPP is written by the dev and the contributor of XMPP
like the top down system as Jerome said.
So concretely, so we have two RFC to many RFCs. So XMPP is an ITF official protocol.
The XMPP core and XMPP is not messaging in presence.
Plus 20 each other RFC to interconnect with other internet protocol like XMPP over web
or web socket or XMPP over TLS or stuff like that. And we have the famous XAP, the XToshans
to the protocol. Right now we have more than 500 XAP and still growing.
And of course developers won't have to implement all the XAP.
You can see that like a toolkit of protocol when developers can pick their own sub protocols
and assemble them like Legos to build their own custom protocols.
But what it means is that different clients or different servers won't implement the same extension.
So that arises a question, can it work?
I mean if a client is connecting to a server and the client is implementing an extension
that the server won't understand, it may be a problem.
But actually we have the backward compatibility in mind.
And we ensure that the interpretation that it's interoperable with Legosys software.
And for that we have different mechanisms to do that.
And we will show you a few of them so you can understand always it possible to be a still interoperable
with this variety of software and implementation.
Let's dive into some great details.
So this is an example, what we call as Tanzah in example,
so it's basically a message that has been sent from someone to someone,
so Julia to Romero to Juliet.
And in this example you actually see how it's done.
So it's based on XML.
And if one of those person have only a basic client,
they will actually just see the URL.
But on the updated client, a recent client can actually have the whole card with the thumbnail and the picture.
So you can basically have like an easily like cross-compatible clients that can
system that can actually go between different software easily.
And the other really interesting thing based on the XML is that we are using namespaces.
So basically those blocks, like we said Legos, can actually be reused.
So this block that is doing this little thumbnail is actually reused in many different places.
So when you're developing a client, you basically implement those blocks and then you just combine them together
for like file transfer, for like a block bus, for like stories, for like all those examples.
And it's just, yeah, reuse across the network and perfectly standardize using the namespace system that you have in XML in general.
Still me.
Yeah, we also have like what we call the discovery and capability is a feature that maybe is in many other protocols as well.
But works quite well actually in the example.
So when a client talk with another client or with a server, it can basically ask the server or the other client, like,
can you actually do that? Can you display this information and decide if it is sent or not?
I read the information.
And if not, then you can actually like degrade the UI or degrade the system to actually work quite well with the others.
So I gave you a little screenshot of my own project where normally no most of the server can do it, but we still have some old servers on the network.
And if someone actually connects with movie, that does the whole social network feature on top,
then actually tell the person that, okay, like sorry, but you don't have everything to do social networking correctly,
but you still have the chat and like video conferencing and all those things.
So it's quite easy to detect, like it's just one query or dirty push to you, and you just adapt your UI this way.
So is there is another mechanism to under the different level of implementation?
Here is this message. This is a reply to when you want to reply to a specific message in a group chat.
So with a knife client that doesn't understand the reply to extension, it will just understand the body here, because all the other stuff are in namespaces that it won't understand.
And that body is already formatted in just plain text formats, just display the response in a good enough manner that the user, the young user will understand.
Then for a client that does implement the reply to, it will understand that that reply stands out here with the ID of the message that is reply to.
And also that fallback here, which is basically saying just ignore the 37 first character in the body, which means that it will just consider this one, because what's what's it's before,
it's not for this client, it's for just for knife clients. And so it will be able to run there like on the right, better UI for the end user.
So this is also the kind of mechanism we can use to cope with the different software and different implementations.
So now that we've died in the protocol itself, let's see how it works between all the project and all the implementations.
So when you submit an extension or when you work on an extension or you want to implement an extension, that's where the exemplifies software foundation actually come in and provide tools to actually help you doing this those tasks.
So those exact, they are well categorized and they have like some metadata and the clients developer and several developers actually provide also metadata and there is like some information shared.
And you can actually see that we, you are not alone, like one, I want to implement the materials of chat, I actually know exactly which other clients are compatible or not on which level from which versions.
And that's really help about like knowing, okay, I have this really fresh example, like for example, I will use see later the stories, sorry that you have an Instagram or like all the other platform is quite fresh, but I can actually say, oh, there is this guy that he's working so I can directly contact him and actually work with him to do the interaction.
And we also have what we call the compliance suits, which is a way to say, okay, we do, we did a best off of the exact. So if you are doing I am only the chat, then this is like the actually tank depth that you need to implement to actually have this core feature and we are a couple of them, I think we have things about also mobile and we have yeah web and mobile and so to say, okay, you want to do that.
It's like a starter park, you need to implement at least those apps and you will actually really fit well with all the other clients and servers.
So yeah, that's the list of an extract of the steps from 04 to 050 on the right, you see the client and if you click on that, you actually have this view that he's like, I think it's 24 hour refresh.
So it's a little game, it's quite fun because actually you are like, okay, this client is doing that and I have this amount of steps and so it's like a little checkbox that you like to do when you're implementing example.
So let's see a specific case to do to see the server and the client interacting together for instance in the voice and video course.
So on the server side, the server will be providing a stun turn services, which are not part of the exam pp ecosystem, but via the exam pp, the client can discover with the disco feature we've seen before.
That there is a stun turn service on the server and we have the server can also provide some credentials so the client can use those services.
And then the server may act as a media relay in case the all the client are netted of behind fire wall and cannot establish peer to peer connections.
And of course there is a signaling part will be will be go through through the server.
So in the exam pp ecosystem, all the video core and audio core protocol is called Jingle and so the all the client participating in the in the core can extend the signaling part before establish their their stream.
The binary stream will extend via the server to negotiate the connection.
So let's look at the client side of the video conference feature so that's a little screenshot of the mobile version of moving with some friends of me.
So yeah, in moving like it's a full web client so I'm mostly built on the web RTC that you may know which is like the standard group of feature that you can have in the browser nowadays.
And I'm talking with the exam pp server that actually translate and I'm doing the translation between the web RTC world and the exam pp world.
So the jingle part, which is basically just to go a bit more technical so web RTC is doing sdp and exchanging messenger zp and in jingles basically the sdp but in XML with a few more information on top.
That's sometimes misses so it's quite easy to map one to the others and we actually also create mj which is like so jingle is mostly one to one is how you create a peer to peer connection between two clients.
And mj is basically this but with several persons so you can basically add this nice little chat rooms with some other people and you will see later.
I have I have to be really careful with this cable so you have more to see later and the really nice thing about that is that.
We are actually compatible across clients so that was I think the first time that we like on the internet that we actually are multi call call between a multiple person on two different.
So we had like a web stack and you know it's like full gtk and a good on base and we had like a really totally compatible video conference between like multiple person with that.
The power of example that it's not enclosed in technologies it's actually a real standard protocol that can like move around well connect really different ecosystems.
Yeah there is also social features on example this is something that I'm personally pushing for like more than 10 years.
All the tools were there for 15 years already.
We didn't like I didn't have to really create the whole ecosystem I really just will use the base thing that he's called pubsab.
So pubsab is quite simple it's a system where like on the on the internet so on on the network example in network.
You create nodes where you publish information on those nodes and people subscribe to them and like in real time when you publish something it will be.
Pushed with the others there is two kind of pubsab there is like the pubsab what we call as only if he's there it will call.
But which is like your own personal so as an account you are you have your own personal pubsab servers where you actually are hosting on your own accounts notes.
And you have also a way to like create those nodes on the example in network in general.
So for example if you want to have like what we call in modern communities where you have like a like a place where multiple person are publishing on a common blog.
You can just say okay I want this node on the network and then you everyone is publishing on it.
And each ability is actually implementing quite well the pubsab system and skills crazy.
It's like you can have like 100 of ties on maybe millions of subscriber and you can actually just like do that quite easily.
And one of the little thing that is like so quite fun with a movie is that actually we have a little tool called atom to pubsab where you actually take a recess and atom feed.
Put them on the example in network and then at this scalable system where you can actually like push like articles to like 1000 of person without any like volume issues.
So this is a little example about how it works like for a john on the on the network so you got there those those.
The pubsab node to the blog and the story is now so you can see like the node is actually having a space by itself.
And it just publish new items on those elements and you can create easily like new kind of system.
So I was thinking about like a gallery system you know like Instagram so you can just create a new node define what's in it and then automatically all the other clients that want to do that they just have to follow these tunnels.
Most of the social future published on XMPP are based on atom.
So it's pure XML, it's not XML, the same thing that you can find on the web you just take the XML just put it on XMPP.
I don't typically it works you don't have to do any translation or things like that.
And the other way around moving is actually creating atom nodes.
Atom HT HTTP URL from that.
And it's just cross compatible so it's super easy to say.
Okay, I have my master not accounts. I have this RSS feed, pre-tony XMPP and this also.
Yeah, so fully compatible with lot of XMPP server and yeah, I will show you later in the next conference why it's quite different than activity type actually on this specific case.
So one can we expect in the XMPP ecosystem this year.
So on it's about it, we are currently working on distributed maximum, it's multi user chat, it's basically group chats.
Right now in XMPP a room only exist on one server.
You can access it from any server in the Federation, but if the server hosting the room goes down the room is gone.
So we are developing this room between Mac when you have several instance of the same room on several servers.
So this is something that already exists in some of our protocols, but here it should scale.
Because first we are not sinking in storing the war combination history.
And second, things to an algorithm that were described in a paper published in 2020-24.
So it's quite recent called right-lace in vertebral bloom look-up table, which has the advantage of being CPU efficient and as near bound with a similar usage.
So thanks to that, we should be able to survive next split by thinking the room state and the room history even on huge rooms.
So this way we should be able to get rid of the room being a single point of failure.
And we have some fresh news because the XMPP summit held by the XSF was held here in Brazil just before the first day.
So we have discussed on stuff that should arrive hopefully quite soon. We have the spaces.
Yeah, so we'll tell you just a couple of minutes about that.
So yeah, it's basically what you think a space it is, so we are actually bringing it to an XMPP.
We have the improvement in the group chat encryption.
Yeah, so right now and to an encryption once came in big rooms.
So we are implementing a new mechanism to be able to do a intuitive encryption in big rooms using Thunder keys and later MLS for those who knows.
We have some, yeah, so this is already kind of working, but it's not standardized yet.
So we have like, measured, as we said, as I said, like the multi-user core system, but with I-SFU.
So just to tell you, I said, you send your video stream to a server that actually broadcast the video stream to other people, then you don't have this bandwidth issue.
This is something that works everywhere and I really work on XMPP.
Like JCC is already doing that, but we want to standardize it and actually implement it more in the XMPP clients.
And we want to be able to do XMPP over quick.
So quick is an UDP-based protocol that does faster connections to the server and is better suitable for low bandwidth environments like radio, radio transmission and stuff like that.
And so we want to be able to do XMPP over a quick in addition to other TCP or other web sockets of HTTP and stuff like that.
So with XMPP, we have true decentralization.
We have the only protocol that supports and standardized instant-pissation, social voice in one unique and federated and current network.
And we are massively scaling as you've seen with the example of deployment at the beginning.
So if you are developer, find a library and start coding.
If you are a citizen, you can find your perfect server and if you have a simple user, check for a client that will sit you.
And you control your data, you can host your own server and communicate with other server via Federation.
Thank you for your attention and if you have any questions, you're welcome.
Thank you so much.
There was no one question.
The question was, in what way is XMPP federated and does that mean that XMPP has to deal with state resolution issues?
So it's federated in the sense that let's just repeat the question.
In what sense the XMPP is a federated protocol.
Actually, you have your account on a specific XMPP server.
But all the servers, participating in the Federation are communicating together.
So we have server to server communication.
So it means that even if you have your account on any server, even your own server, you are on hosting at home,
you can communicate with anyone connecting to any server, participating in the Federation.
So it's like a big mesh of servers communicating together.
There wasn't a question. That's all.
About state resolution, I'm not sure I get it, just no.
It's a concept to make sure that you know who is allowed to be where in the different rooms, which I guess doesn't apply in XMPP.
It's specific to room.
Yeah, the room is not working the same way in matrix, because the room is distributed.
And this is why I was talking before, because we are implementing some distributed macromes, but in a different way.
So we don't have to match the worst state of the room right now, and we will implement a different mechanism here.
That is similar to matrix, but should scale better.
Yeah.
Yeah, okay.
So first...
Yeah, what the matrix, why it's quite successful, and does XMPP want to copy or inspire from matrix, right?
And so first, in Italy we have a matrix implementation.
So we can do several protocols, and I think the main stuff is again distributed room,
we can have a several instance of a room across different servers, that we don't have currently in XMPP,
and this is why we are implementing it right now in the Germany.
So I think this is the main stuff that is missing compared to matrix right now in XMPP.
Thank you.
Thanks for watching.
All right, so now that we have seen one of the strength of XMPP and probability on how this type works,
we are going to see a very two-week case of how to build a software network on top of XMPP.
Yeah, yeah, it's a string.
So welcome everyone, so I'm Timote.
I will show you a bit about a movie.
So one first question for the audience, who knows movie, who are the herd of movies there?
Okay, so we do have a few a person that are aware of this thing.
So I'm also introducing the new logo, new design, new mascot, and everything.
I've been working with a good friend, it is doing all the drawing and design about that.
And I will have maybe stickers for the next fall then, because it was a bit upset like this.
So I'm Timote.
We can also know me as Adelaas, and I'm being meeting movie since 2010.
There was a lot of chances and evolutions.
Back then I was just learning PHP and how to do web stuff and then I grew into the XMPP ecosystem.
And now you will see what's the result after all those years.
And I'm also, yeah, cooking, I like to cook like kish.
I think I don't always say in English.
So what is movie?
My movie is actually a social platform that connects between the XMPP world and the web world.
On the XMPP side, it's used to have some, we used to have an XMPP like web socket and HTTP request
to directly do XMPP, but now it works like any XMPP clients.
So you don't even have to configure anything.
You just start movie and then connect with your credential and it will just connect any XMPP clients.
And it provides you a real time interfacing your browser, browser that can also be put on your phone as a progressive web app.
So it's like a really kind of native app that's fully responsive.
The goal of movie is actually to create and expand all the social feature and a bit more you will see later on XMPP.
And no in 2025 and 26 will start to see other clients.
I was able to convince my friends about the fact that social features can also be interesting on XMPP.
So there is three axes about movie.
So the social networking, as I said, the instant messaging, obviously because like I will not prefer also to use although I have some XMPP feature about instant messaging.
And more recently like the video conferencing feature because I saw that there was a lot of nice things to do on this part.
And actually a lot of people that were also looking for alternative than teams or zoom and all those kind of platforms.
So technically it's based on the CPHP, CSS and JavaScript. There is not a lot where like React app is quite light and simple.
Database wise polygraph skill and MariaDB, but please use Postgres works way better.
It's quite lightweight and yeah, I do have about two releases per year.
So one question that comes quite often is like what actual difference between activity and on XMPP and how social networks are working there.
So I made this little graph like two graphs to actually show you the difference.
So from my point of view activity pub is more like a platform first system.
So the activity pub protocol is actually defined between the platform.
So you create an account on the platform and then the platform through activity pub are interconnecting themselves and exchanging messages.
So basically peer tube will have to understand on top of activity pub.
Okay, what must to do is actually doing on those things and same with pixel feeds, so it's like an Instagram light activity pub system.
An example is the other way around actually so you have accounts and you do everything through your clients on your account.
So it's just a view of the XMPP network and then there is an interaction in the XMPP ecosystem.
So it means that all the interaction the XMPP ecosystem are standardized.
So I will show you just after what a story is a story on it's not a modern story is an XMPP story.
So it's quite easy for a new client to just implement the startup and then be fully compatible with all the others.
Yeah, so you see actually for the question that we had just before that we actually have an interaction between the servers.
So this is in January and Prosody, one of the main servers.
So what we call S2S server to server and client to server is what can be the same like email.
You know, you have these email servers and then Thunderbird or Outlook that are connected to your servers and your account on the server.
So yeah, one of the drawback of I think activity pub is that, and I add this issue myself is that you have to create an account on all the platform.
You basically have one account on master normal, it's a bit more difficult to find where actually your data is.
And the XMPP, when you remove your account, you basically destroy all all the information in one unique place.
So what's new in a little story is a thing.
So what's was introduced in 2025?
Pub sub stories.
So as I said, for those of you that were there for the previous presentation, it's just at 1.0 and Pub is subscribed.
So I will just repeat quickly what is very subscribed.
It's like a pub's published subscribe system.
So you create nodes on your accounts or on the network.
And then you publish information there and people subscribe to it.
And you can manage the node, like configure it and put like another tower and all those things.
And then the information is actually spread across the whole network in real time.
And stories where actually came like last year and there is already two clients compatible.
And I've talked with a couple other clients that might be also interested to add stories.
I see someone in the room that is there for that.
So just diving the protocol, that's actually a story.
As you see, it's super simple.
You just connect to your XMPP server and you publish a story.
So I'm publishing a story to myself.
So this is me, oh, by the way, it's the mascot.
So you say it's a pub sub item that you publish on the story node.
So you're an example is actually namespace on the story.
And then inside you have your item.
It's just a simple atom item with a title.
So it's basically the little text that you have on your story.
Some ID, some time.
And obviously the picture of the story that you created on your clients is super simple.
And if you want to make a error set for item.
And a few of that is directly just to take your database and then recreate.
And I'll be in that.
Something that also came in 2025 are the multi-party jingles.
So it's something that I did with the NLNet findings.
I really thanks to them.
I was able to really spend a lot of time on this to really integrate in the web.
You, I, all those features.
So it, as I said, it's fully compatible with already another client or able to call with multiple
person with desktop clients and a web client easily.
And I added also a similar to Webcam and screen sharing.
There is a little example that is coming from to actually tag those things.
So you can actually share your screen and your webcam at the same time.
So for a presentation like this is actually quite useful.
Or if you're doing streaming maybe you will have like a twitch light,
like system on moviem after.
It's where we've already seen this.
So it works like just in all the browsers and other days.
And yeah, as I said, it's found that by NLNet.
So yeah, that's the mobile versions.
And yeah, I will tell you a bit more about that for 2023.
What's actually came in 2025 is the improved social flow.
So yeah, I actually created a new step that was upgrading
a really old one that was called micro blogging.
Because for 15 years in example, the only kind of thing that was about social
feature was micro blogging.
There was a micro blogging example.
So I said, okay, let's take this thing.
Make it more general and call it purpose social feedback.
So it's like a more generic.
Okay, you put a turn on Pubseb.
And stories, the stories are one of the sub thing of this thing.
Of this, perhaps, sub social feedback.
So it's stories basically.
Pets also have field class.
You must publish one picture at least in your item.
Because a stories, obviously one picture.
So it's super easy to make it extensible.
And add new exact on top of that.
And to implement something like you just need like a simple example
parser database and then you're done.
Something that was added in 2025 is to follow everyone.
Because you used to have, we used to have this system where actually you add
a, you need to add the person has a friend to actually follow it.
And now there is just a follow button follow and follow.
And I open a couple of things in a couple of tickets in the example
service to ask them about Pubseb missing feature.
Basically, it's the follow or feature.
For now, you see some of, well, the follower,
but you are not satisfied about it and you don't add the counter of followers.
So if you are an influencer and you want to come to example,
you will be happy to add the follow or counter soon.
Yeah, there are comments and likes will be as being a redesign.
And I introduced the briefs, which is basically like,
an art, because in a movie, you were producing articles with a title in the content
and people that were, like, on the other social network like this.
I wanted, like, just, I want to post one text.
So I brief it like a smaller, like, article that you can just easily publish.
Chats.
Yeah, so I did not only work on the social feature, I also work on the IM feature.
So there is a message, it's a research per content.
So that's thanks to pause your skill that can easily index content.
And you can just type any keyword and search your whole history.
Works with, like, millions of messages is quite impressive.
There is a new navigation bar.
So on the right there, you actually have, like, all the connected person.
You can click on them, like, send them a private message.
Like, things that you see, you see on many other platforms.
I work on our URL resolver.
So that's a little technical thing, because on moviem.
So when you start a moviem instance, a bunch of people can connect on this instance.
So you can have, like, 20 person that are connected on a one-way instance.
And those 20 person can be in the same chatroom, obviously.
So if someone is sending a URL, it's used to have, like, all those person requesting their URL
to have this little card.
So the poor guy that actually have the web server will have, like, 20 requests.
So no, there is a worker for that, that you can, there's some menu URL.
We'll resolve the card and actually give it only once to, like, everyone.
It works really well.
And really, really help, especially when you load a story.
And you have, like, a lot of means that we're share or things like that.
And you have, like, a 50 URL to a result.
There is a negation flow that was quite improved, like, especially on mobile.
It's quite difficult to pack all those social and IM features.
So there was, like, some mostly, like, touch feature that we're introduced to actually make it, like, more easy to work.
And a little thing that I was added at the end of the year is shortcuts.
Something that you have in this code, I think, is basically, like, on the left bar if someone is,
like, you know, or you are quoted in a chat room, you can easily have, like, this quick button that you click to go directly to the, to the conversation.
Yeah, there was also many other things.
So as I said, I'm still using, I'm still supporting my IDB, but I dropped my SQL, because those two of the bases were coming this way.
And I, it was, like, too much work. And I actually, I didn't add a lot of professionals were using my SQL.
So please move to my RDB or, possibly, SQL for that.
It was upgraded to PHP, the two that actually improve a bit the performances.
There was a fully refactor notification system, because a mobile is actually doing web push.
You can have push notification on your phone and your devices.
And yeah, no, it works really well. You have the conversation.
If you actually read on one of your browser, actually clear the notification, because you read it and all these kind of things.
I added the pronouns in the profiles.
I saw that it was a, there was a, a new RFC with new kind of things in the vehicle.
So I said, okay, why not. And I have a friend that is actually doing, well,
slidge, that is actually doing a bridge. And we work quite a lot together the last year with bridging with the telegram,
WhatsApp, discord, and a couple of other networks.
And those are, like, those kind of information.
So actually, why not to actually show it in the mobile UI and fully stand out.
I'm using the material design from Google actually to do the whole implementation.
So I did a great to the latest one.
And I redesigned the mobile to you and joined the mobile to you.
So join mobile to you is a bit like the master, join my student.
I think page for basically if you have a mobile instance, you can easily register your instance on this page.
And then someone that is like want to join the mobile network actually see like many instances.
I can pick one, he wants based on the location or like a specific aspects.
Okay, what news for 26, because I'm will not stop there. I will do more stuff.
This is a technical thing.
The mobile architecture is full real time.
So yeah, I'm actually doing a full real time things in PHP and it works really well.
But I used to have like 10 years ago, like blocking code.
No escalator requests that were like a bit long or like resolving URL and things like that.
And if you put everyone on the same like process with blocking codes, then if one guy is joining is connecting on mobile with a lot of friends and lot of synchronization today will slow down everyone else.
So what I did back then, I was a bit like I had a simple solution to say, okay, everyone is actually adding a PHP process and I have a
A demand that actually roots everything.
That works really well for 10, 15 years, but the thing is like each PHP process is actually copy pasting a lot of information like the whole movie.
The whole movie, a system in memory.
So now I'm actually introducing into the 26 are in between system where actually people are you have worker where you have five to ten people on those worker because the code was optimized.
No, it's not blocking anymore for a lot of things.
So you can actually share a process between other person.
So that's why I say 80% of them are just because there is five percent on each worker or ten and not one only.
And I did some tests and the performance impact was minimal and actually you can never save up a lot of memory this way.
So I'm not having like five kilobytes like on each property like per new perception, but it's actually really helps especially for more server.
And we all know how the RAM price is now, so it's always good to have like a little optimization on this this part.
So what's news is also on the video conference in part is the last step of the MLNet funding that hired.
So I had three steps on this funding. The first one was to just modernize the video calling system.
The seventh one was to bring muji, so multiple, but it was full clear, clear video call.
And the third step is actually to add the ISFU.
So who is who knows about ISFU? Do I need to go have a technical there?
Okay, so ISFU is basically normally on the the current system is like this.
So if you go five friends in a room like you're sending five time your video stream to everyone.
So you see for two three person it works for audio it works well, well quite well up to ten person I think.
But you see that above that it's not possible especially on your mobile you will send like a lot of data for nothing.
So as if you're quite simple is that you actually have like one server that takes the video streams.
And sometimes the company compresses it sometimes makes it sometimes like yeah do some work with it and then send it to the others.
So then you have like a minimal impact on that.
So for this part actually I'm not rewriting it I'm using like I will use a product called Galen that was also funded by NLNet that is a really well made as a few in a go.
And then they will it will be wrapped in a jingle and example and then we will work with movie and the nice thing because there will be a standard about that it means that other clients can easily reuse that.
Plug them to their example user and then do video conferencing massively with with example.
So you have a little screen shot also of the best of you of this video call system.
And the goal also of movie is that it's easy to deploy.
If some of you are deploy like at gc system it works quite well but you have a lot of blocks to connect to each other.
Movie the goal to that is like you just and still the movie projects start the demand and automatically you have all those feature built in.
And the big thing that is coming are the spaces.
So just to introduce spaces I think there is that already on many other things including matrix.
It's basically to group chat room together to have like not only one room but group of rooms where an illustrator can actually play with with them.
So there was already some work done and we are like working as a system and implementation and we just have to know do it.
The good thing is that it's fully retro compatible so for the many example clients that don't do that you can actually join some of the room of the whole space easily.
One of the first goal that I have in moving with this is not read to build the whole discord or matrix system but actually to have those chat room where you have audio and video room below it like you have on a team speak or a member that you can easily have like on your audio of your room.
So it will be a small space and then after that it will expand on it.
So it will basically mix the SFU system and the space system together and yeah lots of other things that are planned after that.
And that's it I think.
So I was quite fast.
So yeah that was a long year with a lot of work done.
And the example is that we are just just before the first time actually brought a lot of new interesting topics to do for this year.
So I hope that moving will be like one of the nice platform that you want to try in 2021 and yeah I'm joined and see if it gives you like nice nice features and also.
And something that I forgot I actually continued to work with the bridging system so we did a.
Yeah we did a lot of a lot of work with the bridging system so actually moving really interesting really well with discord telegram what's up and a few others.
So I didn't show you but like on my accounts basically I have all those platform in one unique UI and fully bridge with the others.
And I think really well integrated you have the reaction you have like the history management, the file management and all those things.
And one of the goal of the spaces are actually to integrate also with those I treat to see the discord spaces inside moving with maybe the matrix spaces and all the others in one UI.
That's it.
So if you thank you for everything there is some good is there and more on the other room.
I will be available if you have any question but if there's already some question in the room I will be happy to answer you.
Wow I was super clear.
So yeah.
So the question was about how the bridges are working so you have different kind of bridges.
In Japanese it's actually implementing sampep and maybe matrix and act as a matrix server.
So that's it's very easy to complete transparency but the sledge project is actually acting as a client to this network.
So basically when you are installing a sledge you are installed on your example server and you provide new what you call services which is like from movie.
But you I have like telegram that movie that you WhatsApp that movie you discord that movie in the queue.
And you provide your credential to that or like like secure authentication system that actually connect for you to the discord.
And then sledge is basically translating this to example.
And your example is series basically showing the clients pure standard example things.
And that's really nice because once you do that when you plug it then the whole clients connected to it actually see the discord like ecosystem.
As an example.
Yeah that's it.
It's quite tricky because I know that my friend have to follow how the discord changes and telegram all the time but it works really well.
So yeah.
Is there more questions?
Yeah.
But yeah.
What's good is about the front end.
Yeah.
So I'm just like.
You will do so many stuff.
Have.
Yeah.
Perfect.
Actually.
Yeah.
That's a really technical question because I can actually show you how it's done.
It's simple but yeah it's on the front end is pure JavaScript and CSS.
And actually most of the states are built in PHP and pushed in real time to the.
So I think when there was a react at the beginning it's like let's do everything in the browser and at one of the guys say yeah browser I quite slow.
So maybe we can generate a render some of the stuff server sign and push it.
Well that's the thing.
It's like PHP can actually do easily like a lot of HTML.
Like so there is a website and then when you for example receive a message.
Movim is parsing it put it into database.
And then create a little HTML.
Think that's a decade.
This is a new message.
It's roughly said because it's a bit more complex than that but yeah that's it.
So that's how it is that's why it's simple and I made like a little too.
I must not like a couple of weeks ago is showing like difference between this core and moving and we have like a.
In this case like 200 or 400 megabytes and movies like 20 or 30 megabytes in the memory.
So box quite well.
Yeah.
Do we have more time for questions or.
Yeah.
All of the center of the.
Who home.
Oh.
So it's.
Yeah.
So the question was about who host the SFU server.
So that's your choice actually.
You can normally it's good to host it next to your XMPP server to actually for it like as a service.
But you can actually have it like on another network and then collect to that server.
So each imagine you have like a small example server on your Raspberry Pi.
You cannot easily reencode video on that thing.
Then you want to have something in the cloud.
You can actually say, okay, this is where you should go to actually call the SFU.
And then just do the XMPP routing that is quite lightweight between your Raspberry Pi and the cloud server.
So that's one of the goal.
The long time goal with movie is that maybe to offer some kind of.
You know, video call service like this.
Where actually maybe you paper like a bit to actually.
Make the server runs and then after that, like you have just the XMPP on top.
So you use the clients you want.
Yeah.
I want to use asking.
The SFU feature is pretty cool.
And I hope the development goes well.
Do you think we'll get the next XMPP?
Do you like the frame of the post them talks next year?
Ah.
Yeah, maybe.
Maybe.
We have actually I'm quite confident about the Galen.
Galen works really well.
Yeah.
It's a little goo binary.
It's quite magical.
Like what a format I tested.
So maybe.
Because I think for them is about scalability.
First, like you want to have like everyone connected.
So yeah, maybe it could be done.
One of the goal of movie, as I say, was to bring the old zoom and telegram experience.
Because I'm not far from that.
Because you can actually do that in the browser.
So having like a URL invitation system that you can send your friend.
And then they create an anonymous account.
Just for the call.
It's super useful for that.
And then at the end, you have a little like button to say,
Hey, do you want to create an actual XMPP account,
which already information to actually join next time.
So that will be a really nice thing to have like this little unique URL.
We'll be just enjoying.
And then do a bit of XMPP and have this nice conversation.
And I saw more politically.
I saw like the bit of companies and big government.
Like government interested about that.
Also with the European Union and zoom and all those things.
So maybe it's time to build those kind of solution in Europe as well.
To actually say like look.
We did something similar, but actually better because it's turned out
and fully compatible with a million other clients.
Yeah.
So maybe I would be interested to see with the thousand people if it's doable.
Yeah.
Any other question?
I think we still have a few minutes left.
Okay.
So if you have more technical things or more other questions to ask,
I will be on the XMPP, both the rest of the afternoon.
And you're welcome to actually just go on the movie website and try it out.
There is also a move that I am that is the main instance.
You can just create an account and join and try it out there.
That is quite easy.
And if you have any other XMPP clients, everything is compatible.
So just try it.