It has almost been two months since I announced slidge beta0. A lot has been fixed and improved during these two months, thanks to a few early adopters that I will never thank enough for their patience and time. All in all, it felt right to tag a new beta now.
I have never hidden it, I believe that emoji reactions to messages, as stupid as they may look to bearded TUI lovers, are an awesome instant messaging feature. They are a convenient way to acknowledge that you have a read a message and to signal whether you approved its content or not. The chat markers XEP proposed an acknowledgement mechanism, but as far as I know, no XMPP client ever implemented the
Arguably, reaction emojis offer a richer experience than a single "ack" button anyway.
Slidge implements XEP-0444 and most plugins use this core feature of slidge. The specification is very permissive: a single chatter can react with several emojis, and can use any emoji to do so. A lot of legacy networks are much more restrictive: on signal for instance, you can only react with a single emoji; on telegram, you can only use a subset of emojis, etc.
To reflect this limitation on the XMPP end, slidge takes advantage of the privileged entity XEP, to impersonate the XMPP and adjust their reactions so that they are in sync on both ends.
Movim was the first XMPP client to implement XEP-0444, but when slidge beta0 came out, Movim didn't implement it in a way that made it possible to reflect legacy networks limitations. But edhelas was very reactive (hoho) about it, and it's now fixed, as you can see in the short clip below.
Although not released yet, the dino team merged reaction emojis to the master branch, and I gave it a try. This lead to a few bug reports to the dino tracker, which in turn triggered some fixes in slidge to follow the specification more rigourously.
jcbrand, maintainer of the conversejs client, also dropped by the slidge MUC to say that seeing the reactions implemented in slidge motivated him to have them in conversejs too. A very pleasant surprise!
I don't think I will add new features for the 0.1.0 release, except maybe, maybe some history backfilling mechanism but that is still undecided. What would be really great is having more people testing out all the different plugins. As of now, I believe only the telegram and signal plugins have been tested by others than me. Testers, please give all slidge plugins a try and share your feedback!
I had MUCs sort of working on the previous slidge iteration, but decided to postpone their support in order to focus on having direct messages working properly with a maintainable codebase. Since MIX seems to gain some traction, it may also be supported in 0.2.0. I have yet to dive into both specs a little more before deciding what is more appropriate to implement.
Here are some ideas that might be more than ideas someday.
Since legacy networks are likely to change their APIs, I think it would be nice to have different release cycles for slidge core and plugins. For the same reason it may also be useful to have some sort of plugin installer/updater builtin within slidge.
Slidge may enter the official debian repos someday...
The best library available to interact with the whatsapp network is written in Go, so most work that has been done until now was about determining how to make it possible to use it from python. Hopefully, the work put into this will help writing plugins for other networks where only go bindings are available, such as threema.
This also allowed to add support for vcards over XMPP, which I think are mostly useful for phone number-based networks. Only Movim and Gajim support this XEP for now, unfortunately.
Thanks to IGImonster and contributions from azerttyu, slidge now offers debian packages for amd64 and arm64, and even a repository so you can "apt update" your way to slidge.
The containers on dockerhub now support the ARM64 architecture (previously only amd64).
Thanks to the feedback of ejabberd users, various changes have been made to ensure that slidge works with ejabberd: