Bonjour nal
J'écris ce journal pour décrire mes manipulations pour utiliser XMPP. Cela pourra peut-être aider des personnes qui ont la même config que moi, et j'aimerai récupérer des remarques ou des conseils.
XMPP
XMPP, plein de journaux en parlent, il y a quelques polémiques (compliqué à cause des XEP) mais je suis plutôt convaincu.
Aujourd’hui, j'ai décidé de sauter le pas, et de l’utiliser pour remplacer les SMS (avec les contacts "compatibles" bien entendu !).
Je ne m'attendais pas à devoir écrire un tutoriel pour savoir utiliser ça…
L’environnement
Je souhaite dans un premier temps faire communiquer 2 personnes, avec des périphériques android, Ubuntu (LTS 16.04 et 17.10) et Windows. Plutôt banal donc.
J’ai une brique internet avec Yunohost installé si besoin.
Hébergeur
Il faut d’abord choisir un hébergeur.
Auto hébergement
J’ai une brique internet, avec donc un petit processeur ARM, pourquoi pas installer un serveur XMPP dessus ?
Ce journal m’indique 2 logiciels coté serveur : Prosody et Ejabberd. Le premier étant indiqué plus léger que le second.
Malheureusement, un commentaire dit que l’installation n’est pas si simple d’autant plus que l’appli n’est pas packagée pour yunohost.
Hébergeur sur l’Internet
Je trouve dans ce journal une liste de serveur conseillés (et une autre liste ici) et je tombe donc sur jabberfr.org. Ce site fait partie des CHATONS de framasoft, c’est rassurant.
J’ai un doute quand je vois ici que
JabberFR n’est pas un serveur Jabber mais une fédération.
Finalement, je mets quelques minutes à comprendre que c’est bien un serveur jabber pour les adresses @jabber.fr et que le formulaire d’inscription est ici : im.apinc.org/inscription (pas évident tout ça !).
Client Android
J’installe Conversation, indiqué par ce journal.
Comme d’habitude, l’installation se passe bien sous Android (depuis F-Droid pour ma part).
Conversation me permet de créer un compte depuis jabber.fr. Le message qui indique que le pseudo existe déjà est sans rapport avec le problème, mais ça fonctionne.
Je tombe alors sur 3 méthodes pour chiffrer les messages : OMEMO, OTR, et OpenPGP. Ce site et ce journal me convainquent d’utiliser OMEMO (dommage qu’il n’y ai pas de "Server side archive").
Je galère un peu à comprendre comment l’utiliser sur Conversation. Je scan des qr code OMEMO d’un tel avec l’autre, j’importe la clé dans Conversation, mais ca ne fonctionne pas (message "pas de clé pour le contact").
Je passe donc avec OTR et la encore des scan de qr code à faire, mais ca fonctionne.
Client PC
Je choisi Gajim (au design très vieillot) car il est souvent cité en référence (ici et la par exemple).
Alors pour installer un logiciel sous ubuntu, j’ai toujours 2 références : le wiki ubuntu et le site de l’éditeur. D’abord sur le PC Ubunut 17.04 apt install gajim, c’est facile comme d’hab !
Lancement, le compte est bien trouvé,… tentons avec OMEMO, …, il faut un plugin, mais pas de souci, il y a un gestionnaire de plugin dans Gajim.
Par contre je ne peux pas l’activer, et l’interface me dit d’installer les paquets suivants (1 par 1, et il faut redémarrer gajim entre chaque installe sinon c’est pas drôle) : python-setuptools python-axolotl python-qrcode python-cryptography.
Bon, je fouille un peu les options, et ça fini par marcher en OMEMO. Et Conversation se met aussi à fonctionner avec OMEMO tout seul, bonne nouvelle !
Pour l’install sur le PC en Ubuntu 16.04, je laisse temporairement tomber :
Je vois que la version de Gajim des dépôts (0.16.5) n’est pas compatible avec le plugin OMEMO … Your Gajim version is too old, OMEMO needs 0.16.6 or higher.
Bon, je chercherai un PPA plus tard…
Futur
Il me reste à tester Movim pour android et Dino pour Ubuntu.
Aucune idée de la compatibilité des différentes fonctionnalités avec mes clients existants (soit j’essaie de comprendre ce qui signifient chaque XEP, soit je tente et je vois ou ca bloque…).
Avant d'avoir trop de contactes, j'aimerai bien utiliser une adresse xmpp avec mon nom de domaine au lieu de @jabber.fr
Voir ce qui fonctionne avec le client XMPP intégré de thunderbird
Enfin, je jetterai un œil à Matrix. Même s’il n’y a pas la compatibilité de XMPP, ils ont l’avantage (à mes yeux) d’avoir un partenariat avec Purism pour le smartphone Librem 5.
Une aprem pour ça, et ce n'est fini.
Ce n'est pas encore une solution clé en main, XMPP !
Alors, des conseils pour la suite ?
# Rester loin d'XMPP
Posté par dani . Évalué à 5.
Merci pour le journal. Ça me conforte dans mon idée de rester loin d'xmpp. Perso j'ai choisi Matrix, mais je pense que peu importe, n'importe quelle solution fonctionnera mieux. Ce journal est un très bon exemple de pourquoi XMPP ne prends pas.
[^] # Re: Rester loin d'XMPP
Posté par Renaud Casenave-Péré . Évalué à 0.
Je ne peux malheureusement qu'acquiescer…
Après avoir essayé plusieurs combinaisons de clients et de serveurs, il manquait à chaque fois un truc qui ne marchait pas bien. Pour ma part je me suis rabattu vers mattermost pour une communauté d'une dizaine de personnes.
En théorie XMPP propose beaucoup de choses intéressantes mais en pratique c'est toujours un peu trop compliqué et j'en suis le premier navré…
[^] # Re: Rester loin d'XMPP
Posté par Maclag . Évalué à 10.
XMPP a désespérément besoin d'un couple client-serveur de référence.
Et une autorité pour certifier ou interdire les prétentions des serveurs et clients annoncées ici et là ne ferait pas de mal.
Je m'attends à ce que Matrix souffre du même genre de problème à terme… ou reste à jamais une solution avec un serveur unique et un client unique, tous développés par une seule boite, avec pour avantage un dynamisme et une cohérence, et tant pis pour la diversité!
Effet pervers déjà là: les petits serveurs ne peuvent pas accéder aux gros salons! Gare à eux s'ils essaient: ils finissent à genoux sous la charge. Et la solution proposée c'est… une blacklist de gros salons pour empêcher les utilisateurs de s'y connecter!
[^] # Re: Rester loin d'XMPP
Posté par quent57 . Évalué à 0. Dernière modification le 16 décembre 2017 à 22:42.
Disons que ceci est un troll, pour qu'on ne dise pas que je suis de mauvaise foi !
Pour l'utilisation "messagerie instantanée" de XMPP, si on considère
1. qu'utiliser des message chiffrés
2. et de recevoir les messages sur tous ses périphériques
sont des pré-requis : il faut utiliser OMEMO (PGP est déprécié, et OTR ne permet pas 2., cf mes autres commentaires).
Si on en crois ce site : https://omemo.top/
On a des clients de références (les seuls qui implémentent OMEMO !).
- Sur PC (GNU/Linux et Windows) : Gajim
- Sur Android : Conversations
- Sur IOS : ChatSecure
J'ai exclue Pidgin pour PC, car il est déconseillé par l'APINC.
Edit : en fait, je viens de voir que l'APINC n'existe plus : http://apinc.org/ , donc je sais pas si le commentaire sur Pidgin est pertinent.
[^] # Re: Rester loin d'XMPP
Posté par quent57 . Évalué à 1.
Plus de temps pour l'édition !
Il apparaît aussi ces 2 clients sur https://omemo.top/, mais ce sont des forks :
- Pix-Art Messenger est un fork de Conversations
- Zom est un fork de ChatSecure
[^] # Re: Rester loin d'XMPP
Posté par Maclag . Évalué à 10.
Quand je dis couple client-serveur de référence, je veux justement éviter d'avoir une liste de références variables suivant la fonctionnalité qu'on cherche.
Je vais prendre l'exemple de Matrix, parce que c'est sûr que c'est tentant d'aller là où tout semble moins confus.
Il y a un client de référence, c'est Riot, qui fait… TOUT!
Si on n'aime pas Riot, il y a semble-t-il d'autres projets de clients plus ou moins avancés. Mais quand on parle d'une nouvelle fonction ou qu'on demande si on peut faire ci ou ça, la réponse, c'est Riot.
Là tu me cites une source qui compile les clients qui gèrent OMEMO.
Si je te demandes d'ajouter la voix et vidéo, tu vas devoir me sortir une autre liste.
Et c'est là tout le problème!
Les utilisateurs qui découvrent, et je dirais même la plupart des utilisateurs de tous les jours ne veulent pas explorer les combinaisons clients-serveurs qui répondent à une description exacte de leur besoin.
Ils veulent qu'on leur pointe UN client, pour ceux qui veulent s'auto-héberger, UN serveur, et ça doit leur donner une idée de ce qu'on peut avoir avec XMPP.
Aujourd'hui, le paysage est beaucoup trop compliqué pour être appréhendé par un néophyte et espérer qu'il en sorte quelque chose de positif!
Maintenant, le champ d'application de XMPP est plus vaste que la seule communication instantanée, alors on peut supposer avoir plus d'un client de référence. Mais il en faut un par usage:
-Communication instantanée:
Doit comprendre: discussion 1-1, salons, chiffrage bout-à-bout, voix et vidéo, transfert de fichier
-Réseau social:
Doit comprendre: blogage, tant pour l'édition que pour la consultation des autres contenus, système de notification ("suivre") de fils, recherche de contenus
(ce sont des suggestions, la liste des fonctionnalités pourrait être sujette à débat)
Et pour le serveur, c'est simple: si j'installe et par défaut je peux faire marcher les 2 clients réfs ci-dessus sans trifouiller partout, ça marche.
De là, tout me semble plus simple: inutile de vanter les 3 méthodes de transfert de fichier ou les 2 méthodes pour avoir la voix/vidéo: ça DOIT marcher avec le client de référence, ça DOIT utiliser au moins la méthode implémentée dans le client de référence, sinon le client ne peut pas s'afficher comme ayant la fonctionnalité implémentée.
Si plusieurs clients prétendent à être LA référence, c'est gagné: ça veut dire qu'on a une concurrence saine entre plusieurs projets aboutis. Je ne vois aucun problème à ce qu'ils soient tous les 2 mis en avant, mais il devrait toujours n'y en avoir qu'un seul en haut de la liste "si tu débutes, prends ça, tu te poseras des questions plus tard!".
Quand je parle d'autorité de certification, j'imaginais un label "Jabber Comm instantanée" et un label "Jabber Réseau Social", par exemple (je ne doute pas qu'on pourrait trouver de meilleurs noms, c'est pour le principe).
Et je ne vois pas d'autre moyen de sortir XMPP de l'état dans lequel il est: "prometteur" depuis plus de 10ans tout en donnant une image de foutoir et de "pas prêt" à tous ceux qui n'y investissent pas un certain temps.
J'ajouterais qu'avoir beaucoup de projets avec chacun un seul contributeur n'aide pas non plus, quand on voit que Matrix a plusieurs personnes sur chaque projet. Mais ça, on ne peut le reprocher à personne. Ce sont déjà presque tous des dévs qui bossent sur leur temps libre.
[^] # Re: Rester loin d'XMPP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Petite correction, PGP n'est pas déprécié, c'est la XEP historique (c.-à-d. qui a été implémentée au début et qui n'a pas fait l'objet d'un processus normal de standardisation, mais qui décrit un état de fait) qui l'est. La version moderne, propre et sécurisée s'appelle OX, c'est la XEP-0373.
Pour le reste je lis les commentaires, beaucoup de critiques sont justifiées, pas toutes.
Il faut toutefois garder à l'esprit, comme cela a été dit par ailleurs, que la plupart des projets sont développés sur le temps libre, et que chaque fonctionnalité prend un temps fou.
Par exemple dans notre cas (SàT), c'est actuellement un seul développeur actif (moi, avec 1 jour/semaine dédié au projet, et 4 à un boulot salarié qui n'a rien à voir).
Pour donner des exemples : au moment d'implémenter le chiffrement de bout en bout l'état de l'art était OTR, ce qui a désormais changé (il est question bien sûr d'implémenter OMEMO et OX, mais je ne peux pas tout faire en même temps). Une implémentation dans notre cas et dans le cas particulier du chiffrement de bout en bout signifie en fait 2 implémentations : une dans le backend pour les plupart des frontaux, et une en javascript pour le frontal web. De même la vidéo est prévue depuis longtemps, et la base est déjà faite (jingle), mais il y a eu d'autre priorités qui devaient passer avant, surtout qu'il existe déjà des solutions satisfaisantes compatibles (Jitsi).
Movim c'est principalement un seul dév également, Gajim c'est du même ordre, Conversations c'est un seul dév mais à temps plein (il en vit), etc. Matrix de son côté à eu un budget conséquent avec une dizaine de salariés à temps plein (sauf erreur), forcément ça aide à avoir une solution plus léchée.
Un des objectifs de SàT (l'asso) est de développer une activité économique pour que déjà je puisse me salarier, puis si possible embaucher du monde, mais nous voulons faire ça selon nos principes éthiques/politiques et évoluer vers une coopérative à terme (SCOP ou similaire) en autogestion. Si nous y arrivons, ça changera complètement la donne (et ma vie, puisque c'est un investissement sur mon temps qu'il est je pense difficile d'imaginer).
[^] # Re: Rester loin d'XMPP
Posté par Faya . Évalué à 4.
C'est exactement le choix de l'équipe de Signal.
Arguments : https://signal.org/blog/the-ecosystem-is-moving/ et https://lwn.net/Articles/687294/
Contre-arguments : https://gultsch.de/objection.html et https://medium.com/@dwdbah/federation-privacy-and-user-experience-c158547f07f5
[^] # Re: Rester loin d'XMPP
Posté par Maclag . Évalué à 6.
Quand je parlais de serveur unique, je parlais du logiciel serveur.
Mais le réseau de Matrix est une fédération aussi.
Je n'ai pas suivi les liens, mais problème numéro 1 sur Signal: tu n'as d'autre choix que leur faire une confiance aveugle avec tes métadonnées!
# Pas convaincu
Posté par Yuul B. Alwright . Évalué à -1.
En lisant ton journal, j'ai l'impression que tu as cherché toutes les erreurs qu'il soit possible de faire pour ensuite construire ton histoire pour se heurter à chacune n'entres-elles. On dirait un mauvais jeux d'acteur "Ho la la, la solution qui n'est pas celle de mon choix mais que je fais semblant d'utiliser sans préjugé n'est pas bien. HO, regardez, il existe Martix. Qu'elle heureux hasard, j'avais pas du tout prévu ça…"
[^] # Re: Pas convaincu
Posté par quent57 . Évalué à 5.
Je promet être sincère et ne pas avoir écrit plus d'erreurs que j'en ai rencontré.
J'avoue que j'étais novice en la matière, il y a pas mal de concepts à apprendre. Je n'ai peut être pas eu de chance, et sûrement qu'utiliser une solution comme Movim de bout en bout aurait été plus simple.
Je suis désolé si j'ai adopté un ton un peu trop plaintif, c'est sûrement dû à des sujets extérieurs.
Si j'essaie de lister les erreurs que j'ai rencontré ça donne :
- jabber.fr : c'est pas évident au premier abord de comprendre le lien entre ces 3 noms de domaine.
- problème du pseudo sur Conversation : j'ai tenté mon prénom (naïvement) et j'ai eu une bulle avec "échec de l'enregistrement". Je n'ai vraiment pas compris dès le début la raison du message.
- pour le OMEMO sur Conversation, j'ai sûrement pas compris quelque chose dans le fonctionnement de l'appli. En dehors de ces 2 points l'appli est super !
- pour l'incompatibilité avec Ubuntu LTS, c'est moi qui "gère" les installes des Ubuntu des PCs de mes proches, et je les laisses sur des LTS. Mon pc, je le met sur le dernier Ubuntu.
- enfin, le système de plugin sur Gajim n'est quand même pas orienté utilisateur. Si un jours je souhaite discuter avec, disons ma mère, via XMPP, c'est sans aucun doute moi qui ferais l'installation.
Pour Matrix, je n'ai jamais utilisé. Je n'ai aucune idée si ça fonctionne bien.
Et, la question de fin est sincère, des conseils pour la suite ?
J'ai loupé un super tuto quelque part sur la toile, ou un journal linuxfr qui m'aurait évité mes recherches ?
Est-ce que je laisse tomber Gajim dès maintenant et Dino s'installe plus facilement ?
J'aurais dû utiliser Movim pour me poser moins de questions ?
En tout cas maintenant que c'est en place, je n'ai aucun doute que ça va rouler tout seul :)
[^] # Re: Pas convaincu
Posté par eingousef . Évalué à 3.
Question :
Une fois que tu as réussi à faire marcher OTR sur ton client Android, pourquoi n'avoir pas utilisé ça sur Gajim aussi ?
Et en ce qui concerne :
Les mots de passe de prosody stockés en clair ? Où ça ? Et quel est le "plein de modules" nécessaires dont il parle ?
*splash!*
[^] # Re: Pas convaincu
Posté par Maclag . Évalué à 4.
Je ne vais pas répondre pour lui, mais un ne peut pas écrire partout que OTR a pleins de problèmes et que OMEMO c'est LA solution et ensuite s'attendre à ce que les utilisateurs restent sagement sur OTR jusqu'à ce que OMEMO soit rendu simple à utiliser partout.
Je pense qu'il compilait et installait des versions de dév pour avoir les fonctions pas encore dans la version prod. Je suppose que c'est un peu plus brut de décoffrage…
[^] # Re: Pas convaincu
Posté par quent57 . Évalué à 1.
Je voulais éviter l'OTR car, à ce moment là de mon test, Conversation demandait à mon correspondant de choisir sur quelle machine envoyer le message, et ce message n'arrivait donc pas sur mon smartphone ET sur mon pc, mais sur un seul (chose qui n'est pas pratique pour mon utilisation).
Je pense que ça correspond à la ligne
Multiple DevicesiciD'autre part, la page du wiki de gajim pour le plugin OTR indique indique en gros
Quant à PGP, il fallait installer une appli supplémentaire à Conversation pour le gérer sur Android, et cette dépêche pointe sur XEP-0027: Current Jabber OpenPGP Usage qui indique en bas
--
Pour le commentaire que j'ai cité je n'ai rien vérifié, si jamais Cyril Brulebois passe par la pour nous répondre ?
Pour les mots de passe en clair, ça me dérange pas (la partition du serveur est chiffrée, pas d'accès par d'autres que moi même), c'est la partie compilation qui m'a fait peur.
Si quelqu'un me dit propsody est simple à installer (et qu'il y a suffisamment de XEP implémentées dans la version stable), je tenterai !
[^] # Re: Pas convaincu
Posté par eingousef . Évalué à 3.
Bah moi je l'utilise que pour faire du chat donc la base de prosody me suffit. Y'a juste un fichier de conf lua à éditer + les certifs TLS à rajouter et le(s) compte(s) utilisateur à créer (ça n'utilise pas les comptes UNIX).
*splash!*
[^] # Re: Pas convaincu
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
jette un œil au modules
mod_auth_*sur https://modules.prosody.im/ qui permettent d'avoir des méthodes alternatives pour utiliser des comptes existants (il y a notamment un module PAM, à tester).[^] # Re: Pas convaincu
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Les mots de passe sont en clair par défaut sur Prosody, mais on peut les hasher, c'est expliqué sur leur site : http://prosody.im/doc/plain_or_hashed
Pour OpenPGP j'ai expliqué plus haut (la 0027 est à éviter, mais il y a une version moderne et propre, appelée OX).
Les différents chiffrements ont différentes propriétés, j'ai commencé à écrire un article pour expliquer ça, mais je n'ai pas eu le temps de le finir. En gros OTR ne permet de communiquer qu'avec un seul appareil, OMEMO le permet et gère la confidentialité persistance et OX gère plusieurs appareils sans la confidentialité persistante (mais du coup permet d'avoir les archives sur le serveur). Après c'est le rôle du client de rentre ces notions le plus simple et pratique possible pour l'utilisateur, sans sacrifier la sécurité.
Prosody il vaut mieux utiliser la version à jour. Si tu es sur Debian ou dérivée, tu as un dépôt officiel avec les versions à jour, c'est expliqué sur la doc officielle. C'est très facile à installer.
[^] # Re: Pas convaincu
Posté par eingousef . Évalué à 2.
Ben tu vois c'est juste une ligne à changer dans le fichier de conf. Tellement simple que je me souvenais plus de l'avoir fait.
*splash!*
# Movim, Dino et Thunderbird
Posté par quent57 . Évalué à 0. Dernière modification le 16 décembre 2017 à 22:16.
Si jamais il y a effectivement des gens qui veulent utiliser XMPP qui tombent sur mon journal, pour info :
J'ai testé sous thunderbird (car déjà installé sur mon PC)
Ça marche bien, mais pas de support de OMEMO cf bubzilla
Pour Dino, c'est en cours d'implémentation, et pour Movim c'a a l'air d'être au point mort.
Ce site a l'air d'être à jour pour indiquer l'état d'avancement d'OMEMO.
# Prosody pas packagé pour YunoHost
Posté par Crudelis Maniack (site web personnel) . Évalué à 4.
Bonjour
En passant, car j'ai lu ça dans ton article.
Prosody n'est pas packagé en tant qu'application car son fork Metronome est pré-installé et pré-configuré avec YunoHost.
Tout utilisateur YunoHost dispose d'une adresse XMPP avec son adresse mail principale.
Il n'y a rien de plus à configurer pour utiliser XMPP avec YunoHost, juste te connecter avec ton login et password habituel sur n'importe quel client XMPP.
J'utilise personnellement Pidgin avec le plugin OTR, et ça marche sans plus de configuration.
[^] # Re: Prosody pas packagé pour YunoHost
Posté par Maclag . Évalué à 7.
Hmm… ça mérite quelques précisions:
-Métronome n'est plus maintenu depuis des lustres. Tu peux t'en servir, mais il est vraiment temps de passer à autre chose!
-Quelqu'un travaille déjà à la migration vers Prosody sur Yunohost. C'est bien avancé!
[^] # Re: Prosody pas packagé pour YunoHost
Posté par RyDroid . Évalué à 1.
Source(s) ?
[^] # Re: Prosody pas packagé pour YunoHost
Posté par Maclag . Évalué à 5.
C'est pas vraiment le secret des dieux…
https://dev.yunohost.org/issues/67
https://github.com/YunoHost/yunohost/pull/240
https://github.com/YunoHost/doc/pull/473
Sinon movim.eu a déjà migré vers ejabberd.
[^] # Re: Prosody pas packagé pour YunoHost
Posté par quent57 . Évalué à 2.
Merci pour l'info, j'ai tenté et ça marche au poil !
Apparemment, quelques XEP ne sont pas supportés (je ne connais pas les impactes), mais pour du texte en OMEMO, ça fonctionne. Conversations me dit :
# Nom de domaine perso avec Jabber Fr
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Il me semblait bien que JabberFr autorisait les nom de domaines perso, mais j'ai demandé confirmation pour être sûr, voilà ce qu'on m'a répondu :
# Quelques pistes supplémentaires
Posté par seveso . Évalué à 4.
Pour moi tu as fait les bons choix technologiques :
Sur PC/windows on m'a dit que gajim était galère à installer. Tu peux essayer swift qui est assez limité mais simple à utiliser, ou jitsi qui permet notamment de faire du chat audio/vidéo avec d'autres utilisateurs de jitsi.
Maintenant si tu ne te sens pas d'héberger ton entourage sur ton propre serveur (cela a déjà été dit mais je le répètes : tu as déjà un serveur XMPP opérationnel sur ta brique Internet) mais que tu veux quand même les encourager à passer à XMMP il faut trouver des services tiers gratuits (sinon tu vas les perdre) et de qualité. J'entends par là des services qui suivent les dernières évolutions de XMPP et incluent au moins les fonctionnalités comme carbons, http_upload et MAM.
Je suis tombé sur une liste intéressante provenant du projet ZOM : servers.json. Je ne les ai pas testés moi-même mais j'imagine que s'ils sont listés par le projet ZOM ils doivent être dignes d'intérêt pour un public large.
En ce qui concerne le chiffrement bout-en-bout j'ai tendance à penser que ce n'est pas forcément une nécessité de premier ordre. Surtout si au début tu te construis une liste de contacts qui sont soit hébergés sur ton serveur perso, soit sur leurs propres serveurs persos. Dans ce cas les entités ayant l'opportunité de consulter en clair tes échanges sont les mêmes personnes avec qui tu échanges. Donc c'est pas vraiment indispensable.
Le chiffrement de bout en bout deviendra vraiment pertinent lorsque tu auras des contacts ayant un compte XMPP sur un serveur tiers. Dans ce cas là, c'est effectivement OMEMO qu'il faut privilégier. Mais il faut laisser OMEMO mûrir encore un peu, c'est une fonctionnalité encore jeune sur l'échelle de temps de XMPP ;).
[^] # Re: Quelques pistes supplémentaires
Posté par quent57 . Évalué à 1.
Merci pour les conseils :)
Je note pour Swift, et je tente avec le serveur XMPP de yunohost.
Dans ce cas je pense effectivement que le chiffrement du stockage à moins d’intérêt.
Si j'ai bien compris, les communications sont de toutes façon chiffrées en SSL, et le disque de mon serveur est chiffré, ce n'est pas forcément utile d'ajouter une couche de chiffrement au stockage.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.