I was definitely not expecting this.
You got both, man.
Yeah, thank you for being here.
So we're going to talk about IRC in 2025.
Maybe you've heard about IRC, like 20 years ago or something.
Not heard about it since.
So we're going to show that we're still working on it.
We want to modernize it.
Yeah, we're going to explain how.
So yeah, let's start with some people, some young people might not know what IRC is up for.
Maybe you've seen this XKCD before.
So basically this guy on the right, it's me 80 years old.
In the future, maybe.
So why IST using IRC?
I guess it's a question of personal preference of communities.
Like it's a community as some professors.
Which community is some vibe.
So diversity is a good thing.
And yeah, let's use what we like.
So what was IRC like in 2023?
Well, back in my day, IRC used to look like this.
No fuss.
Not so many features either.
So IRC in the back in the day is 20 years ago was mostly on desktop.
There were no easily, well, 20 years ago smartphones were not widespread.
But I mean, it was mostly desktop clients.
Terminal clients, not quite easy to use.
Have to learn a lot of commands, configuration.
If you're using a second desktop, you have to configure it again.
So it was quite hot to use back in the time.
And this is maybe what you remember from IRC.
It has a lot of the lot since which is the purpose of the presentation.
Okay, so what are we talking about here?
So this is a client server, instant messaging protocol.
That is implemented by several pieces of stuff.
So we have a client.
And we have a server on the right side.
So we have several clients today.
This is like the picture today.
So we have clients on Android and IRC.
As well as the desktop and on the web.
So you might recognize some of the icons.
And some of these might be new to use.
So the pink cat is called a sentite.
And on the right, you have networks of servers,
which represent different communities.
So you have liberal I, which is web node, which replaced free node.
That you may have heard about.
And basically, you configure your clients connect to all these networks.
And you would also configure your other client to do the same.
And this is, this is nice, but this requires us to configure each client separately.
And copy the configuration over, which was a really pain point in IRC before.
So we introduced a new piece about 10 or 15 years ago.
Which is a bouncer.
It's an intermediate server that sits between your clients and the network that you connect to.
And basically, these bouncer stores your account, meaning, which networks are connected to.
And your chat messages, some message history.
And we'll see some of these features later.
But this is a key piece that makes IRC modern today.
And there are several implementations of bouncer's.
As I can see, it might be the one that you know.
But now there is so joy that is developed by Simon and I.
And this blue icon is IRC today.
This is a service that I'm running commercial, so as a service.
Just a quick note is Gamja.
And the little blue icon was also developed by Simon and I.
So we have apps about everyone ecosystem.
So now I'm going to show you what the user experience looks like.
Just so you have a quick understanding of what you will expect from IRC today if you are to use it.
It's quite different from 20 years ago.
OK.
So it's a very quick demo.
I'm going to basically spit right in IRC.
We have three apps.
I'm starting with the mobile app.
So let's say I already have an account on my bouncer already connected to several channels.
And I already have messages, et cetera.
And I'm setting up a new phone.
I just installed Googlema.
I can start it.
Yeah.
OK.
I can start the app and enter the URL of my bouncer as well as my credentials.
And as you can see, it immediately synchronizes all the channels that it downloads from the bouncer.
There is no prior state in this demo.
So I didn't have to do slash network connect, et cetera, that you would expect in 2003.
I can open a channel.
The messages are immediately downloaded from the bouncer.
No prior state as well.
I can fetch the history, infinite loading.
Just as you would expect from a modern app.
And I can now let's say a friend of mine wants to talk to me but on a different network that I haven't added yet.
So I can add that from my clients.
So as you can see here, I have a list of networks that I'm connected to.
Libra, I have to see a reason that you might know.
Let's add a new network.
Agle, which is a new basically standard network for a new server.
OK, it's added now and we're connected to it.
So immediately, so now we can ask our bouncer to connect to a new channel on that new network.
Hashtimo.
OK, it's in a message.
Hi there.
And we have a friend there that we'll reply to us in this demo.
Oh, hi, Mark.
And as you can see on the top, we have a typing notification.
We know he's typing another message right now, which is quite nice.
Could it send me a picture?
So we can actually send pictures from our client now, in a standard way.
OK, we can share a file.
And as you can see right now, it swapped my file for a URL.
Because the file just got uploaded to my bouncer.
This is much easier than it used to be 20 years ago when we had two upload files separately on like
Inger and then get the URL on back.
So much better.
And then when I send it, my client friend does the preview and the same on my friend's device as well.
OK, he doesn't seem convinced.
Let's reply to him and ask why.
And reply to the message by swiping and type an answer and then reply me.
And then as you can see, it refers to the message that we've sent earlier.
And I can click on it and the message is highlighted.
So again, reply to any of you.
You wouldn't have that 20 years ago.
OK, so that was a good one.
And let's say I just closed my phone for a few hours now and the app.
I just closed the app and the app was completely shut off.
No connection to the server.
The battery being easy on the battery.
So we just received a message.
How is this possible?
Well, we just received a push notification.
This is new in our C as well.
For messages as well, which enables us not to have to download all the logs from months back.
And just basically, I just connect to it with that prior state here.
So quick search as well.
And also have typing notification as well in Sendai.
Last client.
And this will be the end of the quick demo back to payment afterwards.
This is our web client called Gamja.
Seeing a part on with Google Man Gamja.
Both names of Korean for Tito's two different kinds.
Okay.
Gamja is a web client.
So this is running in the web browser.
But you don't see the web browser frame.
Just the way I captured it.
So again, using the credentials to connect to my server.
And you can see as well.
So it's a bit small.
But so no worries.
No need to actually see the text.
But you can see that in synchronizes the network as well.
And as you can see.
Well, you can see that something turned green on the left side.
The bottom of the list of the buffers on the left side.
This is because I received a message.
So this client is telling me, oh, you've served a new message there.
Okay.
But instead of applying on my web client, I will apply on my desktop client.
Because I also have it open.
And as you can see now that I've applied on my desktop client.
The color is now right where I point my cursor.
That because this client knows that another client has read the messages.
So now I can synchronize where the messages were read.
And I don't have duplicate notifications on it's client,
which used to be the case as well.
Right.
Well, I believe that's it for the demo back to you Simon.
No, yeah, go ahead for watching this slide.
I'm just, so what did we see, basically?
We saw a lot of features that might appear of just to you.
Due to the way, I mean, this is just a modern instant messaging app right.
But it took a lot of effort to bring it from the 2003 screenshot.
I'll show you.
Show you to what it is today.
So how does this work?
So basically, every feature and we have like 10s of them.
Since 2003, tens of them were implemented.
You have, for example, a feature for a chat history, a message history, I mean, etc.
So each feature, we still have a lot to implemented and standardize independently.
So just quick notes.
So we have features in four different categories typically that we so just now.
So for example, planning features that, for example,
ink increase have made the connection time and load time overall better.
We, for example, and then we have manual processes that were previously quite annoying to do that
on our automatic, for example, operating files is now instant and standard, rather than going for an external
website.
And we have new user interactions, replying to messages, reacting to messages in the future, etc.
Dipping notifications, informative device mobile.
I think this is the most important set of features that we've added.
We have history of messages with no prior state downloaded dynamically from the
bouncer.
We have searching messages server sites.
We have synchronizes the state of our metrics that we're connected to.
And I think those are really powerful features that we've added to IRC.
We also have personal notifications that Simon will expand on just afterwards.
That's it for me.
You're new Simon.
Yep.
Another of what is standard IRC.
So, how do you, how do you, how do you, how do we,
what we expect in practice?
So, instead of designing my community, which is done sometimes, we start by experimenting.
So, we implement Vembal extension extensions in our clients and servers.
Then we see how it works.
We discuss with other people and ask if I would implement something like this in the on clients
servers and iterate like this.
Then we submitted to IRC before.
And if we get enough acknowledgments, we can publish it.
So, this is really interesting because we have specs that are interesting to many people
and really work in practice.
And we think consensus and all the parties.
So, let's take for example, let push as an example.
So, what push is extension used for push notifications.
We had the bunch of constraints in mind when we designed this extension.
That's one is it's fully decentralized.
But I mean that that is each IRC server is to send push notifications to a particular client.
There's no one server, but send it to the push notification.
So, we need to work with that.
Second constraint is that we need to interrupt interoperability with Google and Maple and also Unified Push.
Because, under it, for instance, if you didn't go through Google, then your app will just not wake up.
So, that's really something that is mandatory.
So, because we go through Google and Maple, we wanted to use an encryption for notification payloads.
We didn't from Google and I thought to be able to see your chat messages as it basically.
So, the good news is that the web, although we already solved all of these problems for us,
they have a specification for web push, which is basically send a HTTP request
and then a encrypted payload to server.
And then there's a responsible for the thing to see up.
So, only kind of missing piece was interoperability with Google and Apple.
So, we designed also a small bridge push government to translate some of my push into proprietary Google and Maple API calls.
So, the way it works is that it's a client-sense subscription command to the ISE server with the URL of the web push server.
And when the server receives a message, why does the ISE client is disconnected?
Is there a HTTP request with the push notification all of that encrypted to the web push server?
And the web push server is responsible for delivering the push notification to the ISE client,
which is working up by this mechanism.
So, at the protocol level, it's quite simple.
So, so, what is a private key, a public key.
So, I client-ense and the web push register command with the URL and a bunch of keys.
And then the server would like success.
And the push notification contents are basically just a standard ISE message as well with text message text.
So, if we have Google, I call it in the picture, then it's a bit more complicated,
because the push server is a web push relay here and the bottom right.
And the web push relay is a message to, for instance, file-based messaging for Google.
And file-based messaging is responsible for working up the Android client.
That piece was that one by Simon as well.
Yeah.
So, yeah.
Our virtual plans are experimenting with end-to-end encryption,
and maybe experiments also with avatars for users and such.
That's about it.
Thanks a lot.
So, kind of sounds like you have this trying to meet the new key ecosystem between your clients and your clients,
or do any other clients and clients that actually support all of these extensions.
Yeah.
For instance, our goal server is also implementing a lot of the modern stuff.
So, web push and red markers and combination.
So, if you use all the servers, maybe you don't get all these night features,
but if you use a no-don server, then you can get it.
It depends what you use.
Yeah.
So, why is it standard?
Not just a property.
It's very protocol that we're building between our bonsar and our clients.
Well, standard is only as good as the implementation bar.
Nobody influenced it.
Yeah.
So, yeah.
I mean, hence the process to first experiment with actual clients,
and then come back to those extended program organization,
and then go back and implement it in all the clients, as well as the system.
Also, the thing we've suggested is that even if you use all the servers,
you get all the night features, too.
And you're free to use all the client, which doesn't support the new features,
and use it with the bonsar.
Good morning.
How does the migration story look like?
Good morning.
Right now, I'm running the Excel server.
And all the stuff that they use, they're all provided by the clients.
If I want to move to the soils, please, there's some weight.
I can bring over my own chat history and everything.
Unfortunately, we only have a migration script for the DNC,
but I would recommend the contributions to develop a migration script for Tocacela, as well.
Yeah.
Just one observation is that much of the benefits are focused on the hosted bonsar setup.
But the next two value, a lot of value, on the client's talking directly to the server,
because as a client, I don't have to post anything or take for anything,
and just get whatever the server can get.
So maybe they store two weeks of passage.
And that's why I'll get it.
And I can get it stored then locally.
But there's no bonsar involved.
I don't have to set up one or people one.
I agree that it's still an important use case to support.
And if you can use any of these clients, directly connecting to a server,
and it will work, and the error supports a lot of the modern features as well.
I guess the key reason for using a bonsar is not just for introducing new features
to server that don't support it, but also so that you couldn't connect to multiple networks,
as well, at once, without copying your configuration again.
If you connect directly to a server and you have a mobile device and
another device is in your desktop as well, and you have to connect multiple servers.
That's a lot of configuration to write and replicate to all your clients.
So it helps to have some kind of centralized place for all configuration on your networks,
which enables I have to be decentralized and not always use one particular server.
Thank you very much.
Thank you.
Thank you very much.