Fellow bridgers, if you're reading this, it means that I have finally gathered the motivation to write this long due "Slidge progress notes" blog post. Hooray! A lot has happened for Slidge since the latest blog post, so I will not attempt to exhaustively detail all the small fixes and improvements that have made their way to the Slidge source code since latest January. Instead, I'll just list the main stuff.

A logo

This was not expected at all, but Trung, a new member of the XSF, offered to draw a nice logo for Slidge. I absolutely suck at anything design-y, so you bet I accepted it right away.

Slidge is not for end-users anymore

Following my initial plan, Slidge is not a Jabber gateway component anymore, but rather a library for making such components; it is intended for developers. In practice, this means that XMPP operators looking to set up Slidge on their XMPP server instances, should look at these projects and stop caring about Slidge per se:

• slidgnal (Signal)
• slidge-whatsapp (Whatsapp)
• slidgram (Telegram)
• slidcord (Discord)
• matteridge (Mattermost)
• sleamdge (Steam)
• skidge (Skype)
• messlidger (Facebook Messenger)
• matridge (Matrix)

The main repo of Slidge does not contain anything specific to any of these networks anymore: it is generic. While this change makes it slightly harder to navigate the Slidge ecosystem, it drastically increases the maintainability of the code for me (and hopefully future contributors).

I will not detail the changes that have happened for every "legacy" service supported by a Slidge-powered gateway, maybe I'll do a separate post about that later, possibly soon™. In short: they all improved substantially, Slidge-whatsapp, slidcord and matridge support group chats.

Code quality

It's nothing that end-users can see, but since the latest blog post, the Slidge codebase is a lot less crappy than it was. Now that I'm starting to have a slightly less blurry perspective on the problem space, I started doing a lot of (re)factoring of various parts. We're still very far from top-notch software engineering, but we're getting there. I also set up nice stuff such as test coverage reports, rules for commit messages, pre-commit hooks and this sort of stuff, that I discover as I go along.

Finally, a lot of what Slidge needs made its way into slixmpp (the lower-level XMPP library powering Slidge) for a 1.8.4 release.

Performance improvements

I wouldn't dare talking about "optimizations" just yet, but some work has been done in the realm of "stop doing things in the absolute worst possible way". The biggest change in this area is to not store all avatars in RAM but write them to disk instead (as I said: slightly better than it was). A shitload of stuff is still cached in RAM, but doing this way with images was really really bad.

Quite a lot has been done to reduce useless duplicated (or worse) network requests and stanza traffic emitted by Slidge in various situations.

Bugfixes

Oh I'm not going to list them all here. There are too many. Hopefully not too many new ones have been introduced along the way.

New features

MAM for groups

The biggest change since the latest tagged v0.1.0rc1, which by the way, you should absolutely not use anymore, because it's very outdated (use the debian package, the docker.io containers with the :master tag or the python packages built on each push), is the Message Archive Management support for groups. Unlike 1:1 message archives managed by the XMPP server, groupchat-providing components have to handle archives themselves. Slidge now does that, which is needed to ensure continuity in an "intermittently-online" context, such as mobile connections, and is supported by most XMPP clients now.

Threads support

Very few clients actually implement it, but in the XMPP world, threads are defined in the core spec. It was not a lot of work to support them in Slidge, and both matteridge and slidcord take advantage of this already. In practice, the only client I use where I see that is Cheogram Android… for now!

"Friend request" flow

This is a bit tricky to have in a generic way, as being a friend/contact/whatever means something slightly different on each legacy service. Anyway, Slidge now exposes methods for LegacyContacts to send "XMPP presence subscription requests", which are what we have that comes closer to this generic concept.

Some more

I'm tired of writing: bullet point time!

• Avatar for rooms and the participants
• Unique occupant-id support
• "Rich" (with status message, last activity, etc.) presence support in groups
• Auto-add MUC bookmarks and send invitations
• Adjust mimetype and file extension when needed (with filemagic, thanks Raver for the contribution!)
• More advanced Slidge-emitted attachments (SIMS and SFS)
• Optionally serve attachments with an external web server instead of using the XMPP server's HTTP Upload component
• Proper recipient-generated receipts for legacy services that have an equivalent of this - others will ack the message
• Emoji restriction (but no clients support that yet)

The future

If you followed the few posts I've made about Slidge, you probably have noticed that there is no clear road ahead. I'm mostly having fun and working on things that matter for my use of the thing, objectives change as time pass. There are no gantt charts or anything awful like that. The current plan is to keep on working on improving the code quality, bug-fixing what comes up and setting up more (or better) automated testing. I think the next big to work on is going to be proper persistent storage (read: a database) instead of the various shitty shelves used right now to write things on disk. We'll see…

As usual, thanks to all the testers, bug reporters, and people with kind words about all of this Slidge thing, it's very much appreciated. <3