I like this general approach of Sailfish too, as in: The protocol doesn’t matter but the use case. Thought from a user centered perspective. Imagine you could (video)call someone via xmpp by using the telephone app of Sailfish…
2 Likes
I use XMPP/Jabber a lot without using Shmoose or any other fully-fledged XMPP client apps. However PingYou has proven useful, because you cannot add XMPP contacts using out-of-the-box SailfishOS 
. Once you have done this, those contacts appear in your SailfishOS contacts, where you can connect them to existing contacts if needed.
When this is done, you can use XMPP/Jabber to send text messages just the way you do it via SMS (which way you use to send the message is metioned below the message field and you can also switch between the available methods there), which I find pretty cool.
The downsides of using XMPP/Jabber like this (mostly referred to here already), are mentioned and discussed here.
I really like the idea behind the XMPP integration in SailfishOS, but - like many others around here - I think it’s high time Jolla finally went the last few steps to really make it useful for everyone!
1 Like
You can only send a message to someone if you have received once a message from him/her
That’s not quite true. You can use PingYou to add XMPP users to your roster and they will appear in your SailfishOS contacts, where you can connect them to existing contacts if you like or you can use them “standalone”. Once you’ve done that, you can start sending messages using XMPP without having received a message from the contact in question first.
I agree, however, that adding XMPP contacts is something that should just works out-of-the-box!
1 Like
Pingyou has not been updated for more than 5 years. It is not compatible with SailJail.
It doesn’t work on my XA2 with 4.4.0.68.
What about telepathy gabble plus fromopenrepos? Does this still work?
Added to https://forum.sailfishos.org/t/apps-that-havent-been-ported-to-aarch64
I’ll take a crack at it, this week.
4 Likes
Yes it does! (4.4.0.64/aarch64)
1 Like
I didn’t see an aarch64 build? Did you build it?
3 Likes
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 
$ pkcon resolve telepathy-gabble-plus
Resolving
Querying
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 … 
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…)
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?
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.