XMPP in Sailfish, how to start?

Get Started
#41

Ah. I looked on chum and neglected to look on device. Sigh. Thanks!

#42

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?

#43

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.

#44

is there something specific about it that could raise concerns?

#45

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.

#46

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 :slight_smile:

3 Likes
#47

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:

  1. muc
  2. 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
#48

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
#49

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.

#50

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