After a long period of silence I’m coming with a news: Telepathy-Morse project is “still alive” and the first release is going on.

Short introduction: I’m working on the Qt-based Telegram Connection Manager for KDE Telepathy. Actually, there are two subprojects:

TelegramQt — Qt-based library which supports messaging, contact-list operations and other telegram client capabilities. The purpose of the library is to abstract from the telegram protocol details and provide a convenient API for a client application development. Telepathy-Morse — Qt-based Telegram client (connection manager) for Telepathy communication framework. Uses TelegramQt under the hood.

Note: In order to use Morse, you need to have a complementary Telepathy Client application, such as KDE-Telepathy or Empathy.

Note: Telepathy-Morse depends on the latest telepathy-qt version (0.9.6), which might be not available yet.

Now, let’s talk about the development, current progress and plans for the near future.

What is expected to work (on high level):

Contact list with first/last names

Contact avatars

Contact management (you can add/delete contact by its phone number)

Personal messaging (one to one)

User typing events

Message acknowledgment

Own presence (online, offline, hidden)

Loading unread messages on connect

DBus activation

Sessions (Means that you don’t have to get confirmation code again and again)

Restoring connection on network problem

Known Issues

Initial low-level encryption sometimes generates bad random values, which leads to “connection doesn’t work” issue.

Can not send long messages (Missed TelegramQt gzip packing implementation; limit is about 400 characters; telegram protocol limitation is 4095 characters)

Both TelegramQt and Telepathy-Morse are Qt4 and Qt5 compatible.

Information about CMake build: by default CMake looks for the Qt5 build. You can pass USE_QT4 option (-DUSE_QT4=true) to process Qt4 build.

Sailfish OS

Telepathy-Morse almost works on the sailfish devices, but there is one show-stopper: The authentication dialog invocation doesn’t work. We do basically the same thing, as do Telepathy-Gabble (which is known to work), but it have no effect. Sadly, I don’t have a Sailfish device and didn’t test it. Big thanks are going to Teemu Varsamaki, who managed to build Morse for Sailfish, find-out authentication issue and, nonetheless, use the client with an uploaded copy of the auth-info file from desktop.

Telegram Blackberry Contest, Teletonne

I’ve contacted by the “Telegram client for Blackberry” developers. They’re use the TelegramQt library in their Teletonne client and they win the Second prize. More details at https://telegram.org/blog/bb-results. Now it looks like they’re give up with further competition, while it’s really easy to get the next prize for “the developers who make the most progress”, as there is many major improvements in TelegramQt. Sadly again, I have no good phone 🙂 to take a part.

Release

There is no tarballs yet. I’m not familiar with KDE release process, but I’m going to tackle it soon. (I hope to fix the Sailfish issue first)

Next tasks

I see three basic directions in the Telegram client development:

Group chat Secure chat Multimedia messages, files receiving/upload

Group chat support is mostly implemented in the TelegramQt library, but TelepathyQt service bindings require changes to support (such type of) group chat. Of course, TelepathyQt client bindings have everything we need, so clients (e.g. KDE Telepathy) already works well with group chat (e.g. in pair with telepathy-gabble, jabber connection manager).

In its turn, Telepathy-Morse is the first “more, than proof of concept” Qt-based telepathy connection manager, thus TelepathyQt services previously was not used so much. Telegram group chat has “not addressable” rooms and, as I see, the services might needs a little redesign to support it.

Secure chat. As I know, technically it looks like embedded telegram session with the same cryptography methods, which already implemented for the basic telegram connection. This is not a priority task for me (at least at this moment).

Multimedia messages. File download capability is already implemented and used for avatars and initial photo-messages support. I need to tune it a bit for “big files” operation support. Outgoing media messages needs some significant work, because one can not just upload files “as is”, but should meet Telegram requirements, such as format, resolution, etc. I have no strong decision on the API and TelegramQt responsibility yet.

Implementation of the last task means almost automatic “done” for the self avatar changing (uploading) capability.

I have never heard about open source Telepathy stack component with multimedia message support, so, probably, there will be a lot of work. Telepathy specification have some hints on this subject.

Short note about TelegramQt test application

The test application is not intends to be telegram client for end users, but supposed to be feature full developer-oriented application with easy access to some artificial operations, just to be sure that TelegramQt works as expected. Because the TelegramQt documentation does not exist, the test app source can be useful as API usage example as well.

Pictures 🙂



Group chat with multimedia messages in TelegramQt TestApp.

Morse and TelegramQt TestApp in process of one-to-one chatting. As you can see, there is avatars in contact-list, typing status in ktp-text-ui, messages timestamp, delivery-report and a little allusion .

Acknowledgments

KDE Project and especially David Edmundson for making this project possible.

David Edmundson again, for moral and technical support and for the ktp-accounts-kcm plugin for Morse.

Matthias Gehre for his work on the TelepathyQt services.

Previous post autumn commentators, especially Alberto, who eventually made me to continue this project, instead of delaying it again and again under pressure of everyday cares.

Teemu Varsamaki for actual code contribution, ideas, testing.

Links

Afterword

I’m so sorry for the slow development, it’s a consequence of my “always busy” reality. The project is not abandon and will not be abandon. I hope you’ll see an update next few months. Thank you for reading.