Just to add to the discussion around the use of telepathy, I did quite a lot of research myself when writing PingYou for the coding competition. I didn't get very far - mostly just re-implemented account management stuff and exposed some extra options.

The main feature I implemented that isn't supported in jolla-messages was the ability to authorise subscription requests ("accept friend request"). This functionality sat alongside the closed source jolla settings menus (i.e. it was an alternative settings menu, and changes to one would be reflected in the other). I think this is the best way to work around closed source interfaces to open source components (build an alternative/complimentary interface instead of waiting for Jolla to make the changes when it's probably not a priority for them).

One of the libraries I used was telepathy-qt, which I had problems using with qml, it was written for Qt4 and there are some types that don't transfer easily to qml (or, my qml knowlege is too poor to see how to do it). I wrote a bit about how far I got with that in the development readme.

Adding new features/XEPs to telepathy is difficult on Sailfish because you would have to push the changes upstream, and get them approved by Jolla etc, which makes rapid development quite difficult. I don't know what would happen if you built your own packages and made them dependencies on openrepos (would it break other parts of the telepathy stack? seems risky). Having researched which XEPs are available currently, and the progress of people who have implemented support for quite simple XEPs (like carbons) themselves and submitted pull requests, I have to say I think the whole process is very cumbersome and it seems to take ages to get anything done.

However, it's worth noting that it is possible in theory to write a connection manager in any language (including python), so you could write telepathy-matrix and re-use the rest of the stack.

Swings and roundabouts.