close
  • OMEMO is broken in general across the ecosystem :(

    I along with a lot of other people have tried to test OMEMO and we've all spent some time trying to figure out what is going on with OMEMO on multiple clients and compatibility. I think I know at least one reason why clients on different platforms can't talk to each other. If you look at my earli

  • Mo chevron_right

    Movim 0.16.1 – Cesco

    Timothée Jaussoin · pubsub.movim.eu / Movim · Friday, 6 December, 2019 - 09:50 · 1 minute

Only a few weeks after the 0.16 release here is the 0.16.1 one!

This release includes several fixes and a few new features.

Features

You can now share posts to your connected chatrooms :)

Chatroom post sharing

Communities layout were a bit redesigned, publication rules are now displayed clearly in the right column and the header shows more information on mobile.

Communities redesigned

All the messages that you sent in the one to one discussions can now be edited.

Message edition for the whole history

The videoconferencing feature was heavily refactored and several issues were fixed during this process. A new XEP was also used partially to improve the call negociation flow, XEP-0353: Jingle Message Initiation.

Fixes

In the database an index was added on the key that was tracking contacts avatars. This sounds maybe a bit technical to you but this small fix boost quite a lot the performances during the login process, when you join a chatroom (especially that one) or when a contact updates his/her avatar. Because it's a database change you should run the database migrations when updating from 0.16 to 0.16.1.

All the entities that are on the XMPP network needs to declare what they are capable of to the others. This allows feature discovery and negociation and is specified in the #XMPP extension XEP-0115: Entity Capabilities. After the big code refactor of the handling of those #capabilities within the Movim codebase some other small improvements and fixes were done to wrap up properly this feature.

Presences sent to MUC are now generated the same way than those sent to contacts, this fixes #711.

DNS resolution errors an timeout are now handled properly displayed during the authentication flow (#368).

The SQL_DATE constant was renamed to MOVIM_SQL_DATE to prevent some naming conflicts (#820).

What's next?

PHP 7.4 was released a few days ago, so the upcoming version will focus on fixing issues to make Movim fully compatible with that version.

This new PHP release also includes an exciting feature that allows #PHP developpers to call directly C libraries in their codes. This could allow #Movim to directly use the libsignal C library and therefore (finally) allow OMEMO end-to-end-encryption to be implemented. This will be a lot of work and verifications so we're not promissing anything anytime soon. Stay calm please!

That's all folks!

#omemo #videoconference #jingle #release

  • movim/movim

    Movim - Decentralized social platform. Contribute to movim/movim development by creating an account on GitHub.

  • Pictures

  • visibility
  • chevron_right

    Protéger ses conversations avec OMEMO

    Adrien Dorsaz · Wednesday, 3 August, 2016 - 06:07 · 1 minute

Je viens de survoler le texte de la XEP d'OMEMO.

Cette extensions permet de chiffrer ses conversations avec ses contacts d'une manière originale: au lieu de faire un chiffrement par contact, l'extension prévoit de faire un chiffrement par client XMPP.

Ce que j'aime bien, c'est que le chiffrement avec OMEMO est compatible avec les principaux avantages de Carbon et de MAM (le premier permet d'envoyer un message à plusieurs client en même temps, le second de créer une archive sur le serveur pour que les clients qui ont perdu la connexion puissent retrouver l'historique complet des messages).

En réalité MAM perd une fonctionnalité: si j'utilise aujourd'hui un nouveau client XMPP, il ne pourra pas lire l'historique de mes conversations d'hier, car il est incapable de déchiffrer les messages. Comme cette fonctionnalité est un concept opposé au chiffrement, ça fait sens de ne plus l'avoir lorsque l'on décide de chiffrer ses messages.

Si j'ai bien compris, pour chaque message OMEMO génère une clé de chiffrement et chiffre le message avec cette clé. À côté du message chiffré, pour chaque client XMPP de confiance, OMEMO ajoute une entête avec la clé utilisée chiffrée avec la clé publique du client. Ainsi, le message réel n'est chiffré qu'une fois et tous les clients peuvent le déchiffrer (car chacun peut retrouver la clé qui avait été utilisée). Je trouve ça vraiment élégant :)