Consider dropping libswiften backend

[ConiKost]

I propose, that it should be considered to drop the libswiften backend in future. Problem is, libswiften hasn't received for years any updates and last commit was in 2020, while last release is even older. Also, it fails to compile against updated modern dependencies like boost. Debian, for example, already dropped libswiften from debian testing.

[vitalyster]

libswiften is a core library used for transport itself, not just backend. While I'm already started to minimize its usage (see #470) its near impossible to drop libswiften without dropping XMPP transport at all.

[ConiKost]

Hm, that doesn't sound good, as it's quite possible, that libswiften will be more and more dropped from distros in future.

While I'm already started to minimize its usage (see #470) its near impossible to drop libswiften without dropping XMPP transport at all.

I always thought, that could be replaced by the purple backend?

[vitalyster]

libswiften was not in "distros" since libswiften2, it was in maintenance mode for decade already.
I'm not sure you are fully understand what frontend and backend means in Spectrum context.
You are using it as XMPP transport? That part which communicates with your XMPP server is libswiften.
You can replace it with another XMPP library (which one? There are no good C++ XMPP libraries and Swiften was created to solve that) but it is a full rewrite of Spectrum "frontend" code. Nobody will do that because XMPP is dead itself.
The only correct way to remove libswiften dependency is writing new frontend, say ActivityPub frontend, to transport message from other networks on your Mastodon account, and drop XMPP frontend making XMPP fans cry.

[ConiKost]

Thanks, that makes it more clear. I always thought, that libswiften is only used for the xmpp backend, but not as frontend. So yes, I agree, replacement is problematic in that case.

Still, what does that mean for future? FWICS, as Debian dropped libswiften in testing, this would mean, Debian 13 won't ship the needed dependency? I am still using spectrum2 for myself. As I am the package maintainer for spectrum2 in Gentoo, we also have the situation, that net-im/swift (used only to build libswiften, not the full blown desktop xmpp client) does not build with current boost-1.83. At the end, this sadly means, I will have to drop spectrum2, as libswiften upstream is dead and I don't have the knowledge to patch the stuff by myself. And it's pretty obvious, that boost-1.83 will come to other distros too in future.

[vitalyster]

Again, there is no libswiften in Debian since libswiften 2. We always use libswiften from swift.im public Debian repo and from our packages.spectrum.im Debian repository these days. I did integrate some patches in https://github.com/SpectrumIM/swift (spectrum_dev* branches) but I'm not sure will it be enough to build with latest boost.

[vitalyster]

I can propose you to post Swift build errors in our Swift fork issue tracker and maybe we can find the solution

[ConiKost]

We always use libswiften from swift.im public Debian repo and from our packages.spectrum.im Debian repository these days.

Ah, now I get it. Sorry for the misunderstanding here. Does the swift.im deb repo has any packages for newer debian versions? I guess, for recent versions, you are providing them via packages.spectrum.im?

I did integrate some patches in https://github.com/SpectrumIM/swift (spectrum_dev* branches) but I'm not sure will it be enough to build with latest boost.

FWICS, I also have most of the same patches applied in our gentoo ebuilds, like python3 and older boost-1.69 stuff.

I can propose you to post Swift build errors in our Swift fork issue tracker and maybe we can find the solution

Thank you for the proposal. I will fill an issue, maybe you have an idea.

[ConiKost]

FYI: It is a bug. But not in swift, but in boost signals2 itself.

There are two patches for boost, which will fix it:
boostorg/signals2#70

[coldtobi]

Debian, for example, already dropped libswiften from debian testing.

(Very late to the dicussion) but the reason libswiften is not in testing is that spectrum2 is not yet ready for inclusion in Debian and I'd avoid to maintain such a big library in a stable release when it is not needed. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032724. Though I share that it is concerning that upstream developement seems to have stopped.

@ConiKost Thanks for the link to the boost bug!