Telegram Connection Manager — The first release is going on

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:

  1. 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.
  2. 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 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.

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:

  1. Group chat
  2. Secure chat
  3. 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 🙂
Telegram Qt TestApp

Group chat with multimedia messages in TelegramQt TestApp.

One-to-one chatting

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.


  • 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.


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.

Tagged with: , , ,
Posted in Uncategorized
12 comments on “Telegram Connection Manager — The first release is going on
  1. Please, do it. You can grab a Z10 or Q10 for cheap and code for BB10, with TelegramQt, and snag the prize easily. Those $10.000 will easily finance your efforts 😉

    From a KDE and BB10 user.

  2. Kenny says:

    Calling it Telepathy-Morse is very confusing, surely a telepathy library called that would be using morse not telegram

  3. karni says:

    Hi fellow developers. Have you checked out ? It’s very much in active development (and requiring major refactors), but we’ve already had measurable success with it using it for Telegram for Ubuntu, and I believe two other 3rd party clients use our library. If you want to reach out, I’m karni on , contributions are welcome!

    • Kaffeine says:

      Excuse me, but we have so different approaches, thus I have to reject your invitation. 🙂
      I have seen tg code before starting this project. I would be polite enough to just say, that I decided that it would be easier to write a new version from scratch, rathen than refactor “this”. I want to tell about implementation. I have less than 4000 lines of hand-written (and pretty good for me) code plus about 4500 lines of generated code. Public API consist of about 130 lines of header code. By the way, TelegramQt is not any less “asynchronous” than libqtelegram. Fairly speaking, both libraries aren’t thread-safe.

      It was a question of one day to implement avatars in all three TelegramQt, TelepathyMorse and TelepathyQt.
      It was a question of about 40 hours to implement group chat (TelegramQt only).
      I am absolutely convinced, that working on my project is times more efficient.
      Back to the beginning, my API let me write Telepathy connection manager in just about 1200 lines of code. 1200 lines of code means that the manager is thinnest wrapper; it’s just not possible to reduce the code (say, by moving to the library).
      testApp is not user friendly (didn’t even try to be), but it’s pretty functional client, consist of.. 1200 lines of implementation code.
      Once I’ll have free 16 hours, I’ll finish multimedia (audio/photo/video) messages feature (for TelegramQt, Telepathy stack is not that deterministic for me).
      You can share tg and libqtelegram statistic, if you wish. 🙂

      P.S.: I have to admit that I used to shift a timelines, but it’s barely related to programming.

  4. karni says:

    I have no intention of making any comparisons, you’re doing fantastic work, keep it up!

  5. someone says:

    Telegram has a pretty bad security record, I would suggest not enabling people to use it. Search for Telegram on here for more:

    • Kaffeine says:

      The linked page doesn’t say anything new.
      I don’t think that Telegram is any worse, than, say, WhatsApp or Skype. IMO jabber have bit better security, but it haven’t many nice features, such as multimedia messages, dialog history and so on. Telegram have good enough “convenience&capabilities / security” ratio, so it has a reason and a right to be popular.
      By the way, Telegram security challenges demonstrate worthy level of security.

    • The promo of a guy working for OpenWhisper doesn’t sound very unbiased, and there weren’t any claims of any actual vulnerabilities in that link.

      It’s certainly hard for me to tell what’s real and what’s just smearing from a competitor.

      As far as I know on the security side, it’s not had a single third party interception attack, despite a competition prize.
      It’s only had one minor issue where hypothetically if Telegram’s server were compromised one could weaken the P2P encryption by manipulating the initial nonce. This got fixed pretty quickly, and there haven’t been any since.

      Compared with Whatsapp, GMail, Facebook, Snapchat, et al. that’s a pretty damn solid record.
      Those ones don’t even have the option P2P encryption on top, so no matter how great or crap Telegram’s one might be, it can’t be described as worse.

      Besides, in KTp you can just throw OTR over the top anyway.

      • I dislike Telegram’s centralized model. Regardless of the strength of encryption between client and server, the server is closed and stores message history of all users. Even if I trusted Telegram not to abuse this data, and even if I trusted that local governments would not compel Telegram to reveal personal data, I don’t like the fact that this model *requires* me to place that much trust in so many people.

        Yes, you can use OTR on top of it, but now you have two problems: getting people to switch to a new service and getting them to use OTR.

        You’re right that it’s better than most similar services at this time, but I personally can’t justify recommending that my friends switch to a service that (in my eyes) doesn’t do nearly enough to protect communications.

  6. […] todos estos meses de trabajo Alexandr acaba de sacar una entrada en su blog comentando el estado del mismo. En primer lugar nos comenta que este proyecto se ha dividido en […]

  7. […] you don’t know about the project, then you can read the previous post with […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: