Blog —

Slidge v0.1.0

2024-04-09 subscribe to my blog's atom feed

Howdy, fellow instant messengers!

Just in time to be featured in the 50th XMPP newsletter, Slidge v0.1.0, the Python library used to create gateways to other chat networks, has landed. "Why now" you may ask? Because it has been working reliably enough for a few of us users; also, we needed an excuse to communicate a bit so the world knows that Slidge's world domination plan is still ongoing.

Thanks to debacle (thanks dude! 😻) Slidge is now packaged in the debian official repo along with Matridge, the XMPP/Matrix bridge. It's also available from PyPI and sourcehut and Slidge-based gateways are available as containers on docker hub.

We won't list the bugfixes and small improvements since the latest blog post (there are many of them, and many more to come) but here are the notable features that were added.

New features in Slidge core

Presence and avatar synchronization

Your XMPP presence (available, away, busy…) and avatar can now be propagated to the legacy IM networks that support them. At the request of a few users, this behaviour can be opted out by the slidge admin. In the future, this setting will be customisable on a per-user basis, but as of now Slidge does not have a way to store user-specific settings besides credentials.

Group stuff

Besides support for hats, new group features are related to administration and moderation of XMPP multi-user chats, what most IM networks call "groups". Most of the basic group management features you expect from an IM app are now supported, including:


Slidge now provides a generic way to support characters in group participants nicknames that are not valid JID resource parts. This only works with Cheogram so far, in other clients you see a punycoded version of the nick, which is not excellent but readable enough. Now we need to convince gajim maintainers that it's a good idea to merge support for decoding punycoded nickname, and then other client developers too. Two other Cheogram-specific features were added: blurhash previews of images from the bridged network and sender-generated link previews.

Message Display Synchronization, a new XEP to improve read state sync between XMPP clients, is now supported, and most actively-developed XMPP clients should add support for it soonish.


Predictions are hard, especially when they are about the future - a clever person

Premature optimisation is bad as we all know, but doing something about RAM usage for Slidge sounds reasonable at this point, as this has been the main non-trivially-fixed complaint that early adopters have reported so far. This is not unexpected, a shit-ton of objects are cached in RAM forever by slidge, which is not a great design at all. Taking this shortcut did make it possible to ship something somehow functional as a free-time project though. Reaching this point where the next big thing is optimizing resource usage feels great, as it means we have reached a stage where Slidge offers reasonables features for end-users and is stable enough for admins of small XMPP servers to run. It was never obvious that this would happen some day.

Improving RAM usage goes hand in hand with a complete rewrite of the persistent storage code. We'll take this opportunity to make group chat history persistent to avoid "holes" in history when Slidge crashes is updated by the admin on updates, and implement user-specific preferences, eg, whether or not to propagate the XMPP Avatar and presence to the bridged network.

This should be what Slidge v0.2.0 brings, when it's ready. Then we'll probably add support for fancy XEPs such as User Tune, User Gaming, User Mood or User Location, and keep on improving the developer docs, trying to make slidge more contributor-friendly.


These were the news about slidge "core", the library, where most work has been done. Let's see what's been cooking in the actual gateways based on slidge.

Slidge "legacy modules"

The best one: slidge-whatsapp by deuill

Work has been poured into closing gaps for strange requirements set by WhatsApp, primary of which is media (e.g. image, audio, video) file support; here, WhatsApp places heavy restrictions on what file-types can be used for any given interaction, for instance, only Opus-encoded Ogg files can be used as voice messages, while animated GIFs aren't actually GIFs, but MP4-encoded video files. Go figure.

With FFMPEG to the rescue, we're able to convert files between the free-for-all that is the XMPP client ecosystem, to the highly regimented world of WhatsApp.

Other changes include: more robust presence synchronization between XMPP and WhatsApp, avatar synchronization, pairing via SMS-based one-time code (useful for registering without having to scan the QR code on a separate device), as well as experimental group management, improved history synchronization, and bi-directional mention support.

Next cycles will have us work on implementing more exotic parts of the WhatsApp protocol, such as Broadcasts, Status Updates, Communities, location messages, polls, as well as bringing in any improvements made to Slidge Core and WhatsMeow, our underlying WhatsApp client library.

Other good ones

The following ones work as well as the best one, but either lack a few features or lack the thrill of breaking the terms of services of the bridged network.

The bad ones

  • slidgnal (gateway to Signal) now supports setting the user's avatar. Unfortunately, registering a new signal account from slidgnal and linking slidgnal to an existing signal account are both broken until libsignal is updated in signald (the lib we rely on) or we switch to another lib. It's not completely broken, if you registered or linked your account before signal deprecated the legacy API, message still go through.

  • skidge (gateway to Skype) has not had any updates besides the improvements brought by slidge core updates. I actually have nobody that talks to me there anymore; I think it still works but I don't actually know for sure and don't really care. If anybody wants to step up and become a maintainer, come by our MUC to discuss it!

  • sleamdge (gateway to Steam Chat) saw group support added, and is almost usable. Almost because unfortunately, the gateway silently loses connection after a few hours/days and thus does not offer a reasonable UX. I have not been able to free enough time to report it upstream properly to the lib we use, but it is actively developed and the maintainer is very reactive, so we should be able to fix it soonish™.

  • messlidger (gateway to Facebook Messenger) now supports groups but sad news, it cannot send messages anymore because of upstream API changes and the fact that the lib we built messlidger on is not maintained anymore. We need to switch to its successor which is written in go unfortunately. This didn't stop us for Whatsapp, so there is hope.


That's it, folks!

Thanks a lot to raver, Aidan, Neko, procrastinator, Quinn and the bug testers, bug reporters, those who just drop by the MUC to say thanks, and those I have forgotten. We love you all! <3