Goffi a écrit 1556 commentaires

Au passage, si vous séparez protocole et le documentez (encore mieux si vous faites une bibliothèque), ça me plairait fortement qu'on fasse une passerelles Diaspora/XMPP (bon là tout de suite je n'ai pas le temps, mais dans quelques mois).

edit: ah ah j'avais pas lu ton message en entier, tu disais la même chose quelques lignes plus loin :)

Sans regarder, je subodore que ça se limite à la messagerie instantanée de base, probablement via un jappix mini ou équivalent (qui est très bien pour ce que ça fait), ça n'est pas comparable à ce qu'on fait et je pense que l'intégration serait relativement compliquée.

Ce qui serait intéressant en revanche, sans parler de fusions de projets, c'est d'avoir une certaines d'intégration de l'un dans l'autre (pouvoir afficher la liste des fichier owncloud via un pubsub XMPP par exemple); mais bon on n'en est pas là pour le moment.

Si tu veux un truc en PHP, essaye Movim, il est très sympa et bien avancé.

Par contre « mais si j'avais décidé de créer quelque chose avec un bon framework, le résultat aurait nettement supérieur », je crois que tu ne te rends pas compte de la difficulté de la tâche, on parle de faire un truc décentralisé hein, pas le FB des débuts.

Au passage ok, SàT est un client XMPP, mais tu modifie XMPP (via des XEP) pour pouvoir faire SàT. Tu n'implémente pas tout XMPP (pas d'internet des objets si j'ai bien compris) et au contraire tu cherche à augmenter XMPP pour ton besoin. C'est bien que ce n'est pas simplement un client XMPP, c'est un client XMPP développé dans une direction donné et c'est cette direction qui n'est pas mise en valeur

Oui, pour l'instant nous cherchons principalement à avoir un chat complet (ça c'est plus ou moins le cas, il nous manque quelques gadgets comme la modification du dernier message, et des trucs plus utiles comme l'historique côté serveur), et un (micro)blogage complet.

Les choses que nous faisons à côté c'est soit parce qu'on en a besoin (les commandes ad-hoc, qui servent à faire la télécommande, sont nécessaire pour configurer par exemple prosody). Après parfois on s'amuse un peu, c'est utile pour rester motivé, et ça permet de pousser un peu (la télécommande n'est qu'un usage à peine détourné des commandes ad-hoc, ça m'a pris un soir et m'a sorti un peu du code chiant).

Tu répondais surtout à quelqu'un qui parlait de remplacer XMPP, qui semblait penser que XMPP est mort ou est du passé.

Oui je pense que c'est une erreur en effet, et je critiquais aussi la cause à mon avis de ce raisonnement.

Ce sera vraiment bien. Pour le moment, ne le prend pas mal, mais moi, j'ai l'impression que SàT essaie de tout faire et ne fait rien de bien (par bien j'entends "qui soit utilisable pour l'utilisateur moyen").

Non je ne le prends pas mal au contraire. Je suis quelqu'un de très susceptible si on ne met pas les formes quand on me parle: quelqu'un qui me prend de haut je l'enverrai chier au quart de tour. Mais je suis preneur de critique justifiée, et effectivement pour l'instant on ne fait pas les choses parfaitement (pour le chat on commence à être pas mal quand même). A priori on devrait être bien pour le (micro)blogage à la prochaine version, ça se stabilise (on bosse aujourd'hui sur les XEPs pour ça justement.

AMHA, mais ça n'est que mon avis, avant de courir vers la perfection XMPP et de pousser des XEP qui remplace ARP, il faudrait sortir quelque chose qui fonctionne, même s'il ne fait pas grand chose de plus que gajim ou pidgin.

Les 2 XEPs sur lesquelles je travaille, qui sont les premières vu qu'avant je n'avais pas le temps avant que souliane me rejoigne, sont pour utiliser notre service pubsub avec n'importe quel serveur. Ça permet d'accélérer le développement, de ne plus être compatible qu'avec prosody avec une bidouille sale, et d'avoir la compatibilité avec Movim et Jappix. Ce n'est pas de la nouvelle fonctionnalité, ça sert plutôt à stabiliser ce qu'on a et le faire de manière plus propre.

Ça permet d'avoir une base d'utilisateurs qui font des remontés,

Oui nous avons attendu avant de vouloir avoir des utilisateurs. Avec l'utilisation de SàT pour nos propre blogs, on devrait avoir un microblogage suffisamment au point pour une utilisation régulière pas une communauté, au moins de premiers testeur (nous avons déjà quelques personnes qui utilisent régulièrement et nous font des remontées, même si nous décourageons ça car nous n'avons pas encore de politique de sauvegarde sur le serveur de démo).

Les 2 XEPs qui devraient établir la compatiblé avec Movim/Jappix devraient aussi permettre d'avoir une communauté active.

AMHA c'est pas du temps de perdu que de stabiliser une base fonctionnelle, c'est un investissement pour la suite (ou une dette que tu t'évite au choix).

Même si on peut donner une impression différente, on ne va pas vraiment dans tous les sens, on a cheminement relativement logique, par moment on ajoute des trucs parce qu'on en a besoin (par exemple les marque-page à cette version), et des fois on a implémenté un truc qui nous donne envie d'essayer de bidouiller, parce que c'est motivant aussi de sortir un peu des sentiers battus (ex. la télécommande). La plupart du développement va toute de même dans la stabilité et le chat/microblogage.

Que ce soit en simplifiant la description ou en proposant des bundles, il est clair que la description actuelle de SàT peut laisser perplexe le commun des mortels.

Oui, mais on s'améliore sur ce point. Tu peux déjà voir les différences entre ma conf aux RMLL d'il y a 2 ans, et celle de cette année, ou je ne parle presque pas de XMPP. Il faut qu'on fasse la même chose pour le site, mais on aura certainement besoin d'un bon week-end pour ça, et pour le moment c'est difficile à trouver.

Il faudrait presque pouvoir créer des "bundles" (ou simplement des paquets optionnels sur une distrib, par exemple sat-chat) pré-configurés pour des cas d'utilisation et donner un nom à ce bundle.

Ben en fait le backend implémente le plus de choses possibles, mais l'idée c'est de pouvoir faire des frontaux adaptés à des cas particuliers par la suite. On pourrait par exemple en faire un qui ne fait que du microblogging à la identi.ca.

Par exemple, SàT serait adapté pour une utilisation comme réseau social d'entreprise (RSE). Seulement aucune boite n'ira regarder les fonctionnalités de SàT pour voir si ça peut convenir à son RSE.

On a déjà été contacté pour ça, mais c'est trop tôt pour le moment. La prochaine version (0.6) devrait commencer à être intéressante sur ce point, on pourra en parler plus sérieusement à ce moment.

Je prends cet exemple en particulier parce que la boite dans laquelle je travaille dépense une fortune chaque année pour un produit qui fait nativement moins de choses que SàT pour son RSE.

Ça m'intéresserait de savoir ce dont vous avez besoin en particulier, histoire de voir si nos priorités sont bien placées…

C'est un vrai problème. A chaque fois que je vois un projet qui n'arrive pas à se définir lui même je pense à Google Wave et à son destin funeste. Il est difficile pour les gens de comprendre ce que tu fais si tu à toi même du mal à synthétiser simplement ce dont il s'agit.

Je ne suis pas forcément fan du besoin de toujours devoir synthétiser, rationaliser. On a plusieurs points liés à ce projet, et ça n'est pas fait pour un cas d'utilisation précis. Maintenant les différents frontaux peuvent se concentrer sur un cas précis sans soucis, mais le projet dans son ensemble est large. Si tu veux résumer, tu peux dire un « client XMPP ».

Quand tu parle d'« envoyer un flux de données arbitraire à un contact », les gens qui comprennent de quoi il s'agit sont peu nombreux, ceux qui en ont besoin sont très rare donc c'est pas forcément la peine de le mettre en avant.

Je le mets en avant quand j'ai un public que ça peut intéresser (des gens techniques sur un salon par exemple), ceci est possible avec l'interface en ligne de commande qui s'adresse déjà à un public technique.

AMHA SàT est un logiciel de chat texte (vocal ? vidéo ?) et blog, le reste c'est de l'à coté (ajouter du chiffrement, envoyer un fichier, jouer à des jeux,…). Feu-MSN a toujours était décris comme un chat alors qu'il permettait aussi l'envoi de fichier et de jouer avec son interlocuteur.

C'est un client XMPP, ça ne se limite pas au chat ou au blog (pas encore de vidéo, mais on en parlera sûrement l'année prochaine).

Ça paraît probablement bête ce que je dis, mais ça aide clairement à donner de la visibilité à ton travail et ça pourrait t'éviter des coups de gueule.

Mon message est indépendant du projet, de manière générale je trouve dommage cette excitation à chaque annonce pour des trucs pas toujours commencés, Diaspora en a été l'exemple le plus caricaturale, et a contrario j'ai trouvé tout autant dommage qu'on le considère comme mort quand il a été repris par la communauté (pour ma part c'est là que j'ai commencé à lui faire confiance).

Quel est le problème avec ce message ?

Par ailleurs as-tu un endroit où on peut voir pour chaque fonctionnalité où est-ce que ça en est (XEP en cours ? implémentation coté client ou serveur ? etc) ? Toujours pareil ça permettrait d'améliorer la visibilité sur ton projet.

Non mais on en a parlé aujourd'hui justement (on est à un hackathon XMPP à Berlin là), c'est donc la confirmation qu'on a besoin de le faire… On va retravailler sur le site aussi qui est trop technique, et parler un peu plus de l'association, mais comme pour tout faut qu'on trouve le temps de faire ça. Aujourd'hui on va essayer de travailler sur les standards déjà, y'a du beau mon ici (développeurs prosody, openfire, movim, buddycloud, etc).

désolé pour les réponses tardives, mais on est actuellement au XMPP summit à Berlin, et donc peu disponibles. Owncloud a sa propre technologie, ça me semble difficile de fusionner.

Oui bien sûr que je connais. Mais nous avons des besoins particuliers (en particulier pour les permissions fines, c'est à dire la possibilité d'envoyer un message à un groupe de personnes plutôt que publiquement), et nous ne voulons pas être dépendants d'un serveur en particulier. Avoir la maîtrise sur le service pubsub permet de ne pas être bloqué pour développeur une fonctionnalités en cours de standardisation, ou non encore standard.

prosody: simple, fonctionnel et léger.

Le problème c'est que c'est assez difficile à mettre dans une case, c'est très large.

C'est un client XMPP. C'est donc un outil de communication. Ça sert à communiquer, donc à faire plein de chose.

Quelques exemples:

• discuter en temps réel avec une personne

• discuter en temps réel avec un groupe de personnes

• envoyer un fichier

• envoyer un flux de données arbitraire à un contact

• bloguer/microbloguer publiquement

• bloquer/microbloguer avec un groupe restreint de personnes

• communiquer avec des réseaux externes

• diffuser/utiliser des menus génériques avec accès contrôler (par exemple un serveur peur autoriser des administrateurs à recevoir des statistiques, à redémarrer la machine, etc)

• avoir une conversation chiffrée sans trace avec une personne (si votre correspondant ne sauvegarde pas lui-même), via OTR

• faire une partie de Tarot

• écouter des musiques en lecture synchronisée

• utiliser un client courriel (MUA) pour lire ses messages XMPP

• …

Non possible aujourd'hui, mais prévu pour le futur:

• partager un groupe de fichiers

• synchroniser des fichiers/répertoires

• organiser des événements

• …

Le tout sur différentes plateformes (web, console, bureau, etc).

Ça va venir, c'est pour ça qu'on ne parle pas encore de version grand public. La difficulté vient principalement du fait qu'il faut transpiler le python en javascript (d'ailleurs on devrait peut-être envisager des paquets déjà transpilés, ça simplifierait l'installation).

Nous sommes en train de travailler avec des développeurs Debian pour que Libervia arrive dedans (peu probable avant le freeze malheureusement), et ça devrait être le cas dans d'autres distributions comme Arch.

L'autre difficulté est que nous devons utiliser un service PubSub maison, et ça demande une bidouille dans Prosody (Prosody uniquement pour le moment). Nous avons commencé à travailler sur les standards pour avoir une version générique et simple à installer, nous espérons que ça sera le cas pour la 0.6 (je peux détailler le pourquoi technique si ça intéresse).

donc si tout va bien, d'ici quelques mois un « apt-get install sat-xmpp-libervia » ou l'équivalent pour votre distro devrait suffire, suivit d'une éventuelle ouverture de port sur votre firewall, voire d'options particulières à votre installation dans le sat.conf.

Oui, ce choix a été fait pour plusieurs raisons: rester sur Twisted déjà, en développement asynchrone, avoir la maîtrise simplement sur le serveur, faciliter le déploiement (pas de serveur à installer et configurer), et c'était très facile à faire car le serveur fait partie de Twisted lui même. Donc beaucoup d'avantages, alors qu'avec un serveur externe nous aurions sans doute eu d'autres problèmes à gérer, et en tout cas une installation plus compliquée. Ça nous permet aussi de contourner des problèmes, comme l'impossibilité d'envoyer un message D-Bus à un autre utilisateur du système.

Ici soit une utilise le serveur intégré et il n'y a rien d'autre que le firewall à gérer, soit on utilise un serveur web principal déjà en place, et il suffit de faire un reverse proxy. En bonus il est possible d'avoir le serveur principal sur une machine et SàT/Libervia dans une machine virtuelle par exemple.

Le serveur web est intégré dans Liberiva.

J'avoue ne jamais avoir trop compris tous ces termes. Mais si j'en crois la définition de Wikipédia: «  type de logiciel qui permet à un groupe de personnes de partager des documents à distance pour favoriser le travail collaboratif. », on s'en rapproche oui, mais ça ne se résume pas à ça (ça ne sert pas qu'à travailler ;) ).

En fait j'ai un peu simplifié dans ma phrase, c'est PEP qu'on ne peut pas utiliser comme composant, car on ne peut pas déléguer un espace de nommage à un composant (ma deuxième XEP pas encore écrite va porter là dessus). Pas le temps d'expliquer en détails parce que je dois me coucher et me lever tôt demain (sortie de 0.5 en cours, et demain je pars pour Berlin et la rencontre XMPP).

La première XEP (celle dont j'ai mis le lien) est pour que le service puisse avoir accès à des choses normalement réservées au serveur, comme le roster d'une entité. C'est indispensable pour implémenter un « access-model roster » par exemple (comprendre, pour ne réserver l'accès qu'aux membres d'un groupe de ton roster).

Tu peux passer sur le salon sat@ pour en discuter si tu veux, mais là jusqu'à la fin de semaine ça risque d'être compliqué vu qu'on sera à Berlin (sauf si on a le net facilement).

Je pense que tu es déçu par XMPP parce que ça n'avance pas assez vite à ton goût, mais ça avance.

Regarde où en étaient Movim ou SàT ne serait-ce qu'il y a un an et aujourd'hui, et dis toi que ce sont 2 projets communautaires, le premier porté par 1 seule personnes avec 1 aide régulière d'1 autre et des contributions externes, le deuxième par 2 personnes avec des contributions rares. Mais ces 2 projets ont à peu près le même âge, avancent régulièrement depuis des années et sont toujours (très) actifs. Nous notre prochain objectif sera d'utiliser SàT pour nos propres blogs, autrement dit sérieusement (en production comme d'aucuns diraient).

Vu les ressources disponibles, et la difficulté de la tâche, je pense que ça n'avance pas si mal que ça…

Le problème actuel, pour nous en tout cas, c'est que ça n'avance pas là où on voudrait: Il y a une base PubSub pour faire quelque chose, mais plusieurs problèmes à régler, à commencer par des choses mal spécifiées (par exemple l'« access model » qui permet de savoir qui peut accéder à un item - et donc un billet de blog par exemple - a des soucis, oh rien d'insurmontable, mais il faut les régler).

Ça avance beaucoup plus fort sur l'internet des objets (internet of things, IoT) en ce moment, probablement parce que certaines boîtes, dont Siemens, bossent dessus.

Pour SàT, jusque ici j'avais décidé de faire mon propre serveur PubSub parce que je n'avais pas le temps disponible pour avancer sérieusement sur les standards et attendre l'implémentation, les choses vont beaucoup mieux depuis 1 an car je ne suis plus tout seul sur le projet (Souliane m'a rejoint).

Dans le même moment, à l'initiative d'edhelas (Movim), nous nous sommes regroupés pour avancer sur PubSub il y a quelques semaines, quand je dis « on » je parle des projets qui utilisent PubSub comme base pour du microblogage voire plus, à savoir Movim (edhelas), Live Jabber (binary), Jappix (Vanaryon) et Salut à Toi (souliane et moi). Résultat: on a déjà une XEP publié (XEP-0351, attention publiée mais pas validée, elle est expérimentale), une XEP en attente de publication (http://xmpp.org/extensions/inbox/privilege-component.html) et une autre qui ne devrait pas tarder. D'autre part le summit à Berlin cette semaine est à l'initiative de Binary, et les personnes que je viens de citer y seront ensemble (sauf Vanaryon qui a un empêchement). Cette rencontre va permettre de montrer à la communauté XMPP que ça bouge de notre côté, et d'essayer de régler les plus gros problèmes PubSub, du moins on l'espère.

Les 2 XEPs que je propose (celle en attente de publication et celle qui ne devrait pas tarder) devraient permettre d'utiliser un service PubSub indépendant de celui du serveur, et donc d'avoir un cycle de développement beaucoup plus rapide (plus besoin d'attendre la release d'un serveur, ou le bon vouloir des développeurs pour avoir telle ou tell fonctionnalité indispensable).

Donc voilà, vous avez un aperçu de ce que c'est de bosser avec les standards, et vous voyez qu'on est plusieurs à faire bouger les choses. Et je pense que nos projets respectifs montrent qu'on est proches de toucher au but.

Tox remplace Jabber/SIP

Ouai enfin bon, soyons sérieux 2 min. Il y a systématiquement une frénésie avec les effets d'annonces, et après le soufflet retombe à la faveur de l'annonce suivante, et on recommence tout à zéro.

Tox est rigolo, mais pour le moment c'est un jouet: j'ai testé et la messagerie est ultra-basique et boguée, et je n'ai pas réussi à lancer une vidéo-conférence entre Paris et Vienne (sans toucher à la configuration réseau et avec Venom qui est me semble-t-il l'interface la plus avancée). Et je ne vois pas trop ce que ça apporte (hormis un identifiant plus court, ce qui est déjà pas mal, et éventuellement une certaine facilité d'utilisation) par rapport à, disons, Retroshare.

Donc peut-être que ça donnera quelque chose, mais pour l'instant je n'y vois rien d'extraordinaire, et l'engouement dont il jouï est difficile à expliquer. Les choses vont peut-être évoluer, il y a du monde dessus, mais ça m'étonnerait qu'on ait quoi que ce soit d'intéressant avant des années. Et les interfaces utilisent toutes - corrigez moi si je me trompe - la même bibliothèque, et donc la même implémentation, ce qui n'est pas forcément une bonne chose.

Comparer ça à XMPP, qui a 16 ans d'expérience, d'implémentations, et d'utilisation massive, ou à SIP qui en a 18, c'est déjà osé; mais dire que ça les remplace carrément c'est n'importe quoi ! Alors oui c'est peut-être difficile d'imaginer quand on n'est pas dedans, mais XMPP c'est des RFC, une organisation et des discussions, et plus de 300 extensions qui décrivent des choses aussi simples que gérer un « /me » ou aussi complexes que Jingle. Il y a des problèmes certes, mais dans l'ensemble ça marche et pas mal du tout. Et les problèmes on travaille dessus (à Berlin la semaine prochaine par exemple).

D'autre part, XMPP est décentralisé, et l'utilisation de serveurs intérmédiaires est à mon sens un avantage, surtout qu'il n'est pas exclu qu'on puisse s'en passer à terme (c'est déjà possible en réseau local). On parle parfois de transformer XMPP en protocol P2P, le plus important étant de pouvoir se passer de DNS, ou d'en avoir un équivalent distribué, ce n'est juste pas une priorité pour le moment. Après il « suffit » de regrouper serveur et client dans un seul endroit.

XMPP ou SIP sont déjà bien en place, et c'est à mon sens les seules solutions correctes pour avoir quelque chose dans le futur proche. Je ne dis pas que d'ici quelques années Tox ne sera pas une alternative intéressante (peut-être avant mais j'en doute), mais pour le moment on est loin du compte.

Les jeunes (oui, je me fais vieux et dit "les jeunes" maintenant), bougez-vous, allez faire un tour à l'étranger (pas forcément dans des pays de langue anglaise, la plupart des capitales ont maintenant un grand nombre de réunions informelles entre informaticiens et ça se passe en anglais car les capitales sont remplies d'étrangers venant des quatre coins du monde et c'est la langue commune),

Hum là dessus je ne suis pas d'accord du tout. Enfin qu'il faut voyager si, bien sûr ! Qu'il faut apprendre l'anglais pour un informaticien c'est évident. Mais les capitales non anglophone ne sont pas bonne pour apprendre l'anglais: même si on peut souvent trouver quelqu'un qui parle anglais, la plupart des échanges se font dans la langue locale, et on est vite largués. Dans les hackerspaces parisiens que j'ai fréquenté par exemple, la plupart des échanges oraux/par écrit sont en français (à l'exception notable du fabelier car très fréquenté par des non francophones), même si beaucoup parlent (plus ou moins) anglais. Et je dirais même plus: c'est une très bonne chose !

Sinon entretien intéressant.

C'est marrant de voir qu'il y a autant de gens qui ont voté pour le courriel, parce que j'ai l'impression que c'est un moyen qui est de moins en moins utilisé par le grand public (dans le milieu pro je pense que c'est encore bien présent).

J'ai de plus en plus de mal à trouver les adresses des gens que je veux contacter, et souvent c'est twitter qui est utilisé comme moyen privilégié pour contacter/poser une question à quelqu'un, même chez les libristes ! En plus comme je m'auto-héberge et que je n'ai pas d'adresse en @gmail ou @hotmail, il y a le risque de passer plus facilement en SPAM.

Vu que je n'ai pas de compte twitter (je consulte juste de temps en temps en faisant un « !twitter XMPP » sur duckduckgo), c'est parfois difficile voire impossible de contacter les gens.

Il y a quand même un paquet de moyens alternatifs libres qui fonctionnent, je suis étonné et un peu déçu de voir ce système proprio et centralisé aussi populaire chez les libristes. Surtout que des trucs comme seenthis sont, à défaut d'être décentralisés, au moins libres, des trucs comme Diaspora ou Friendica (et plus ou moins XMPP pour le microblogage) fonctionnent pour ce type d'utilisation, et qu'il y a d'autres alternatives plus ou moins anciennes.

facile, suffit de marquer les bits à l'encre indélébile

Conclusion : Les gens sous windows ne savent pas ce que fait leur ordinateur, et ne s'en préoccupent pas.

Je suis sous GNU/Linux et je ne sais pas toujours ce que fais ma machine: quand je vois que ça chauffe je fais un (h)top, je peux voir par exemple qu'akonadi parcours mon disque. Mais ça pourrait être un malware qui a pris la place du binaire akonadi, c'est pas dis que je m'en rendrais compte facilement. Et tout le monde n'a pas les connaissances techniques (bien qu'avoir la liste des processus devrait être un minimum, tout comme sur une voiture tout le monde devrait savoir contrôler le niveau d'huile).

La plupart du temps quand la machine chauffe ça vient d'iceweasel, alors oui je peux voir que ça vient d'un javascript sur un onglet, mais à part me taper le code source, j'ai peu de chances de savoir exactement ce que fait cette page.

moi j'essaye régulièrement des solutions libres (Jitsi, Linphone, Tox), et même Skype malheureusement. J'arrive à convaincre certains de mes contacts de faire des essais avec moi, et ils sont patients. Je vais peut-être faire un journal dessus, mais rien n'est convainquant, y compris Skype.

Le meilleur résultat c'est avec Linphone, qui en plus est dispo sur beaucoup de plateformes, mais l'interface est franchement pas agréable, et y'a beaucoup de bogues (contact qui n'apparait pas en ligne, ça sonne dans le vide, ça ne détecte pas le casque, ça sonne occupé quand le contact me dit qu'il n'a aucune sonnerie et qu'il est dispo, etc). Faudrait que je prenne un peu de temps pour remonter ça et en parler aux développeurs.

J'utilise par exemple des casques/micros USB, et c'est la croix et la bannière pour que ça fonctionne (redémarrage nécessaire, ça ne sort pas au bon endroit, etc). Alors ça peut aussi venir de Pulse Audio, mais quand je l'utilise avec mpv ça marche correctement pourtant.

Au final, je me retrouve régulièrement à utiliser le téléphone qui est encore ce qui fonctionne le mieux…

Bon faut dire aussi que j'utilise aptosid, donc tout n'est pas forcément super testé… Mais même sur d'autres distros (Kubuntu/Linux Mint/Android) je retrouve ce genre de problèmes.

Oui j'ai effectivement dit une connerie sur OTR v3, j'avais mal compris ce qu'il apportait.