 Good morning. Thank you for coming. So today I'm going to talk about free communication on the desktop. And specifically I'm going to talk about the telepathy project. For those of you that don't know me, a few words about myself. I'm an old KD and telepathy contributor. I started back in 2009 with Google Summer of Core project related to KD telepathy. And nowadays I work on GStreamer, totally different. However, last year I was kind of bored. I wanted to do something else apart from GStreamer. And I started looking at communications because it's something that bothers me when I work. Communication is kind of hard. So one problem is that basically nowadays all the communication happens on the mobile. I have like three, four different apps on my phone to talk to different people. And that kind of sucks. And when I'm on the computer and I want to talk to them, the best way to do that is to just open their respective websites because all of them have web apps. So I load my browser with three, four different tabs of heavy websites and all that just to talk to some people. So yeah, it bothers me that there is no good way to do that on the desktop. And of course, there are some open source applications on the desktop that are quite okay to use. But some of them, they are for specific protocols. Some of them, like for example, Pidgin or similar things, they are okay. But I don't really like them. So I was looking at telepathy again and I thought, yeah, why not? Why is this project dying? So yeah, maybe you've heard of that project before. What is it? It's basically it's implementing, it's a framework implementing instant messaging as a desktop service. Every protocol backend is a different process and all the communication with the user interfaces is done through debas. And you can have, of course, more than one user interface sharing the same connection because of this architecture. This graph is quite old. I know MSN doesn't exist. I was too lazy to change it. So a quick history lesson about the project started around 2005, 2006, I think. It was developed actively for the Nokia's MIMO and Mingo platforms. At some point, Empathy and KD telepathy kicked in the two respective user interfaces for GNOME and KDE. But the project was told around 2013 and it was the point where people were working on releasing version 1.0, which was about cleaning up API and doing some porting which I'll talk about later. Where are my notes? So yeah, when I joined last year, I tried to see what's the state. And I saw that there was activity all these years in telepathy Qt, in the telepathy Qt library, which is the Qt API to talk to the debas services. And there are people that were writing and still are working on those Qt-based connection managers. Connection managers are the processes that actually implement the protocols, right? And they provide this connection to the user interface. There are, like, we have these connection managers, Qt-based connection managers at the moment with telepathy Morse for the telegram protocol, telepathy Nonsense, which is an effort to redo the XMPP connection with the Qt API. And some other connection managers as well that I put the question mark there because I don't know what their state is, but it's telepathy hanging for hangouts, a telepathy reciprocate, and telepathy Bell for the ring protocol. There is a talk later about this one. So I joined in, I saw this activity, and then I saw that the JLIB site was not being worked on. We have also telepathy JLIB, the JLIB API to talk to the debas services, and a couple of JLIB-based connection managers for XMPP, for IRC, for, I don't remember what that is. And I started working on that a bit, did some releases on the JLIB-based connection managers. And then after discussion with the other guys in the project, we thought we should finish the 1.0 release effort because it will make things easier both for us and for new contributors in the future because it cleans up the API a lot. The API right now is a bit over-engineered, I think. And yeah, there is also some work to port telepathy JLIB to use JLIB-based, instead of debas JLIB, which is a bit painful. Telepathy Qt also needs some API rework to make it easier for people to use it. So that's what's happening now. We also recently moved the repositories to GitHub because it was easier for us to work there. Previously we were on a free desktop, and still are actually, the website is on a free desktop. Repositories are also on a free desktop, and we synchronize them. But yeah, the main development is done here. And there are a couple of plans for the future, like ideas we had that we would like to see implemented at some point. Implement some modern chat features which are not there, like being able to see server-side logs. Many protocols do that nowadays. Do chat lists instead of contact lists. The thing that you see on your WhatsApp or Messenger or Telegram, when you open the app you see a list of chats instead of seeing the list of contacts. Contacts is a very old idea. Multimedia messages as well. There is support for that, partial, but it needs some work. Another idea is to implement a better graphical user interface, something more modern, something that corresponds more to what people are used to nowadays. That doesn't essentially mean rewriting everything. We could improve the existing applications, but any idea is welcome. Do some connection managers for other modern protocols, like Matrix or Tox. Also, we would like to improve compatibility with proprietary protocols, because that's where most of the user base is. If you're not compatible with those, it's hard to keep people using it because they will always switch to something else when they want to talk to their friends that are not on XNPP, for example. A couple of ideas, Skypes, Team Messenger, these things are... I think they can be somehow connected. Also, another thing that I would like to see is reduced product fragmentation. Right now, I know there are patches around in selfie shows, Ubuntu phone, mostly for the ring connection manager, which is the connection manager for the cellular protocol, the GSM protocol. Because these companies use telepathy in their phones, actually. This is all there is a lot to do for me and the other guys, so we need you. There are a couple of tasks. Right now, we want to finish version 1.0, as I said. There is a lot of work in maintaining connection monitors. We have Gabu for XNPP, Salute for Linklocal XNPP, Hayes, which is a compatibility layer for exposing lip purple protocols, so we can use whatever lip purple has on telepathy. Idle for IRC, Ring for Cellular, as I said. Rakia for SIP, which I don't know if the backend is being maintained. It's based on Sofia SIP, I don't think that's maintained, but anyways. We would like to also work on missing features on the connection monitors. It would be very nice for people to be compliant with XNPP Compliance Street 2016. Also, it would be nice to be able to support more lip purple features in Hayes. Right now, we want to support text chats. We could do more, and it would increase our protocol span a lot because lip purple has a lot of protocols implemented. Another thing that you could do is come up with a new client, I don't know, or improve one of the existing ones in a way that makes it more modern and more appealing to users. And yeah, that was everything I had to say. Any questions? Yes? On priorities and future directions, I was wondering if you're trying to do outreach to distinctly open communications protocol groups like the Matrix thing, because I think one of the problems we're trying to solve is rather closed communication channels, and I understand that telepathy already supports or aims to support a wide range of protocols, but I think maybe the best things that the core enthusiastic people and developers can do is connect with other groups that are trying to do the same thing like Matrix. Maybe by talking at the conference, please repeat the question. Yeah, so if I understand the connection right, the question right is you're asking if we have a certain direction in specific features that we would like to work on with other communities? Is that what you're asking? Really, I want to suggest that talking to these other communities and trying to work together is a good thing to add to your future directions. Yeah, I think so, definitely. It's like everything is open. We are open to discussing with other communities, of course, but one of the reasons I came here to give this talk is try to see what other people are doing, engage in talks and maybe come up with very specific directions that we could move on. So does telepathy have any provisions for out-of-order messages? So for example, Matrix is not just message-passing protocol. It's just chat synchronization protocol. So it's possible that you receive some messages and then you receive some messages in between them. Right. So the question is if telepathy supports message synchronization like Matrix that some messages may come later they may be in a different order than they actually arrive. So the answer is no, we don't have good support for that, but it's something that we would like to do. It's in the modern features pool that we would like to implement because, yes, it's essential that we support things like that. Okay, so what I'm going to add, because I heard this Sophia Seed mention, I think the guy that free switch either fork it or they embed it, but I think they're still using it and eventually improving. I'm not sure if Giovanni has more... Giovanni, you know the state of Sophia Seed with free switch is imported and embedded? Yes, Sophia is important and we are putting a lot of effort into updating it, fixing bugs, making it more probable, etc. More or less in the, let's say, the original project what you find into the SDN is not so much improved. Let's say it's kind of stale, but we're using really a lot of effort into it. So let's say that our version is much more, let's say, as much more work than that one that is still like Nokia left it in this case. So feel free to interact with our people, particularly with Michael J. Ortoni about the Sophia Spank. And I think that you'll be maybe better served to use our version that's kept completely compatible with the original one. So you don't have to do any particular work. Okay, so this was not a question, it was an intervention that Sophia Seed is still being worked on in the free switch project. And yes, we will definitely come to that when we bring this. That's a small question. I saw you mentioned a lot of extra plugins or something like that. I don't remember exactly. One of them was a plugin to interact with already existing codebase from teaching projects. I see you have very small developers in your group. Maybe it's time to cut off an extra while re-implemented the same things and just focus on that plugin, which allows you to work with that, let's say, arguably bigger codebase, bigger, more vital project like PIP. Yes, yes, it's one option. If you take a look around, people are saying this is old codebase, this is not maintained anymore. And if you take a look at what state of plugins and free disk project are, I see some of them have violated the commit years ago. Just move forward. Yes, so the intervention was that maybe it's better to focus on telepathic haze, which brings protocols from Leap Purple because it basically cuts down our maintenance and makes us use very updated codebase. I agree in some degree, yes. I like to have haze support more things and use Leap Purple more because exactly what you said. But I don't want to stop there because we can do more. You won't attract new developers in that way because they will ask you why not contribute to Leap Purple or rather contribute to your own projects which will never reach the same level of functionality. So you are actually effectively cutting off the... I think the reason is that some people may not be comfortable in coding in Leap Purple and that's why. I mean, people who work on the telegram connection manager right now, they use Qt, they are Qt developers. So I can't tell them to just stop doing that, go to Leap Purple. I don't think it's good. Also there is a problem that Leap Purple and Telepathy have different feature sets. So Leap Purple doesn't cover all the features that need it in Telepathy. For example, I was looking at Leap Purple support for Skype and it can't support your own messages. I mean, if, for example, you send a message from another client, you won't see this message in the client that works through Leap Purple. Skype is a different story. Guys, I'm sorry, but you're going to have to play with the discussion. Because thanks a lot and thank you for your audience.