XMPP in Sailfish, how to start?



Hm weird.

Storeman shows the version I have installed as the latest available, but it’s not one of those listed on the Openrepos website.

Also the rpm name looks like an OBS built one.

But I don’t remember building it :smiley:

$ pkcon resolve telepathy-gabble-plus
Installed       telepathy-gabble-plus-0.18.4+git2+HEAD.20220403191913.bc2e989+telepathy.gabble.aa0a11f6b+li
b.ext.wocky.6a31d2c-32.aarch64 (installed)      A Jabber/XMPP connection manager
Available       telepathy-gabble-plus-0.18.4+git2+HEAD.20220318195648.9da4537+telepathy.gabble.502a2ffad+li
b.ext.wocky.6a31d2c-31.aarch64 (openrepos-noonien)      A Jabber/XMPP connection manager

What’s really strange is that I have it installed and had completely forgotten. I have to stop doing crack.

Maybe someone should have a look to kaidan.im .
If it could be compiled for Sailfish too it would be great.

The native implementation of xmpp is very unusable for several aspects:
No omemo,
No muc,
No several other basics…
The reason is that telepathy framework is so far behind of modern xep’s…

The backend kaidan uses, GitHub - qxmpp-project/qxmpp: Cross-platform C++ XMPP client and server library , could probably be built with current SFOS tooling. The front end, which also uses kirigami ( not a fan ) and requires 5.15, so that’d be a challenge. qxmpp would be a upgrade over telepathy (I think!?)

The native XMPP account works, but is very limited:
The only thing that really works are 1:1 unencrypted text chats, similar to SMS.

Video chats do not work, group chats neither, end-to-end encryption does not work,you cannot send pictures, videos or voice message (but at least receive them), read markers are not correctly set and so on. And you cannot create new contacts, you have to add them in some other client to your contact list, then they also appear in Sailfish “Contacts” app and can be used.

With installation of telepathy-gabble-plus this can be a little bit improved: Read makers work, sending pictures/videos/files works.

Shmoose can also be used, but as it’s an extra app, so it does not extend the native messaging system but works in parallel. It does at least support group chats, sending pictures/videos/files, adding contacts, and has limited support for OMEMO end-to-end encryption.

In total there’s unfortunately no XMPP client on Sailfish that comes near to Conversations (Android) or Monal (iOS).

I personally normally use the native client beefed up with telepathy-gabble-plus on the phone. Usually that’s sufficient. If someone uses OMEMO or if I want to use groups I start Conversations. On my computers I use Gajim.

Just to play the devil’s advocate (I’m a long time XMPP user/service provider) what if we consider the most likely to be a win for all case? I’m thinking, even though I have my issues (both software as organizational), that doing OS level integration (given that @HengYeDev is doing fundamental client work already) of something like matrix might get us further, faster?

I’ve been losing the fight for upgrading XMPP in the organization for 2 years now. Defacto, matrix has become the standard.

How many here are still using primarily XMPP? Serious question. Not ideological. Not to say they exclude one another, but obviously Jolla isnt’ able to support XMPP so that it’s usable.

Valid question. Personally I would be happy with any native communication app which supports chat, voice and video and is supported in the android and apple world as well.
It’s the permanent bugs with, e.g., calls or video calls which annoy me when using Telegram or Threema via the android compatibility.

1 Like

via GitHub - TelepathyIM/telepathy-tank: Matrix connection operator for the Telepathy framework Matrix could have the same level of “integration” as XMPP actually. And Telegram if you dare GitHub - TelepathyIM/telepathy-morse: Telegram connection manager for the Telepathy framework:wink:

Ah, thank you. But that doesn’t cover E2E which seems to be the ‘baseline’. So that would be libolm. Still, I wasn’t suggesting that plumbing is entirely absent, just that maybe the developer ‘mind-share’ is a problem. Unfortunately, if you’ve ever looked at how synapse stores json arrays in an otherwise fine pg database, you might argue that it’s better not to have that mind-share.

How much effort would you guess is involved in supporting libolm? In the case of implementing libolm support, how far up the tree (I mean UI support for stuff like key exchange, backup, etc.) does it go?

Could be time to push this to the funding page. It’s discrete enough … (currently stuck writing grant applications that I’m not qualified to write…)

Not to forget: GitHub - gkdr/lurch: XEP-0384: OMEMO Encryption for libpurple.

libquotient seems to support and use libolm already for EE encryption. In how far the telepathy specification contains meta data for EE encryption and key handling I don’t know. Maybe @kaffeine is here as well? :wink:

To be honest I wasn’t seriously suggesting to extend those! Creating an abstraction layer like telepathy or libpurple across protocols (this includes SMS, MMS, telephony btw) seems to create quite some friction and loss of features.

Had forgotten!

But you mentioned the same level of integration, which suggests libolm integration?

Within the next release kaidan will have omemo fully integrated.
The new version will be released soon.

If Kaidan will compile then maybe we would have a good xmpp client

1 Like