Telepathy Tank

tags: kde telepathy matrix

TL;DR: telepathy-tank and Telepathy IM, in general, are here and not forgotten, few enthusiasts are still playing with it and even revived private matrix room as public for the telepathy developers and packagers: #telepathy-im:matrix.org. Sailfish OS, KDE, and PostmarketOS developers could be interested (and probably already know about it :D)

Telepathy IM project

General overview

First about Telepathy in general. Telepathy IM is a client-side specification and a framework for the desktop and mobile Linux real-time communications. It builds their modules as independent programs (Unix processes) and uses IPC for coordination between them (D-Bus precisely). The applications called pidgin/libpurple and weechat and kopete are probably predecessors of the telepathy project, but they're focused on the plugin subsystem approach, not IPC one.

The most beautiful and challenging thing about Telepathy is probably a client apps interoperability. For example, if you what to write an application with some new UI that shows contact list or shows and sends messages to some rooms, you don't have to rewrite an application that supports login and manages connections if it's already written for your system. The new applications could be implemented in different languages that could even not support your IM protocol directly, it just has to support dbus system protocol on the library side.

Since pure D-Bus is quite low-level, additional wrappers are already there for convenience, such as Qt D-Bus (Qt is well documented ❤ and also have a nice write-up about dbus), python dbus, haskell dbus, lua dbus, npm dbus, dart dbus.

In other words, the IM protocol client could be implemented in one language, UI applications in another, and they could communicate with each other via dbus following the Telepathy specification that describes IM subject matter. Even Qt, glib, and python wrappers for the Telepathy protocol itself were introduced for more convenience (comparing to the dbus wrappers mentioned earlier).

Matrix point-of-view

Matrix developer who is interested in Linux but not familiar with the Linux IPC and dbus could ask:

• Why do I need even more abstractions on the client-side, if I could just use bridges on the server-side and focus on the all-in-one application on the client side?

There're probably two reasons in my opinion:

• It makes an option to not to use bridges if it's not possible for some cases, and work on protocol support directly for the client-side
• It makes possible different system-side integrations. For example, not only the chat but also the PIM applications (adress book, calendar), media players, etc – could share the same connection on the device. You probably have to re-invent Telepathy if you have to build something similar but in the all-in-one application.

So, while Matrix specification covers server-server and client-server side, Telepathy IM is more about client applications, while both describe real-time communications subject matter.

Challenges

There's also known challenges with the current implementation:

• DBus-specific solution. While dbus is native IPC for the Linux-based systems and could be shared over the network or ported to the target OS, it's not well-known across the other operating systems. Somebody could say that network connection could be used as IPC instead of some OS-specific mechanism. But the higher-level abstractions are a trick (which will remain the same probably) and should be evolved and maintained anyway. Which leads us to another currently weak side
• Contributors flaw. Telepathy project roots are from the good-old-days of the Nokia N900/N9 Linux devices and Collabora team development. A lot of contributors are needed to support such a level of standardization. Right now we have Kaffeine maintainer who has "picked up the flag" and few other project sympathizers. It's the well known chicken-or-the-egg problem that could be solved step-by-step though.

Matrix connection manager

Telepathy-tank is a matrix connection manager for the Telepathy. It uses libQuotient and mentioned Qt wrapper library for the Telepathy.

The Telepathy framework is the native messaging solution for the Sailfish OS. There're also chances it could revive in the KDE project due to Plasma Mobile activities.

Sailfish OS 3.3.0 Rokua was released recently, where gcc compiler updated 4.9 -> 8.3 thanks to Aurora OS developers' contribution.

Don't be surprised it's not 9.3 like in your favorite vanilla rolling-release arch desktop distro, embedded devices state is another story currently (PostmarketOS and Archlinux/ManjaroARM are nice exceptions though).

Compiler updates make it possible to drop super-cool rinigus workaround to use gcc from opt for Sailfish OS and compile libQuotient! Patches to support outdated Qt5.6 are still needed though.

Sailfish OS Qt update are still in 5.6 state also due to non-technical challenges about framework LGPL/GPL transition 2 -> 3; It bothers many developers (me too), but it's not something anyone forgot about

Recent activity from KDE and Sailfish users and personal interest of Kaffeine (telepathy maintainer, telegram-qt, and telepathy-morse developer) lead him to make Telepathy IM room public.

While telepathy-tank is in the very early stage of development, it's already possible for the developers to play with it in KDE and Sailfish OS (thanks to Kaffeine again, since he also provided a workaround for the Sailfish notifications/history subsystem).

Here are some screenshots in fancy devices renders from the Sailfish with telepathy-tank. It's the first iteration, already working with the system apps like messages and contacts natively:

An infinite source of inspiration and all my wallpapers: Simon Stålenhag.

Alexey Andreyev (aa13q) for the This Week in Matrix Digest (24.04.2020.)