Unified Communication – What KPeople and Nepomuk can do for you (in the future)

Unified Communication – What KPeople and Nepomuk can do for you (in the future)

Most of the time within KDE I discuss things which are either already out there or in a design/ mockup stage, because those are the points where either I notice problems or developers have questions for me. From time to time, however, I just do a little “thinking outside the box” to come up with new ideas, or “visions” (no, not the “If you have visions, you should call your doctor” kind). One of the things that come to my mind every time I discuss anything related to communication is: With all the information federation stuff we have in KDE (Nepomuk, KPeople, Akonadi, …), we should be able to unify the communication with the same person across different communication media. There are at least three scenarios I have in mind here:

Scenario 1:

I have an idea which I’m eager to tell Àlex about (because Àlex is usually my go-to person for crazy ideas). I don’t want to open several applications first just to check whether he’s online on GTalk or IRC, I just want my message to reach him as fast as possible. In this situation, I want a system where I can just say “Give me the best way to reach Àlex right now” (where “best” is based on both availability and my preference for certain communication media).

Scenario 2:

I read an email by someone on a mailing list. I feel that I have to discuss the content of that mail with the author, but I assume that having the whole discussion on the mailing list may produce too much noise on the list and just annoy people. Therefore I decide to continue the discussion via instant messaging. During our private discussion, we realize that a few more people should be involved, but we still want our discussion to happen on a synchronous communication medium, so we decide to continue it on IRC. After we’ve reached a conclusion on IRC, we post the conclusion in a reply to the mailing list. Later on, I want to review the whole discussion. In this situation, I’d like a history of the discussion which aggregates the original mail, the IM log, IRC log and the final mail.

Scenario 3:

I am looking for that file David sent me a few weeks ago. I don’t remember its exact name or whether he sent it to me via mail, Jabber or IRC, I just know that it was a few weeks ago and that it was from David, and I want to find it easily just based on that information.


All three of those scenarios may sound like rainbows and unicorns at first, but they are not that far-fetched, and the basic technology to give me what I want in them is already there. Therefore, last week at the KDE PIM sprint in Brno I talked to some of the people who could make the features I’d need in those scenarios happen: David Edmundson and Martin Klapetek from KDE Telepathy, Christian Mollekopf from KDE PIM and Vishesh Handa from Nepomuk. David told me that for Scenario 1, they are already “50% there”: A contact list which shows you in which communication media a person is currently available (powered by KPeople, of course) is already being developed, so the most important part for that is already happening. The “give me the preferred communication medium at this moment” part still has to be done. That part doesn’t have such a high priority to me, though, because if you have all communication media in one place, including the person’s current availability in each of them, manually selecting your preferred medium is easy to do.
For scenario 2, more still needs to happen. Currently neither IM nor chat logs are stored in Nepomuk, so it cannot connect them to a person. According to Vishesh, Nepomuk isn’t a good place to store whole logs, but it should still be able to link logs stored externally to people, so that logs from conversations with one person which are spread over various sources may be aggregated somewhere. Plus, all the clients used for the conversation need to support KPeople. KDE Telepathy uses it already, KDE PIM support is currently being developed, and David told me that people from Konversation are looking to integrate KPeople as well. This means that least if you use these applications for your communication, you should be able to get your aggregated logs at some point. Another problem here is that conversations nowadays are spread not only across different logfiles on the same device, but across devices as well. We would definitely want to support a conversation started on a PC and continued on the smartphone. With emails this is not a problem if one uses IMAP. With IRC it works if one uses a client/server system like Quassel, which is more of a power user thing, though. For IM, it depends: Facebook, for example, has an API for accessing the logs stored on their servers, but of course with everything stored on a server somewhere in the US, you have a privacy problem. This problem is not easy to solve, but we agreed that we do not want to synchronize locally saved logs. So if you want cross-device logs but still limit privacy problems, you’d have to e.g. use a Jabber/XMPP server you trust and have it store your logs.
For scenario 3, Nepomuk has to be able to link each file received from a person to that person. Vishesh told me that it “kind of” works for some cases already, but still needs more work. And we need the UI to search for files by person, of course. We all agreed that all three scenarios are something we should aim to solve, now the next step is an actual plan of action to implement the stuff that’s still missing.
So, dear readers, what do you think of all this? Do the scenarios sound realistic to you? Would you find it helpful if the aforementioned solutions were available in these scenarios? What additional scenarios can you think of with respect to unified communication?


Comments: 15

  1. Heiko Tietze says:

    You describe nice scenarios, similar to those Bjoern talks about. Users shouldn’t need to care about software or technology but rather on ease of use and content. I agree totally.
    But I like to contrast this view with some kind of dystopia, probably. Back in the 1950th or 60th people trusted in future. Science fiction was about inventing new sources of energy, overcome conflicts and take off to the stars. Then we got the Club of Rome. In the late 90th we had LaTex to just write, Mosaic to browse simple html, and the public library to copy stuff from. Eventually, it changed a little bit. Security was never a matter of concerns, making a date was done per… I don’t remember ;-).
    You just used only one approach to reach your goal. Now we have many means to accomplish tasks, and the life has become rather complicated. You have to care about file formats, encryption, authenticity, the way of communication etc. So my question is: With all other developments in the last years things went worse in terms of complexity. Why should it be different here? Maybe it will be very important to know on which channel Alex talks to you, or which program is running after David sent you a file. If so, wouldn’t it make sense to use software contrary to your vision? Not that I don’t want to live in your future…

    • Security and privacy are indeed important aspects in online communication, so they definitely have to be taken into account when thinking about any communication solution. I think people generally do not want to think about their need for privacy and security each time they want to contact someone, though. My goal therefore is to have communication always secure and private, regardless of the medium used. In my vision, people could just communicate whichever way they want, knowing that their communication will be private and secure.

  2. Tassos says:

    I think KDE really needs this kind of thinking. We all need to innovate more and offer more than a desktop alternative but a software solution that provides real value to its users.
    Keep up the good work.

    • Thank you for the encouraging words!
      I agree that KDE needs more thinking from the perspective of actual user benefit. It appears to me that KDE still has too much of a “technology first” perspective: Our developers often create awesome technology with which amazing things are possible and then seem to hope for others to make good use of it. In reality, though, this often leads to technologies which are out there for a while but users do not experience any benefit from them, because nobody made use of them.
      I feel this stance changing, though, and I’m here to help accelerate that change, though I can only lay out ideas in front of the developers, who will still have to write the code to realize them.

  3. These all sound good. In fact, they are ideas that had already been hinted at by other KDE devs (mostly those you were talking to at Brno). I think this always was the promise of a connection between Nepomuk and the communication technologies available in KDE, it only hasn’t become reality yet. But your clear vision of use cases could be a good motivation (and a way of tracking progress) for actually integrating these technologies. I am sure many of us users are looking forward to this.

  4. Yes, yes, yes …a thousand times yes!
    It is great to finally see things clicking into their places — this is the vision of KDE4 that has kept me as its long-time power user and I’ll happily continue 😀
    Hmmm, I wonder if it would make sense to break up things even more — to e.g. display all group chats in Konversation (IRC channels, Jabber MUC) and all private chats (Jabber contacts, IRC queries) in KTelepathy …probalby not.

    • Your idea is definitely interesting. I’d have to think about it more to see if it actually would work out, but IRC client UIs indeed work best for chat rooms whereas IM UIs work best for one-to-one chats.

    • It’s probably easier to just use KTP for all and have a different GUI for person-to-person chats then for group chats.
      …but at the moment KTP is just very much sub-par when it comes to IRC and other group chats.

  5. apiman says:

    It’s great to see these kind of efforts to fit Kde to users needs. But I feel something is missing: “The cloud part”. While there have been stated requirements for some kind of server to sync across different devices, no specific alternative is out there. From my point of view it’s of the highest priority to address this issue. Wasting big efforts on cool features that require certain kind of geeky deployments doesn’t payoff. There are several examples of this in Kde. For example: rekonq’s sync feature. At this point it only offers ftp and ssh sync without relying on third parties. How can I possibly sync with my phone using these methods? (I think this is the most common use case for syncing nowadays). Another feature: has anyone ever used plasmoids sharing (just working over Lan).
    Some services need some kind of server to be useful and I think that we need to pay attention to this often dismissed part of the equation. I don’t think it has to be a mom proof server software because at the end you would be running a server, but we need to provide an appealing bundle for which no doctorate thesis is needed to bring up an imap, xmpp, bookmarks sync, webdav, irc, webcal and webcard servers in a way that they work nicely together with Kde’s cool features.
    And is not that we need to create everything from scratch; we’ve got Kolab, Quassel, Owncloud (I’m sure I forget some more). We need to provide the needed integration bits (Owncloud is the place IMHO) to enable geeky family members to offer the kind of experience that is suggested in this post.
    If we don’t tackle this issue and just rely on third parties without the Kde environment in mind we would keep having a bunch of cool useless features for most of our users.

    • Actually, you took the words right out of my mouth! Synchronization across devices is a big gap in the KDE offering right now, and we have to close it.
      I’ve been thinking about starting a project (as in “talk to the devs”) to give users a dead simple way to set up their own local (ownCloud?) server for synchronization of things like PIM data or Nepomuk information using the local WLAN.
      Setting up an Internet-accessible server surely isn’t something every user would or could do, but I think being able to easily sync your devices when you’re at home would already go a long way towards solving that problem.

    • It’s great to hear enthusiastic ideas in those lines 😀
      I was thinking the same — how can I e.g. sync chat history between my KDE laptop and my Nokia N9, that use the same Jabber accounts. OwnCloud might eventually do that, but someone has to write it (or just csync the log files).
      There were syncing options made before (KitchenSync, Wammu, …) but nothing worked as well as cloud-based solutions. I think that ownCloud (& other similar FS solutions) should be the way to go here. Of course not everyone wants to run a web server at home (although fingers crossed for FreedomBox), but people who trust each other could share an instance/node or just use a trusted provider.

  6. David says:

    This kind of idea is something that I have been looking forward too ever since discovering akonadi and nepomuk. I love this idea!
    Keep up the great work, thank you very much!

  7. brejoc says:

    I absolutely want this! And I’d also like to see it in combination with todo-management and issue tracking! 😉

    • Integrating it with todo-management sounds like a great idea indeed, it even sort of follows logically considering that tasks can be created from emails already and we want to blur the lines between different communication media. The combination with issue tracking is quite developer-centric, of course, but given that KTp already contains a filter for displaying bugzilla links in a nice way, I can imagine that they’d integrate it anyway 😉

Add your comment