• chevron_right

    End to end encryption in Movim - OMEMO is (finally) there!

    Timothée Jaussoin · / Movim · Wednesday, 15 December - 22:01 edit · 7 minutes

A few days ago I finally closed the OMEMO encryption ticket on Github. Opened in 2015 it had many twists and turns along the years but I finally found a proper way of integrating it in Movim.

In this article I'll explain why adding #E2EE (End to End Encryption) was not as easy as with the other #XMPP clients (and more generaly all the chat clients that are using a similar encryption protocol) and how I addressed the issue.

But before going in the details I'd like to thanks the NLNet Fundation for its financial support in this project. With their help I was able to free-up some time to work on the problem and propose a proper architecture (detailled bellow) for it.

NLNet Foundation logo

The result of this work will be released with the upcoming 0.20 version of #Movim. There is still some quirks and whims about it but the base is there and works pretty well.

End to End encryption in XMPP, a quick overview

The introduction of Signal in 2015 brought a small revolution into the encryption protocols in the IM ecosystem. The Double Ratchet Algorythm (see the dedicated technical documentation on the Signal website) allowed users to exchange messages between different clients in an “end to end encrypted” way (only user devices themselves know how to encrypt and decrypt messages) with some technical improvements (not detailed here) that made the new protocol a “must have” for all the others IM solutions.

Today the Double Ratchet Algorithm is used in applications such as WhatsApp or Matrix.

In the XMPP ecosystem it was primarily pushed by Daniel Gultsch in the client and standardized along the way in the OMEMO XMPP Extension XEP-0384: OMEMO Encryption. Throughout the years many XMPP clients implemented OMEMO, their status can be tracked on the following website Are we OMEMO yet?.

The OMEMO architecture

Without going too deep into the technical details the general idea about OMEMO is to generate some keys on each of the user's devices and publish the public ones on their account server.

Using the keys published on the XMPP user's servers, anyone can then start an encrypted session at any time (the servers are always available) and start to send messages to the desired contact without having to wait.

Publishing keys and building sessions with OMEMO

If one of the user's contacts wants to start an encrypted discussion they will first start to get those keys, then build sessions with their secret one and encrypt a message using the freshly built sessions.

If a user receives a new encrypted message and doesn't have an encryption session to that device, their device will then retrieve the contact keys, build the encryption sessions and start decrypting messages.

This can be done automatically if the contact trusts blindly the key used or in a more “trusted” way by accepting manually each keys to build the encryption sessions on.

All the existing XMPP clients are using this simple architecture. XMPP servers are storing their users' #OMEMO public keys and the users are connecting directly using their different devices to build their encrypted sessions.

The Movim particularity

But Movim is kind of special. The XMPP connection is actually not maintained on user devices but by the Movim server (built in PHP and running behind a web server such as Apache or nginx, see Movim General architecture on the Wiki). Movim is then processing everything server side, saving the information (articles, contacts and messages) in a SQL Database (PostgreSQL or MySQL) and then showing the result to the Movim users through a lightweight website.

If a user is connecting on the same Movim instance through several browsers using the same XMPP account all the browsers are then “merged” into one unique XMPP session (called "resource") and all the browsers are synchronized in real time by the Movim server. This is pretty useful to save memory and to prevent Movim to maintain several XMPP connections at the same time for a unique user. This also allows quick disconnection/reconnections, the users can close and reopen their tabs without having to reload the whole XMPP state when they come back after a while (Movim is closing the XMPP session after a day of inactivity).

End to end encryption actually requires to encrypt and decrypt messages on the user device, this brings several issues:

  • For Movim, the user device is actually a “dumb” browser that only display the messages pre-processed by the Movim server, there is no logic whatsoever browser side
  • A user can use simultaneously several browsers with the same XMPP connection on the same Movim instance
  • All the message processing logic is done server side

This unique architecture requires a very unique way of adressing the E2EE situation. Hopefully OMEMO offers all the tools needed to handle those cases.

Split the logic

The OMEMO extension is actually talking about devices, for a large majority of the XMPP clients a device is connected through a unique XMPP session (one device equal one current XMPP resource in those cases).

Publishing keys with Movim

The fact that Movim is sharing a unique session (resource) with several devices (browsers) is actually not an issue in the end. Each browser will then be considered as a unique device on its own, with its own key and its own OMEMO encrypted sessions.

Building encrypted sessions with Movim

This brings some interesing results. When a user is connected using the same XMPP account using two different browsers on the same Movim server (also called instance, or pod), an encrypted message sent by the browser Firefox will then directly be decrypted by the browser Chrome without even having to travel through the XMPP network.

The term “browser” is also defining more than actual browsers (like Firefox, Chrome or Opera). Since we can have private navigation or containers (in Firefox) each time it is seen as a different “browser” on the Movim side (because each context is separated, with a different cookie and different local data).

So the global idea is to continue to handle the messages server side, push the encrypted message object to the browser, and then implement only the key handling and message encryption-decryption flow browser side. When doing this implementation I actually looked at the Converse.js and JSXC OMEMO implementations, the Movim implementation is really close to the one done on those two clients (I am also re-using the libsignal JavaScript implementation).

This architecture actually works for the current version of OMEMO (0.3.0) where only the body is encrypted. The upcoming versions are looking to encrypt a larger part of the XML stanza. This will be way more difficult to handle for Movim, as it will require to decrypt messages browser side and then implement a second parser, this time in JavaScript (everything is parsed in PHP using libxml at the moment).

if (textarea.dataset.encryptedstate == 'yes') {
    // Try to encrypt the message
    let omemo = ChatOmemo.encrypt(jid, text, Boolean(textarea.dataset.muc));
    if (omemo) {
        omemo.then(omemoheader => {
            xhr = Chat_ajaxHttpDaemonSendMessage(jid, tempId, muc, null, replyMid, mucReceipts, omemoheader);
} else {
    xhr = Chat_ajaxHttpDaemonSendMessage(jid, text, muc, null, replyMid, mucReceipts);

This little JavaScript Movim code extract presents the differences in handling encrypted and unencrypted messages. The text variable is containing the clear text version of the message. When the body is encrypted it is then calling the same method as for a clear text message.

This method is actually a wrapper generated by the RPC (Remote Procedure Call) Movim server core. Once this function is called an Ajax called is made and the rest of the flow is handled server side. The encrypted body, and generated OMEMO headers passed will be injected in a freshly generated XMPP XML <message>.

Keep the messages in the local database

With the separation of the logic it was then required to keep a copy of the decrypted messages browser side.

To do that an IndexedDB database is used. This database is quite simple and only contains a key-value store, where the key is the message id (the same as the one in the Movim server SQL server databse) and the value the plaintext message.

  • When a message is decrypted the plaintext body is then stored in this database.
  • When the user sends an encrypted message, the original text is also saved in this database.
  • If a message cannot be decrypted, the message key is still saved in the browser database with a false value. This prevents Movim to try to decrypt several times a message, knowing that the decryption will fail each time in the end.

Using this database, when a chat is loaded, all the messages are then sent chronologically from the server, passed trough a little bit of code that will lookup the state of all messages and then decrypt the ones that are not decrypted yet, the already decrypted messages are then shown, or an error is displayed for those that cannot be decrypted.

To sum up

In this article I tried to present you what limitations I faced when trying to implement end to end encryption within Movim and what architectural and technical solutions were used to address them.

The current solution seems to fit and bring all the desired features to Movim without too much downsides. The feature can now be considered as done and will be released soon. And as always, lots of small fixes and adjustments will be integrated to polish it afterward.

That's all folks!


  • favorite

    8 Like

    Sal, Kris, Matt, Jorge Luis, U, matlag, Marzanna, Alexander


  • person

    23 December stefan

    Great work! Does OMEMO also work for group chats?

    I'm however a little worried if the Javascript handling the keys is served by the same server which e2ee protect against. If I understand correctly, a malicious server operator could easily extract my private key by (temporarily) serving a modified, malicious version of the Movim frontend.

  • 31 December Alexander

    Bon boulot

monocles chat is an Open Source XMPP/Jabber Messenger for Android Messenger App Ein Jabber/XMPP Client für Android Smartphones, der für ein einzigartiges mobiles Erlebnis optimiert wurde.

#xmpp #OMEMO #e2ee #Encryption #Jabber #monocles #blabber #conversations

  • chevron_right

    Debian - Profanity - OMEMO

    Stefan · Saturday, 18 September, 2021 - 06:35 edit · 1 minute

Profanity in Debian GNU/Linux

In Debian 11 ("Bullseye") ist Profanity 0.10.0 verfügbar. Installiert werden kann es mit dem Befehl apt install profanity. Profanity ist ein ncurses basierter XMPP Client.

Schlüssel generieren

Hat man sich in profanity erfolgreich mit seinem XMPP Account angemeldet, muss man zur Verwendung von OMEMO das Schlüsselmaterial erzeugen lassen. Dies kann mit dem Befehl /omemo gen erstellt werden.

Jedes OMEMO fähiges Gerät hat eine accountweite eindeutige Device-ID sowie einen Fingerabdruck. In der Profanity Console (/win 1) lassen sich mit dem Befehl /omemo fingerprint alle eigenen Fingerabdrücke anzeigen.

07:58:17 - Your OMEMO fingerprint: 5284ea0c-42d698b8-9e8bc07d-daa9c4fb-d9d02814-53847b59-7b85479a-e03fca20
07:58:17 - user@domain.tld's OMEMO fingerprint:                                                       
           3cb71f98-3e167abf-ae8352d3-3dd5f6d9-bc9f74fa-95e787af-fed55fa5-0a62315b (trusted)              
07:58:17 - user@domain.tld's OMEMO fingerprint:                                                       

Schlüssel vertrauen

Vielleicht möchtest du Nachrichten, die du verschickst, auch auf deinen anderen Geräten lesen? Dann kannst du mit folgendem Befehl deinem Schlüssel vertrauen.

/omemo trust user@domain.tld 3641e6ba-fddd542f-cfd69a4c-e5907193-d0682001-28a4c1b5-4971b4ea-a057b717

PS: Du musst den Key nicht per Hand eintragen. profanity kann Autovervollständigung via [TAB]-Taste.

Dieses vorgehen lässt sich auch auf die Schlüsselverwaltung deiner Kontaktpersonen anwenden.

/omemo fingerprint buddy@domain.tld 


Ein Fenster zu deinem Chatpartner lässt sich mit dem Befehl /msg Nickname oder /msg buddy@domain.tld starten. Im geöffneten Chatdialog kann auf die JID bei der Abfrage der Fingerabdrücke verzichtet werden. Ein einfaches /omemo fingerprint ist ausreichen, um noch mal über die Schüssel des Partners drüber zu gucken.

Mit dem Befehl /omemo start wird die OMEMO Verschlüsselung aktiviert. Wurde eine OMEMO für einen Kontakt aktiviert, wird diese Informationen in den Account-Einstellungen gespeichert, um in Zukunft auch OMEMO direkt zu aktivieren. Beendet werden kann sich Session mit /omemo end. Das Verhalten kann mit dem Befehl /omemo policy beeinflusst werden.


Dateitransfer via OMEMO lässt sich normal mit /sendfile und /url save bzw. /url open verwenden.


Debian bookworm verfügt über die Version 0.11 von profanity. Hierzu werde ich einen eigenen Beitrag machen.

Viel Spaß beim chatten!

#Debian #Profanity #OMEMO #Bullseye #XMPP

  • Be chevron_right

    Year of the OX: OpenPGP for XMPP

    debacle · / berlin-xmpp-meetup · Monday, 1 February, 2021 - 02:02 edit

In February 2021, this month, starts the year of the ox. At Berlin XMPP meetup, we will celebrate the new year with an introductionary talk about "XEP-0373: OpenPGP for XMPP" and "XEP-0374: OpenPGP for XMPP Instant Messaging" and the panel of experts:

  • DebXWoody (implementor of OX in Profanity)
  • defanor (implementor of OX in rexmpp)
  • Florian (co-author of the OX standards)
  • lovetox (implementor of OX for Gajim)
  • Paul (implementor of OX in Smack)

When? Wednesday, 2021-02-10 18:00 CET (always 2ⁿᵈ Wednesday of every month)

Where? Online, via our MUC ( A Jitsi video conference will be announced there.

See you then!

#yearoftheox #openpgp #xmpp #ox #jabber #encryption #e2ee #privacy #omemo #🐂️ #berlin #meetup #community #profanity #rexmpp #gajim #smack

  • chevron_right

    (brouillon) Messagerie instantanée : comment allier communication et liberté de manière durable / Partie 2 : Comment faire ?

    Yannv · Friday, 29 January, 2021 - 22:13 edit · 11 minutes

En cours de rédaction, n'hésitez pas à me faire part de vos remarques, oublis, erreurs éventuelles.

Messageries instantanées : Partie 2

COMMENT peut-on profiter du mouvement autour de #whatsapp pour rétablir la liberté dans la messagerie instantanée ?

Libérez vous de l'effet réseau!

Avant toute chose, il est nécessaire de réaliser un état de fait désagréable: celui de notre impuissance face aux choix de #Facebook (propriétaire de Whatsapp) quant à l'évolution de son service. Et si cette dernière ne nous convient pas, nous devrons alors quitter tous nos contacts, présents sur cette plateforme.

Bien évidemment, cette décision, potentiellement lourde en conséquences affectives et/ou professionnelles, nous fait le plus souvent rester sur la plateforme en dépit du fait que nous ne cautionnons pas sa politique d'utilisation. Ce phénomène de captivité officieuse -et le plus souvent inconsciente- est dû à "l'effet réseau" qui nous rend captifs, par crainte de perdre notre cercle social.

Comme il serait dommage de quitter un réseau fermé pour déménager vers... un autre réseau fermé, aux allures faussement alternatives (expliqué dans la 1ère partie), voici une autre solution pour le plus grand nombre, qui est un compromis entre centralisation et accessibilité à tous.

Procédure pour smartphone Android

  1. chercher et installer le client #quicksy sur le Play Store ou F-Droid. Il vous faudra votre numéro de téléphone pour récupérer le code de confirmation par SMS. Cela vous permettra de valider votre nouvelle adresse personnelle.
  2. convaincre ses amis de faire la même chose (l'étape la plus difficile). S'ils ont votre numéro de téléphone dans leur carnet d'adresses, vous vous retrouverez automatiquement dès qu'ils l'installeront.

Bienvenue sur #xmpp! Vous venez de rejoindre un réseau ouvert et sécurisé pour votre messagerie instantanée! 🎉

Petit lexique

Les clients

Les clients xmpp sont des logiciels sur ordinateur, des applications sur smartphone ou des sites web particuliers qui se connectent à votre fournisseur xmpp. Vous devez avoir un compte pour pouvoir les utiliser et ils fonctionnent avec tous les fournisseurs. Ils peuvent fonctionner simultanément sur le même compte.

Les fournisseurs (ou serveur)

Les fournisseurs xmpp sont des acteurs qui vous donnent un compte avec une adresse (ou identifiant ou JID) sous la forme : monnom@monfournisseur . Nous pouvons souscrire à un nombre illimité de fournisseurs.

Vous pouvez créer une nouvelle adresse via une page web dédiée du fournisseur, ou directement dans un client Xmpp compatible : "Conversations", "Gajim", "Dino", "Siskin", je préciserai au cas par cas :

FournisseurCoûtInscriptionLimitations (association de promotion et défense du logiciel libre)gratuitinscription depuis un client xmpp250Mo par envoi max, 500Mo max sur le compte pendant 380 jours (orienté réseau social)gratuitinscription préalable uniquement sur le site web10Mo par envoi maximum (association des utilisateurs francophones de Jabber)gratuitinscription préalable uniquement sur le site webstockage de l'historique pendant 2 semaines
conversations.imgratuit 6 mois, 8€ par aninscription depuis un client xmppGarantie d'une disponibilité professionnelle.
quicksy.imgratuitautomatique lors de l'installation du client Quicksy ""

éventuellement d'autres, mais je vous conseille au préalable de bien vérifier leur compatibilité avec toutes les fonctionnalités avancées ici

Groupes de discussion (MUC, salon de discussion, canal, groupchat)

Il existe deux types de groupes de discussions : privés ou publics. Pour les groupes privés, il faut que la personne qui a crée le groupe (ou une autre personne autorisée) vous invite. Pour les salons publics, vous pouvez généralement utiliser un pseudonyme. Vous pouvez y accéder via l'adresse publique du salon, par exemple:

Chiffrement, cryptage, #OMEMO...

Même si votre client vous indique "non chiffré", toutes les communications sur le réseau xmpp entre les serveurs et les clients sont protégées, ainsi que les appels audio et vidéo. Ce que le chiffrage OMEMO garanti en plus, c'est que vos messages ne seront pas lisibles par votre fournisseur ou autre autorité. "Quicksy" et "Conversations" utilisent par défaut ce chiffrage "bout à bout" qui protège ainsi les données stockées chez votre fournisseur. Il est aussi possible de protéger un groupe de discussion privé, si les participants utilisent tous le chiffrage OMEMO.

Les "Stores"

playstore est le catalogue Google d'applications installés par défaut sur les appareils Android.

#fdroid est un "store" ou catalogue installable d’applications libres et open-source sans publicité pour la grande majorité. Ce logiciel, lui même un logiciel libre, facilite la découverte, l’installation et le suivi des mises à jour sur votre appareil Android. Pour l'installer :

  • ouvrez le navigateur de votre téléphone et allez à la page d’accueil de F-Droid
  • sélectionnez le bouton "Télécharger"
  • exécutez le fichier sur votre smartphone et suivez les instructions

Suite pour une utilisation avancée (plusieurs identités)

Cette étape n'est pas obligatoire et peut se faire ultérieurement. Si vous avez besoin de séparer vie privé et vie publique en utilisant des adresses différentes, continuez la procédure. Vous pouvez par exemple utiliser votre adresse Quicksy comme adresse privée et une adresse sur un autre fournisseur comme adresse professionnelle (ou inversement): votre adresse sera connue uniquement par les contacts qui auront votre numéro de téléphone.

Les points suivants vous permettront d'obtenir une nouvelle adresse et de pouvoir gérer les deux (ou plus) adresses simultanément. Quicksy ne peux gérer qu'une identité, c'est pour ça que je vous propose d'utiliser à la place #conversations, qui s'utilise de la même manière tout en permettant de centraliser tous vos comptes sur cette application.

1. Créer une sauvegarde de votre compte actuel

  • ouvrir Quicksy sur l'écran principal
  • menu "" -> Paramètres -> "Créer une sauvegarde" (tout en bas)
  • lancer la sauvegarde

2. Noter les informations de votre compte actuel

  • retourner sur l'écran principal
  • menu "" -> "Gérer les comptes"
  • noter scrupuleusement votre identifiant "" et le mot de passe (icône œil). C'est lui qui vous permettra de récupérer votre historique crypté. Sans celui-ci, vous ne pourrez plus lire vos anciens messages

3. Choisir votre prochain fournisseur

  • Si vous prenez une adresse chez ou, il faut s'inscrire sur leur site web avant de continuer la procédure.
  • Si vous choisissez ou, l'inscription se fera au point suivant

4. Installer "Conversation"

  • désinstaller Quicksy
  • lancer l'installation de l'application Conversations, celle-ci est gratuite sur F-Droid, et payante (2,5€) sur le PlayStore.
  • lancer Conversations
  • choisir "J'ai déjà un compte" si vous l'avez crée en amont (avec jabberfr par exemple) sinon choisir "Créer un nouveau compte"

Choix 1 : "Utiliser votre propre fournisseur". Voir le "Petit lexique" plus haut pour faire votre choix, à l'exception de (voir choix 2 ci-dessous). Saisissez votre adresse xmpp : monadresse@fournisseur, puis le mot de passe souhaité. Retranscrire les chiffres de l'image (captcha) pour valider

Choix 2 : "Utiliser" (8€/an, 6 mois d'essai gratuit) si vous voulez avoir une adresse "professionnelle". Suivre la procédure proposée.

5. Restaurer et activer votre ancien compte "Quicksy"

  • retourner sur l'écran principal.
  • menu "" -> "Gérer les comptes". Puis menu "" -> option "Restaurer la sauvegarde"
  • sélectionner la sauvegarde quicksy.
  • saisir le mot de passe du compte Quicksy que vous avez noté précédemment
  • sur l'écran principal
  • menu "" -> "Gérer les comptes". Activer le compte . Vous avez fini! 🎉

6. Si vous voulez ajouter un nouveau compte

  • sélectionner le bouton "+" dans la "Gestion des comptes" en appliquant le point 3. si nécessaire

Réinstallation / nouveau matériel

Vous pouvez trouver toutes les informations détaillées en anglais sur le dépôt de Conversations / Quicksy. Ici la procédure rapide :

  1. Sur votre ancien appareil ou installation, ouvrir Quicksy ou Conversations sur l'écran principal. Puis menu -> Paramètres -> Créer une sauvegarde (tout en bas) et lancer la sauvegarde
  2. Retourner sur l'écran principal. Puis menu -> Gérer les comptes. Noter scrupuleusement vos identifiants et mots de passe (icône œil). C'est eux qui vous permettront de récupérer vos historiques cryptés.
  3. Réinstaller Quicksy ou Conversations sur votre nouvel appareil
  4. Ne pas répondre à la proposition de connexion à un compte au premier démarrage: aller dans menu -> Restaurer la sauvegarde
  5. Sélectionner les sauvegardes. Saisir le mot de passe de chaque compte que vous avez noté.
  6. Activer le compte: Écran principal. Puis menu -> Gérer les comptes. Activer le compte

"Siskin" pour un utilisateur d'iPhone ou de tablette iOS

L'application Quicksy permettant la recherche automatique des contacts n'existe pas sous iOS. Vous devrez choisir un fournisseur (voir "Petit lexique"). Suivre cet article qui vous détaillera la marche à suivre.

Pour un utilisateur qui utilise un téléphone simple sans internet

Si votre téléphone ne permet pas d'accès à internet mais que vous souhaitez néanmoins être joignable via une messagerie instantanée, vous pouvez l'utiliser sur un ordinateur :

  1. Choisissez un fournisseur (voir le "Petit lexique" plus haut)
  2. Optionnel : Pour être retrouvé automatiquement par vos contacts qui utilisent quicksy et qui ont votre numéro de téléphone, inscrivez-vous dans l'annuaire Quicksy (5€ par paypal)
  3. Installer un client XMPP en fonction de votre ordinateur : Gajim sous Windows et Linux, Dino sous Linux, BeagleIM sous MacOS. Pour l'instant, ils n'offrent pas la possibilité de passer des appels audio/vidéo.
  4. Actuellement, pour passer un appel vidéo ou audio, connectez vous sur avec votre adresse XMPP depuis n'importe quel ordinateur.

Pourquoi ces choix ?

Un réseau ouvert évolutif tel que XMPP a l'inconvénient de ses avantages : une incontestable liberté mais aussi beaucoup de choix... qui ne sont pas toujours totalement compatibles entre eux, ce qui s'avère compliqué quand on débute. C'est pour cela que dans cet article, j'expose volontairement un nombre limité d'applications et de fournisseurs compatibles entre eux, afin de rendre la première expérience durable et facile. La centralisation sur Quicksy n'est bien sûr pas une fin en soi, il faut le voir comme un appel au changement, l'occasion de passer d'un réseau fermé à un réseau ouvert. Comme expliqué dans l'utilisation avancée, il est "facile" d'avoir plusieurs adresses et de changer de fournisseur.

Client "Quicksy"

  • simple à installer et à utiliser, à l'image de whatsapp,
  • découverte automatique des correspondants qui ont installé quicksy
  • appels audio et vidéo à l'international (votre correspondant doit être connecté à internet pour que son icône d'appel s'affiche)
  • envois rapides de fichiers sons, images et vidéos avec redimensionnement et ré-encodage automatiques en cas de fichier trop volumineux.

A noter: pour l'instant, il n'y a pas d'outils de découpage de vidéo intégré. Il est nécessaire de le faire en amont de l'envoi. Mais cela peut changer dans le futur: en effet, cette application étant géré par des bénévoles passionnés, les améliorations futures dépendent en partie de leur motivation, qui augmentera sans doute en fonction de l'intérêt porté à leur travail. Et cet intérêt se mesure par le nombre d'utilisateurs...Il est d'ailleurs possible de suivre, d’interagir et de proposer des évolutions aux concepteurs: pour cela, rdv ici (en anglais)

  • possibilité de créer simplement des groupes de discussion privés et publics
  • citation d'ancien message, émoticons, accusés, statut en cours d’écriture, etc..
  • sécurisé avec le chiffrage bout à bout OMEMO : votre fournisseur ne pourra pas accéder à vos données
  • code source libre
  • disponible gratuitement sur le Play Store et F-Droid

Client "Conversations"

  • L'application "Quicksy" est un dérivé officiel du même auteur de l'application "Conversations" avec la découverte automatique des contacts. Ces deux applications ont été créees par le même développeur, Daniel Gultsch et ont les mêmes fonctionnalités de base. Seulement, dans une volonté de cohérence et de simplicité d'utilisation, Quicksy ne permet pas de gérer plusieurs identités.
  • code source libre (GPLv3 niveau client et serveur)
  • à l'installation, vous obtenez un nouvel identifiant valable sur tout le réseau #xmpp ainsi que votre inscription sur l'annuaire Quicksy après validation de votre numéro de téléphone

au sujet de son auteur Daniel Gultsch et de son modèle économique

  • Il a une politique respectueuse de la vie privée quand à l'utilisation du service de découverte des numéros de téléphone. Quicksy n’envoie pas votre carnet d'adresses sur les serveurs Quicksy : l'application sur votre téléphone interroge l'annuaire Quicksy avec les numéros de votre carnet d'adresses pour trouver un correspondant qui utilise déjà l'application.

  • Son financement se fait grâce aux personnes possédant déjà une adresse xmpp et souhaitant être retrouvé automatiquement par leurs contacts utilisant quicksy. Daniel Gultsch perçoit également des financements grâce à la vente de l'application libre conversations sur le PlayStore et en tant que fournisseur d'adresses

  • Il participe activement à l'évolution de l'écosystème xmpp et à la défense du concept de fédération (réseau ouvert à tous).

Client web "Movim" solution multi plateformes

Pour voir et interagir avec toutes vos conversations sur votre ordinateur, je vous conseille d'utiliser Movim. C'est un client web (comme un webmail externe) qui possède toutes les possibilités de "Conversations" (appel audio / vidéo entre autre) avec des fonctionnalité de blogage supplémentaire.

Vous pouvez vous connecter avec n'importe quelle adresse XMPP.

auteur : Yann, relecture : Ludivine, publié sur le réseau XMPP à partir du client web #movim.

  • Vous pouvez commenter cet article via le réseau XMPP en vous connectant au préalable sur movim (avec votre compte xmpp ou en créant un nouveau) et en vous rendant à cette adresse.

  • Be chevron_right

    Berlin Online XMPP Sprint 2020

    debacle · / berlin-xmpp-meetup · Sunday, 22 March, 2020 - 00:47 edit

Berlin Online XMPP Sprint 2020

The planned XMPP sprint in Berlin from Thursday, 2020-03-26 to Sunday, 2020-03-29, will take place despite the current crisis. But instead of an in-person meeting, it will be an online event!

We will mainly use the XMPP group chat for all coordination, and multiple Jitsi instances for audio/video conferencing, maybe also mumble for voice chat.

Please find all details in the wiki and consider participation! This time, there are neither travel nor hotel costs!

See you at the Berlin Online XMPP Sprint! Berlin is whereever you are!

#xmpp #sprint #event #community #hacking #freesoftware #uwpx #beagleim #siskinim #xmppjs #omemo #kaidan #smack #dino #omemo #prosody #xmpprs #salutatoi #debian #jitsi