Following last month's 0.30 Encke important upgrade here is the first bug-fix release!

What's new?

Animated pictures support in the image proxy

Movim is proxying all the pictures to recompress and cache them along the way (the cache needs to be configured in your web server, see the dedicated documentation for that).

For animated GIFs, it used to only take the first frame and compress it in WebP, like for all the other pictures. Now Movim tries to turn it into an animated WebP!

The Picture Proxy was also refactored to handle some cases with some buggy picture URLs.

New Avatar and Banner Configuration Panel

The avatar and banner configuration panel was redesigned to give you a nice overview of your final profile page.

XEP-0392: Consistent Color Generation support! 🎨

The internal color palette handling was refactored and slightly adjusted to integrate better with the Accent Color feature introduced in 0.30. A few new colors were added along the way.

Movim is now implementing XEP-0392: Consistent Color Generation. This means that the same user or content will have the same colors on all your different XMPP clients. ✨

Slight adjustment of the ChatroomPings service

Movim is implementing XEP-0410: MUC Self-Ping (Schrödinger's Chat) to ensure that you are still connected to your chatrooms even if there is no activity in them. The ping-pong system was a bit too sensitive and could declare a disconnection in some cases; the timeout was adjusted to prevent most of those unfortunate disconnections from happening.

Dropping MySQL support

Movim had "MySQL" and PostgreSQL support for a while already. The original MySQL database was forked as MariaDB and both started to evolve very differently the past few years. MariaDB finally became the "default" database in most of the Linux distributions.

The two databases were always considered as "flavors" until now, but only MariaDB was extensively tested with PostgreSQL during development.

It seems that the now MySQL DB is not compatible with Movim anymore and will require very specific support to fix all the migrations and some queries that are not working anymore on it.

It was therefore decided to only keep the PostgreSQL and MariaDB support, PostgreSQL still being the (strongly) recommended one.

What's next?

Going back to the multi-participant calls project, lots of exciting things to do! Stay tuned. ☺️

That's all folks!

#movim #release #xmpp #features #database #colors #mysql

Only a few months after the previous version here comes Movim 0.30, codename Encke ☄️

This release is actually way bigger than you might think! Indeed, during half a year a lot of work was poured into the part II of the Movim Live project that has been the biggest evolution in Movim for many years. This side project was finally merged and stabilized in the main branch and we are proud to unveil it to you 🤩.

Movim Live, Part II

Funded by NLNet, the Movim Live project's aim is to bring a modern and complete stack of video-call features to Movim and to create a strong alternative to the other proprietary and centralized platforms.

The Part I goal was to modernize the existing one-to-call call stack. Part II was to bring multi-participant calls, and we did it!

How was it done?

Movim is now implementing XEP-0272: Multiparty Jingle (Muji) combined with XEP-0482: Call Invites. The first XMPP extension, called Muji, allows a user to join a temporary chatroom and initiate an audio or video call with any of the participants inside it. The second one allows this user to be invited or invite contacts to join this "Muji Chatroom".

Another client is already implementing those two XEPs, Dino, and it's actually the first time that we have two clients on totally different stacks (one is a desktop client, the other one a web application) that can do multi-participant calls on a standard protocol.

How can I create a group call in Movim?

The flow is quite close to a one-to-one call, except that you start the call in one of your group chats.

The group call will then appear in your chatroom list, similar to what you can find on Discord. The other participants will then get an invitation and will be able to join the group call once their camera and microphone are set up correctly.

What can I do in a group call?

Once you're in, Movim offers a couple of nice features to enjoy the call.

You can toggle between the grid view and the "active-speaker" view (where the actively speaking person is put in front). When using the grid view, the speaking person's microphone is slightly bigger and blinking in green.

The existing screen-sharing feature has also been ported to group calls, allowing you to share your screen with the others. More work will be done on the part to allow you to stream your screen and webcam simultaneously and use Movim as a nice stream-gaming platform or live-conference tool in the future ✨.

A lot of work was also spent on ensuring a proper integration of the call in the user interface and the user flows. When you're in the chatroom, the group call is integrated into the chat view, and when you leave the discussion, it moves automatically in the corner. You can also put the group call in full screen at any time.

And as always, you can toggle your webcam and microphone off any time.

Movim Live, Part III

So what's next? In the upcoming and last part Movim is actively working with the ProcessOne team on a new set of XMPP extensions to bring massively scalable group calls in XMPP.

The current Muji flow is to initiate a one-to-one call with each of the Muji call participants, as you can see it doesn't scale that much. An SFU, or Selective Forwarding Unit allows you to call a specialized server, send your video and audio streams and receive the other participants streams in return.

This should require standardizing two new XEPs:

• One to allow declaring an SFU server in a Muji Call
• One to allow chatrooms to have permanent call rooms to join

The current flow is an "invite-based" one; this means that once everyone leaves the group call, it is automatically destroyed. We would like to allow chatroom admins to create one or several "call rooms," name them, and allow their users to join and leave the calls at their convenience. This will bring a more modern experience and bring many new ways of interacting with audio and video calls in XMPP.

Hopefully this Part III should be delivered in the upcoming months; stay tuned!

What else?

The 0.30 is also bringing some other exciting features 🤩.

The reactions are now displayed in the detailed message view.

Some parts of the UI were modernized and simplified, such as the emoji picker view or the navigation bars.

Movim is now supporting Unicode 15.1 with plenty of new emojis to use 🥳.

When one of your contacts is publishing a new Story his avatar will change, allowing you to easily open it.

The Movim UI, and especially color management, was also deeply refactorized and simplified. The Light and Dark modes are better looking and an exciting Accent Color feature is now allowing you to customize your Movim even more 🎨.

See you soon!

So that's all folks ✨.

We hope that you'll really enjoy all those new features. If you're a server admin we invite you to add your server to join.movim.eu and join the federation.

We would also be really pleased if you share Movim around, invite your friends to join, and talk about it. Movim can be a really nice open-source, federated and standard alternative now. Let's grow the community ☺️!

Thanks again to all the contributors, translators, and other bug finders that allowed this exciting version to be launched 💕.

See you next time 😘.

#movim #release #xmpp #nlnet #videoconference #groupcall

In this #release you'll find some important fixes and improvements; let's have a look. 😉

Set minimum PHP version to PHP 8.2

This change was initially planned for the next major version but some dependency issues forced me to raise the minimum PHP version required by #Movim to 8.2. PHP 8.1 was already in EOL anyway.

Fixes and improvements in file upload

The file upload code was slightly refactored. It fixes a crash when the filename was too long (the filename is then shortened and a hash is added at the end).

When uploading a file from Movim their name is also prefixed with post_, chat_ and story_ regarding from which part of the UI they are sent. This feature was requested many times by the admins to allow them to organize and expire them properly (for example after 24h for Stories files, unlimited for Post files).

Fixes Pubsub ordering

ejabberd and Prosody don't return the requested #Pubsub items the same way, most recent first for ejabberd and earliest first for Prosody. The XMPP protocol doesn't specify any default order so Movim is now automatically checking the order based on the articles publication time.

Reconcile the nullable state in some tables

It seems that a small change in the internal Movim database library (Eloquent) changed the behavior of some migrations along the way, this version reconcile those differences (some SQL columns were not nullable as they should).

Update fabiang/sasl to fix Update of the SASL SCRAM Downgrade protection XEP #17

Movim is now integrating the upgrade of the XEP-0474: SASL SCRAM Downgrade Protection XEP and the proper integration of the RFC 5802. This solved the connection issue on some #XMPP servers and fixed a risk of attack in the #SASL stack.

What's next?

Hopefully the next version will be a 0.30 and will integrate some pretty big changes, especially on the video-conferencing part. Stay tuned!

That's all folks ✨

Here comes the first bugfix release of the year 🎉

The 0.29.1 comes with a more polished and improved Stories feature, database fixes as well as some preparatory work for the PHP 8.4 version.

This release will be the last one to support PHP 8.1. PHP 8.2 and above will then be required for Movim 0.30.

Polishing the Stories feature

In the 0.29 Movim introduced the Stories feature, it is even now showcased on the main website.

This release fixes a few quirks introduced in the last version:

• When viewing Stories between different browsers on the same connected account the "viewed" synchronization is now working properly.
• It is now possible to publish Stories without having a camera enabled (or no camera at all), you'll then be able to just pick an image file from your device gallery.
• The play/pause buggy feature was fixed with a new timer (which was also used in the Chat dictaphone fixing some recording timer problems).
• Close the Stories viewer using the previous button or Esc key.

Preliminary work on PHP 8.4

The brand new PHP 8.4 release introduces a lot of interesting new features... but also deprecates some old syntaxes and enforces strong typing for some extensions.

Most of the errors were fixed in the Movim code but the dependencies need to be updated to ensure proper compatibility with this version, this update will drop the PHP 8.1 version (that is now in end of life). So we are suggesting to start to update to at least PHP 8.2 to prepare for the upcoming release.

Database fixes

The most important fixes of this release are related to the database. A serious issue with chatroom presences that was preventing Movim to handle some of them was fixed (issue #1386). This fix leads to discover a more serious issue that was there for more than two years (!) and that causes some presences to be deleted from the cache unexpectedly (issue #1357).

Those changes come with some database migrations, don't forget to migrate when updating Movim!

The translations were also updated, a big thanks to all the translators 🫶

That's all folks! ✨

#movim #release #xmpp #stories #database #sql

New year, new #release ! This time with plenty of new exciting features, let's have a look at them. 😊

Stories

The past few years several chat platforms tried to blur the line between their chat and social features.

Stories are a very nice way to share content with your contacts and allow them to react easily by chat.

Movim 0.29 is the first XMPP client that implements Stories. A specific XMPP extension, XEP-0501: Pubsub Stories, was created to standardize and allow perfect compatibility with other clients on the network. XMPP is once more showing its capability to be a perfect protocol to build this kind of feature and deploy it easily across a large network of compatible clients.

While writing this article some other XMPP clients are already planning to implement the feature.

You'll be able to create a new Story by taking a picture directly with your camera or select one from your gallery, edit it, add a small text and publish it to your contacts. Your story will then be available for 24 hours, and your contacts will be able to comment on it by sending you a chat message.

In the upcoming versions more features will be progressively added to complete those ones. If you are looking for a feature in particular feel free to drop a comment or a message in the support room. 😌

Briefs

This version is also introducing Briefs, a simpler way to publish content on your profile or in your Communities.

Until now you were invited to write posts having a title and a content. Briefs allows you to directly publish a short text to your contacts like on Mastodon, Twitter or Bluesky. If you feel the need to express yourself in a more "bloggy" way you can always switch back to the complete experience.

Some refactoring was done in the database and user interface to better integrate Briefs in the feeds.

But also...

An important refactoring was done regarding how the internal dates and times were handled. Now each connected user is sending its own timezone on login and all the times are generated dynamically using those timezones; this solves some weird calculated hours during the switch between daylight saving times.

Lots of fixes were done in how the chat discussions are handled and cached. This is fixing a few erratic behaviors in how chat discussions were ordered and their related notifications displayed.

And as always some database, user interface and JavaScript fixes.

Some news from the Movim Live project

The Phase 2 of the Movim Live project is finally getting in shape. Movim is now able to start and join a multiparticipant call and get their cameras and microphones. This required some important refactorings in how the calls and media streams were handled internaly, you can follow the dedicated branch there Pull Request: Multiparty Jingle.

This second important phase should be finished in a few months and a dedicated version (maybe a 0.30 ?) will be published then.

In the meantime lets enjoy all the new exciting features.

Happy New Year to all the #Movim and #XMPP users 🎉

That's all folks!

#stories #briefs #story #brief

tldr; On the night between the 2nd and 3th of October 2024 a corruption of the mov.im instance HTTP cache allowed several users to be connected as another person. Only one account was affected.

This issue only affected the mov.im instance and doesn't apply to the Movim project itself.

The nxing location issue

On the 2nd of October evening a new #nginx #configuration was pushed on the mov.im virtualhost. This configuration is using fastcgi_cache to #cache some URLs and lighten up the load put on the PHP side and therefore Movim.

The existing configuration looked like this:

server {
    server_name mov.im;

    location /picture {
        set $no_cache 0;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location / {
        set $no_cache 1;
        if (!-e $request_filename) {
            rewrite ^/(.*) /index.php?query=$1 last;
        }
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;

        add_header X-Cache $upstream_cache_status;
        fastcgi_cache nginx_cache;
        fastcgi_cache_valid 200 301 302 1h;
        fastcgi_cache_bypass $no_cache;
        fastcgi_no_cache $no_cache;
    }
}

The fastcgi_cache module is by default enabled for all the .php files called, is disabled for all the URLs except for the /picture ones. The reverse logic is what made things a bit confusing there.

The configuration change added a new section:

    location = / {
        # Introduced configuration
    }

This new section was applied only to the root https://mov.im/ requests but didn't contained the $no_cache parameter line.

The second confusion came with how nginx is handling their locations blocks. The DigitalOcean - nginx location directive examples explains it quite clearly.

Some locations blocks definitions are used or passed to the next matching one:

3. NGINX location block for a directory The following location block will match any request starting with /images/ but continue with searching for more specific block for the requested URI. Therefore the location block will be selected if NGINX does not find any more specific match.

And some others don't:

2. NGINX location matching exact URL NGINX always tries to match most specific prefix location at first. Therefore, the equal sign in the following location block forces an exact match with the path requested and then stops searching for any more matches.

The new introduced block (location = /) behave like the second definition. nginx basically used it and stopped there, applying cache to it without jumping to the "default" one location /.

The consequences

One of the mov.im users, lets call it Matt (name was changed) had a quite intensive activity on the instance, he basically created a little script to login and logout each 2-3 minutes to check a few parameters. This was not the cause of the issue but this activity raised the chances that he was the first one to hit the / URL when reconnecting.

The PHP script processed the XMPP authentication successfully and set à cookie to Matt to let him enjoy Movim.

The new nginx faulty configuration cached this call.

The following hours many new users that tried to authenticate reached this URL and nginx directly returned the cached version... containing the cookie created especially for Matt.

And then suddenly lots of persons were Matt.

Fixing the issue

Early in the morning, waking up, I was notified personally and on the support chatroom that some users were connected as other users.

The mov.im instance was disconnected as well as the nginx configuration.

I contacted Matt personally explaining the issue and asking him to change his password and started an investigation. A few small but not directly related issues and improvement concerning the session management were fixed.

The actual one was found by searching the nginx cache for cookie content and I quickly figured out that the new nginx configuration was the cause of that.

Aftermatt/aftermath

The configuration is for now reversed to the old one and the nginx cache is disabled, I'll try to find a cleaner way to re-enable it to prevent such issue to pop again in the future.

Only Matt (the first one to hit the cache) was affected by this issue so normally no other account were affected by the issue. If you logged during that night on mov.im I'd still recommend to change your password just in case.

That's all folks, and sorry for the mess.

edhelas

#security #issue