Please guys, don't hijack this thread with general discussions about the pros and cons of different programming languages There are plenty of other places for that kind of thing.

@Modulebaan is quite right to have identified messaging as a weak point on SFOS, and his proposal to do something about it is more than welcome

Will this app someday be able to take care of SMS/MMS also? Does Sailfish allow to use different app for SMS/MMS?

If this is possible, will this be able to solve the big problem of not supporting group SMS/MMS in default messaging app.

Modulebaan, will you use MartinK's universal components, so that the whole thing will work on any system that support qqc2 (such as nemo)?

From all the comments I read here, building a framework is hard and that's not the purpose of Transponder.

The current architecture looks like this:

• Transponder QML UI
• Matrix.org daemon
• DBus interfaces to communicate
• C++ as main language, PyOtherSide to add Python for certain SDKs

I'm not familiar with those components and the UI is shared with Sailfinder. I will not use those, I'm sorry. Feel free to write the UI yourself.

It's basically a component set I wrote so that modRana (and any other apps using Universal Components) can have a single QML UI codebase that is independent of Silica/Qt Quick Controls or any specififc QML components set in particular.

But it's not yet another component set in itself, it's rather a common API layer with backends selectable at runtime (currently Silica & Qt Quick Controls), so an application using Universal Controls still looks native (an UC Button is a Silica Button on Sailfish OS and a QQC Button on Fedora for example).

I'm using this even during development of modRana - I can easily test and debug the UI directly on my Fedora desktop via the QQC backend, while on my Sailfish X Xperia the same UI code will run with the Silica backend. I've also used Universal Controls for porting modRana to Android, where QQC are available as part of the Qt 5 port to Android.

So that's just some background to explain what the Universal Components project is about. Of course if you already have an existing UI codebase based on Silica and or if you plan to only target Sailfish OS then I guess using Universal Components might not bring many benefits to your usecase.

And also, thanks yet again for taking on the Transponder project! I think it really has a potential to improve the currently suboptimal native messaging situation on Sailfish OS.

I think, that shmoose is hands down the best xmpp client for sailfish now if it supports at least Message Carbons XEP-0280 (needs probably to use swift 4.0 base).

But the XMPP discussion seems to drift offtopic here, sorry for that...

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.

@MartinK Your components are pretty nice! I really like them but since I only target SFOS and I have already an UI ready, I'm not going to use them, keep it up though!

I really appreciate the feedback on Transponder, the initial design is completely gone at the moment more info and Github commits on Transponder are on the way.

Any news on the status of this project?

https://github.com/DylanVanAssche/harbour-transponder
Last commit January 29th