Blog — nicoco.fr

Slidge: first beta of the 0.2 series

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

Thanks the testers and bug reporters, slidge version 0.2.0beta0 is out!

Release something, something often

We have been way too shy with releases in the past, so we started tagging versions more aggressively. This has several advantages and there are no good reason why we did not do it earlier, really:

Since the latest blog post was about slidge v0.1.0, we will list (only) the major changes that we have achieved for v0.2.0beta0, some of which were actually part of the v0.1.1, v0.1.2 and v0.1.3 releases.

Performance improvements

As planned, most of the work put into the 0.2.x series was about making slidge less RAM-hungry. There is definitely still room for improvement, but it looks like we have managed to avoid RAM usage growing constantly while running for several days, weeks or months; although I am unsure we have already reached the stage where it can run for months without needing a restart.

This was done by big refactors to ditch our hacky restart-persistent shelves for user registrations and avatar caching in favour of a proper SQL database. Then, more importantly for our matter, we could stop to store a bunch of python objects into RAM and spawn them only when needed from the data in our persistent storage, which is the right™ way of doing things.

This — almost — naturally came with some nice new features. Group archives are now persistently stored across restarts, allowing a better continuity in the history of bridged rooms. Users' avatars are also "remembered", avoiding useless legacy network calls to set the user's avatar when slidge is restarted.

Major new features since v0.1.0

Whether to share your avatar and your presence with the legacy network is now configurable on a per user-basis via a new "User Preferences" command.

Stickers that Movim and Cheogram Android send, using BoB and XHTML-IM are now supported.

Unregistering from a group (as opposed to just leaving a MUC from your XMPP client) is now supported through a dedicated command or using the standardised (yet not very commonly implemented) dedicated mechanism. It is worth noting that support for this mechanism is now available in gajim and nicely integrated into the GUI.

Banning a participant from slidge was already possible, but it is now also possible to kick without banning.

Image previews are now generated using the thumbhash algorithm instead of blurhash. This is also something that Movim and Cheogram both have support for.

Slidge-based gateways

All of them have been updated to be compatible with the slidge core v0.2 series. Most of them are now available on PyPI, with the notable exception of slidcord, which requires a unreleased version of discord.py-self, preventing a PyPI publishing, unfortunately.

Slidgram has been almost entirely rewritten to use pyrofork instead of aiotdlib, which is overall a better library to interact with Telegram. It is also easier to package as it does not depend on the huge TDLib C++ library. Surprisingly, despite being mostly pure python, pyrofork also seems faster and more lightweight than aiotdlib. 🤷

Both slidgram and slidcord now support animated vector stickers to the XMPP side by optionally converting them to videos using lottie-converter.

For more details about what has changed, see their respective pages on sourcehut.

What is planned next?

For the v0.2 series, we will try to add some more performance improvements and fix the bugs we find along the way, notably the ones introduced by these optimisations. Then, the 0.3 series should be where we add new features such as User Tune, Gaming and Mood. After or before that we will probably introduce support for inline custom emojis as Cheogram and Movim both support them now. Later, it would be nice to set up internationalisation of the texts exposed to slidge end-users.

Final words

We are immensely grateful to all of you who have tried to (and sometimes even managed to) install and set up a slidge-based gateway and reported back. Extra thanks for those who took the time to open tickets in our trackers since that makes following up on the reports easier than just a message in the MUC (which is appreciated nonetheless, <3).