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? 
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
2 Likes
With the new support of QT 5.15 Qt 5.15: what's next? - #49 by tortoisedoc, I think that compile kaidan for Sailfish will now be possible
1 Like
That’s a good idea! Having a look now!
2 Likes
and kaidan with OMEMO was released on May 5th, it would be very nice to have it (they only lack group chat support which will be in next versions, for the moment they have only implemented group chat search). Kaidan 0.9: End-to-End Encryption & XMPP Providers - Kaidan
Sadly, fedora doesn’t have a recent spec for it, or it’s stuck in kde-extras. Looking about…
EDIT: File kaidan.spec of Package kaidan - openSUSE Build Service looks fairly usable!
1 Like
This is the ground work with a submodule. However, we need another dep: ZXing. so it’s gonna take time. If someone wants to take a crack at it: GitHub - poetaster/kaidan: xmpp messanger from kde
1 Like
There’s a zxing-cpp package available, is that not it?
1 Like
Ah. I looked on chum and neglected to look on device. Sigh. Thanks!
Following nephros prompt I started gathering the rest:
With the following, when the spec files are finished, should build on chum. Some questions.
Seems everyone disables omemo. I believe it SHOULD be on by default …
here I’ve set upstream to Debian XMPP Maintainers / libomemo-c · GitLab since kde also tracks that. But I’m not sure if it’s a good idea?
qca is in chum already. @rinigus before I start on the kaidan et.al. spec files what do you think about the omemo source?
Ok, I have libomemo-c built without any dependancy on opt-kf5 so that most projects can use it.
Sadly, the more recent versions of qxmpp, with proper omemo support require 5.15. This build of qxmpp will only be useful in the opt-kf5 context.
is there something specific about it that could raise concerns?
no, not really. It’s just not the norm for ‘our stuff’. But debian seems to be the best source, short of going directly to the dino repo which I would rather avoid.
What a day. So, Show home:poetaster:qt5.15 - SailfishOS Open Build Service has omemo and qxmpp. The former is generally usable, the latter is opt-qt5/opt-kf5 only.
Kaidan, sadly, still requires QtPosition which I just don’t have time for now. So, someone step up! Please 
3 Likes
Sooo, I’ve spent a painful amount of time fighting my ignorance of packaging (and opt-kf5 in particular) to come to the somewhat sobering conclusion that I probably won’t get past v0.8.0 (which is one year old).
Currently I we have libomemo-c, opt-qca (@rinigus I think), and opt-kf5 qxmpp and an opt-kf5 kaidan moving to chum:testing. But, I don’t see the point without:
- muc
- omemo (.4) for all conversations.
These conditions will require, I believe, g++ 10 (c++ 20 or better engineering). I seriously, given how much time I’ve spent on this, considered rewriting some of qxmpp (class equiv. operators implementation leaves something to be desired) and but, as you might guess, when delveing deeper into the kaidan code, it became evident that that would eat ALL my time.
Soooo, since this effort depends on tooling updates from Jolla, I decided to try a parallel approach. I’ve got the required libraries building (qca (latest), libomemo-c (latest), qxmpp (1.5)) on chum that would support, and in fact rely on, the work from GitHub - ron282/shmong @ron282 …
I think this latter effort makes more sense to work on, even if the muc + omemo bits are non-trivial.
Any feedback is appreciated.
2 Likes
Hi
Ron and me developed Shmoose a long time ago. Recently, we switched from Swiften lib as a base to qxmpp and started Shmong (ShmooseNG). We had the same issues with C++ standards. There is a very first patch we used, to get the latest qxmpp release compiled with the SFOS toolchain [1]. The changes are not that big.
Meanwhile, I stepped out of active C++ development. But we discussed about the future of Shmong [2]. Have a look at the end of that thread. Ron took over the lead developer role of Shmong now.
In my opinion, it would make sense to focus on one good xmpp client, as we now have all the dependencies fulfilled to get Kaidan also working on SFOS. It will for sure need some efforts to maintain either the patches or to get it integrated into Kaidan as an compile option. Also the power-saving stuff (receive messages in power-saving mode) and the SFOS notification integration needs to be ported. But this is doable, once Kaidan is really building and running on SFOS.
[1] qxmpp-sfos/sfos.diff at master · geobra/qxmpp-sfos · GitHub
[2] Porting steps · Issue #1 · geobra/shmong · GitHub
2 Likes
Great to hear the news. I had sort of grokked it while building it but now I understand the course of events.
So, in the hopes of furthering development of the native client, I’ve built the support libraries on chum and now shmong. Show home:poetaster:qt5.15 / shmong - SailfishOS Open Build Service To get things to build on chum, I had to move things around in my fork and make adjustments to the spec, but that might all be useful in the end.
I ran into such time sucking challenges with kaidan that I’ve decided to not take that further since getting v0.9.1 compiled is not possible even with qt5.15 without having g++10.
So, I’ll try to help with shmong as much as I’m able.
I’ve done successful preliminary testing with Shmong from chum: testing. I’ve asked to take it live and encourage any users to give it a go. It looks like @ron282 is taking a crack at backporting kaidan to 5.6 (which I didn’t have the desire to do) so it may get more interesting still.
3 Likes