Playing with Rujan?
Yeah.
Hello.
Welcome to another exam paper talk.
So, I'm Azjan from Istanbul.
And I'm not actually working on an exam paper or like the centralized communication as my first job.
But I have a story about implementing this feature to Dino.
Yeah. So, just imagine about the year 2005.
Unfortunately, it's a proprietary, but MSM Messenger was king at the time.
But you could use it with pigeon or AMSM free software.
And there was a feature, if you remember, you can see what your friends are listening at that time.
And like, if you see Iron Maiden under someone's name, it's cool.
So, it was the golden era of non-playing.
Like, so many protocols and so many software had support for it.
I mentioned about MSM Messenger because like, it is Istanbul, it was the standard.
But it can change place to place.
But the MSM Messenger was using a proprietary app from Windows, the Windows Media Player.
It can only show what you're playing on Windows Media Player.
So, like, back in my era, there was a thing.
Like, you open a cool song from Windows Media Player, just make it silent.
And you listen your ordinary music from another.
But the thing is, pigeon, AMS and an adium.
Those are like, it's MPP clients, but also they support MSM Messenger at that time.
They had some form of music sharing.
But then, it suddenly disappeared.
Like, the MSM Messenger and similar protocols are gone.
And mostly mobile messenger, the messaging like apps like WhatsApp or telegram, takeover,
like the communication, the instant communication globally.
So, that kind of centralized applications never had, like, such feature.
And the streaming services were popular, still popular, but I'm talking about the time.
And they have, like, I'm aware that Spotify, let's say, have a feature to share it.
But it's within the app. It has no, like, API or connection with some other app.
And it's MPP clients or a proprietary app.
So, within the time, we just forgot about the story.
And it's now a nostalgic thing for most of us.
And I use XMPP with all memo, like, in a daily basis.
It's one of my main communication mediums with my friends.
And a few months ago, I was talking with Alper, a friend of mine from Istanbul,
and we figured out, like, we were just chatting about something else, like buying a CD.
And we figured out that we are listening the same song at the time.
And it was funny.
It's a song from an old Turkish symphonic metal group.
It's a great band, by the way.
And I suddenly remembered about this.
Like, if it was, let's say, 15 or 20 years ago, I would probably know that he's listening that song.
But now it's a coincidence method.
So, here comes the question.
How can I bring this now-playing feature from back in the era to my daily client, like, today?
And before doing a research, I started to contemplate the protocol, like, how can I do this?
Like, yeah, XMPP uses XML and stuff, how can I build it?
And, you know what, the specification already exists?
There is an XCP for that.
It's used to, by the way, I said last updated 2006, but it's last updated this 2020, actually.
But it's just a tag update.
So, for years, it was not updated.
So, I discovered this.
Then, I started the journey, because I'm not professional on XMPP in the protocol.
In the protocol itself, or the clients.
I just had an idea to implement a feature that I love in the client I daily used.
So, first part is discovery.
I know that the protocol exists.
It's the way you two use old.
And I realized that it's very implemented in my daily usage.
I know it's implemented, but it was not supported.
In Dino, it was not supported in conversations.
And it was not supported in my server.
So, the standard defines simple things.
What you're listening to, basically, the track name and the artist, which album, is it from how long the track is like the length.
This was the update in the 2008 by the way.
The rating of the track.
Like, if you have stars on your local thing, you can share it from one to ten.
And much more by the way, like the metadata is huge.
Like the genre composer, performer, lyricist, so many things.
It's build on a widely used standard.
Like the personal event in protocol.
It's basically a pop sub thing.
And almost all extent key key clients have this implementation and using it for status, mood, etc.
So, the protocol part is okay.
Simple, basic.
What the problem is.
There are clients, for example, Pigeon.
It has great support on user too, but it sucks in a memo.
And, you know, we need to make a balance.
I decided to implement it in Dino, but there is another question here.
And here comes the research part.
How do I know what's playing in a system?
My client does not play music.
We play music in certain sources.
Like, 5x, 5x, VLC, Lollipop, M-M-E-P-M-P-D.
So, how can I ask them?
If it was in like a 2005 using Windows, a proprietary box, the API was there.
But we need to implement it in GNU slash Linux.
So, after that I realized, if I play a song from any app.
When you click on the post of your menu, the sound menu on your system,
you will see some controls and the name of the song.
So, it must come from an API or something in the system.
And, I know a friend who is a web developer was worked on it.
So, a client asked them to like some of our users once this controls.
So, can you implement stuff?
And I asked him, he sent a module that will open network link to me.
And after that, I made a research and there are certain APIs for platforms.
In GNU Linux, BSD, we have D-Bus for interpress communication and Empress under it.
The Android has Mediation API.
Windows has something but we don't care.
And, not surprisingly, my co-S has a private API, so we have no idea.
So, my main targets were Linux, GNU slash Linux and Android.
So, for Dino, I will use D-Bus.
So, this is the standard.
Mediaply removed, interfacing, specification.
And almost every media player speaks it.
Like, VLC, low-epot, everything we said.
Even DRM blotware, like Spotify or whatever.
So, this is basically the flow.
We have players and they registered to a D-Bus session bus.
And they sent the details about the playing track to it.
And we can subscribe to those changes in the system level API.
So, which data we can get?
Basically, everything we need.
It sends the playback status.
Like, is it playing right now or paused or stopped?
The metadata, artist title, album, length and the URL.
And, signals.
They use real-time communication.
Like, if we stop the song, it sends the signal immediately.
So, we don't need anything else.
Empres, tells bots playing.
D-Bus, delivering the notifications in real-time.
And we have all the data.
So, it's time to write the code.
The implementation needs just wiring those.
So, this is the architecture.
We have the path, personally, landing protocol.
And in the XMPP layer, we need to just build a module that uses it.
You know, publish and subscribe.
So, when we receive a tube from D-Bus,
it will notify us and we will publish it to the server, basically.
And when someone publishes their tune, they are playing song in the server.
We will get an notification, because we are a subscriber.
So, we will just show it.
So, we need a few components.
I'm not an experienced, well-experienced, let's say, C developer.
But the code of the code base of D-NOW was like, very stable.
You can find what you need easily.
So, I realized that they have modules for each each, each EP they support.
So, I will tell them one.
And it basically defines the XML scheme.
And this is this scheme from the specification.
And we create the XML stands up.
Then, I wrote a function, publish tune.
If we create a tune object coming from D-Bus, it publishes it.
Receiving is the same.
We do not handle the signals in the EP.
The signals are handled in the system level, in the Empress.
So, if we receive any tune from D-Bus, we just receive it and display it.
I wrote the D-Bus interfaces to publishing.
This was the name space or Empress Mediplayer player.
And then, there is a dot and the app name after it.
So, as you can see, it was supported in the lib D-NOW.
In advance, there was, like, modules from D-Bus.
For example, for login, for system notifications, D-NOW was already using the lib.
So, I just needed to look who people did in the previous implementations.
For example, for the notifications.
And I basically cheated copied from them.
And so, we have a tune manager.
If, to unchanged, it handles it.
There were some three key parts.
Multiple players, what if, like, more than one player is playing.
And I realized that, basically, it's not a, like, it's not a big problem.
Because we already got, like, players in NRA.
So, we can determine which we want to play.
We want to share, basically.
Now, in this implementation I made, I only, like, publish the last one.
But it's working progress.
Rapid changes.
Like, if someone just hopes songs, like, a thousand songs in ten seconds,
it will cause, like, a huge dedos, basically, to the server.
And life cycle, players start crash, whatever.
We need to think about this.
And the biggest problem is my skills, basically.
Because I do not consider myself experienced in C,
and voila, especially, like, the GTJ graphical user interface development.
But I take a few classes to, like, build this project.
And, like, the balancing problem I mentioned is easy to solve.
If you just paid one second and nothing changes, publish it.
So, it really makes difference, basic, basic implementation.
And another problem is, like, I made the implementation,
and the backend was okay.
But where should I display the tune?
It's, it's a huge problem.
Like, I thought to put it in next to the contact list,
but it's, like, a ridiculous place.
As a separate panel, it will be,
problem, because it will be too hidden under the hood.
So, a conversation harder is great.
But as I said before, I was not a super experienced in graphical user interface,
designed in implementation.
So, I checked out the codebase about, like, what I can use.
And I realized that there is an already implemented feature
on the conversation harder about the conversation topic.
And I take that, I can just add the tune there if it's working.
So, the result is pretty much something like this.
The name and the song under it.
And this is the, yeah, it's a little bit small,
but you can find this slide in the description of this talk,
there is a link.
And basically, from Lollipop,
where we play to your friend's screen,
the Lollipop publishes the song's name and details to the debas.
The debas sends a signal to Dino.
Dino subscribes, but yeah, Dino waits for a second.
If it's not changing, it builds an XML and publish it.
Viapap to the XMPP server.
My friends, clients, subscribe to the notifications.
So, get it.
And parse the data, update the conversation harder.
So, basically this.
And after you pause the music, the debas notifies it again.
And the protocol is simple by the way.
You just publish an empty tune and it means like your stuff.
So, it publishes an empty tune and it's clear.
So, the contribution part.
I want to make it usable for everyone.
Because that's matters on that way.
And I open the pull request on Dino's gift of account.
And the reason you are about it, it's very new.
It's still not merged, but one day it will be wrongly.
And the present, like where we are now, about the implementation.
So, now this is the compatibility chart.
And I need to mention a friend here.
Because I never used Monaco's and I had no idea about like the status of it.
But I'm looking for the name, aren't probably a friend.
Just like reached me out of XMPP and said, like I really liked your topic.
And I was working the same thing on Monaco's chat to implement it in Android.
So, maybe you want to try it.
And yesterday, like you wrote it.
So, I added Monaco's there.
Monaco's is a fork of conversations.
Android XMPP clients.
And it works perfect.
So, I was trying to like, how do I like do a demo here?
Like should I use a virtual machine and run Dino there and something?
And it's all my problem as well.
So, see has built-in user tune.
But do not support on a movie well.
Gajim has user tune while uploading, not natively.
But has full-on demo support.
Conversations has no user tune, but Monaco's has Monaco's.
Use the same codebase with conversations.
So, maybe it can be like backport.
And Monaco, one of my friends is using that.
It's the client for the iOS.
And it has no support which I'm not surprised.
So, yeah.
Why it was not supported in new clients basically?
Because in mobile API is a restrictive.
Like, I tried Monaco's.
And it requires like a notification access permission.
And to give that permission, you need to like say,
I know it's super dangerous, but I trust this app for three times or something.
So, it's hard to implement.
And it's about priorities basically.
If you develop like a new example P.C. client,
you usually focus on core features,
like phone calls, maybe or encryption.
But it's not a core functionality.
It's just a nice to have feature.
Some people don't know about the P.C.
handle idea.
And time has changed.
We are not looking for it anymore.
On the server side, every modern server supports it.
But since public servers can restrict some issues,
they may have different configurations.
I tried on zero or seven F, but the E on the demo.
But I need to check the demo before my talk.
Like, 20 minutes ago, the server was not accessible.
So, I created new accounts on x.im.
And it's supported as well.
But I have problems in 5222.de.
It can differ.
So, the next steps.
First, I really want to get some P.R. merged in Dino.
And it needs some improvements.
For example, now, even though I publish like the album and your
L details, if available, in the UI, you cannot see them.
It needs, like, if you click on the tune,
maybe, like, a modular pop-up with more details.
I don't know.
And also, I want app selection.
Now, it publishes whatever you play.
But I need, I want to, like, restrict only publish VLC
or only publish these certain apps.
Conversations will be my next target.
I will try to backport from monocos.
Because it's really well implemented.
Encourage of the class implement is not what I can do,
but maybe they see and do it.
And the main purpose of this talk is actually,
encourage people to use and contribute,
for example, because I was not a professional.
I was just an ordinary software developer who uses
XMPP in a daily basis.
And now, I made a contribution.
And it was not so hard than I think.
So, this was the thing.
And you can try it yourself.
Just clone my repo on Dino.
And build-ups, it will work.
So, before that, I can, like, do a demo if you want.
So, if I have.
So, this is my Dino build.
And in the menu, sorry, it's Turkish.
I'm using it, but you'll understand.
In the settings, there is a new entry.
Below, it translates as publish what I'm listening.
And if you open it, it will publish your tune, your play.
And I'm using monocos on the mobile side.
If we have, like, the internet.
Okay.
So, if you start playing any song in your form,
for the copyright purposes, I will not play it loudly.
But enjoy the silence.
It will just show up.
Yeah.
So, let's bring it back.
It was being enjoyed.
It can bring joy again.
Thank you for listening.
If you have questions, I can try to answer.
Those are my communication.
Stuff my email, my SNPP, and my GNOWPGG,
and my under maintenance website.
Thank you for listening.
Do we have time for you?
Any questions?
Okay.
One question.
Any little bit louder, please.
The door is open.
Now, in this implementation, it's probably will.
The question is, if you are watching a movie, like in VLC,
will it show up in the, you know, yes, it will.
Because now we don't have filter, like if some app publishes to Empress,
we will like publish it.
Because it's basically a POC.
But the next step I'm working on is like filtering the apps that publish the songs.
For example, you are listening on Lodipop.
Let's say.
It will only publishes the songs details from Lodipop.
And the other one is, I tried monocles, as I mentioned.
In monocles, there is a feature.
I had no, like, it wasn't come to my mind.
But it's a great feature.
You can limit the length.
Like if it's length is less than, let's say, 90 seconds.
It just ignores it.
It can probably be, like, a little video from MasterDone or maybe a sound recording.
So now it's not.
So privacy, like, focus.
But yeah, I know about this.
And I really need to implement it.
But this talk, like, at the date of this talk,
this is the information for now.
But within a few weeks, fingers crossed.
Yeah.
Okay.
Thank you.
So we have the bonfire for excellent.
I don't know.
Okay.
Maybe.
But I have this, like, I was in this tent, like, before the talk.
And we have a chat, like, they said, you can join to the release.
Yeah.
Please, please.