Goffi a écrit 1523 commentaires

Dans le même ordre d'idées il y a Wikidébats, présent notamment à la fête de l'huma.

J'attends d'avoir un peu de recul pour me faire une idée sur ce genre de choses. Ça peut sembler une bonne idée de regrouper les arguments, sauf que ça va nettement dépendre de la population qui fréquence le site, du contexte du moment (époque notamment, comment prendre en compte l'évolution de l'opinion générale selon les événements ?), de l’acharnement/ de certains à éditer/rééditer, etc.

Des arguments nécessitent souvent un contexte et de longues réflexions pour êtres entendus, plus qu'un simple paragraphe sanctionné d'un d'accord/pas d'accord puisse donner. Quand on voit un sujet délicat comme « Dieu existe-t-il », la partie « pour » n'a pratiquement que des « pour » (pouce bleu) et des « objection » (main levée orange qui semble neutre) au premier niveau, tandis que la partie « contre » n'a pratiquement des « contre » (pouce rouge vers le bas qui semble montrer une opposition ferme) et des « objection » au premier niveau.

D'un autre côté, c'est un outil, et si c'est pris comme tel et pas comme source unique de réflexion, ça peut être intéressant (j'avais d'ailleurs déjà songé à faire un outil de ce style, c'est une idée visiblement dans l'air du temps).

Bref, à voir avec le temps, et à ne pas utiliser comme source unique de réflexion.

C'est très à la mode de critiquer le côté modulaire de XMPP alors que c'est au contraire son grand point fort.

Tous les protocoles qu'on utilise ou presque évoluent, y compris ceux qu'on utilise actuellement: HTTP et HTML et Javascript. Il y a des fonctionnalités qui évoluent, qui sont améliorées, abandonnées, etc. C'est le cycle de vie de pratiquement tout ce qui touche à l'informatique.

Sur HTML/Javscript les fonctionnalités sont testées dans le navigateur, souvent de manière assez crade (on teste si une méthode existe pour javascript par exemple, avant on testait carrément le nom du navigateur ce qui était très, très moche). C'est sans doute moins visible de nos jours parce que les butineurs ont de grosses équipes et sont mis à jour très vite (et je suppose que sur ce site la plupart des visiteurs ont des butineurs récents), et aussi parce qu'il y a des « polyfills », ces rouleaux de papier adhésif pour essayer de faire marcher des fonctionnalités un peu partout.

Sur XMPP c'est fait proprement (annonce des fonctionnalités, découverte, négociation, espaces de nommage, etc), je ne vois pas trop ce qu'il y a à critiquer de ce côté.

D'autre part il y a de nombreux logiciels qui utilisent XMPP, avec des anciennetés, des objectifs, des équipes et moyens différents, et donc des implémentation différentes. C'est normal que des fonctionnalités ne soient pas disponibles partout, et ça fonctionne tout de même (et on peut même encore utiliser un client qui a été écrit il y a 10 ans sur le réseau, même s'il n'a pas été maintenu).

Aussi je dois avoir beaucoup de chance parce que les fonctionnalités que j'utilise sont souvent implémentées. Je ne contrôle même pas tous mes serveurs (mon compte principal est sur jabber.fr que je n'administre pas, même si je peux demander quelque chose aux admins si j'en ai besoin), et bien évidement je n'ai aucun contrôle sur le client que la personne utilise en face.

Alors bien sûr si vous prenez comme étalon un trucs très récent et en cours de standardisation comme OMEMO, forcément ça n'est pas partout pour tout un tas de raison (débats sur les spécifications, certains n'en veulent pas, dans certains cas comme le web ça n'est pas trivial, etc.), mais c'est déjà présent dans un bon nombre de clients.

Et pour des tas de fonctionnalités, il n'y a pas besoin que ça soit implémenté partout. Le blog par exemple, rien n'empêche d'utiliser Gajim ou Xabber qui ne l'implémentent pas, et d'avoir Movim sur le web.

Mais j'ai toujours autant de mal avec XMPP. Un protocole de messagerie instantanée open-source multi-serveur est primordial, et de par son ancienneté, XMPP s'est fait une belle place (limitée bien sûr, par rapport aux messageries fermées Facebook/Hangout/Skype/…).

ce n'est pas que de la messagerie instantanée, c'est beaucoup plus large que ça.

Seulement, à chaque fois que je regarde ce qui est disponible comme serveurs/clients, je me trouve confronté à son plus grand inconvénient : savoir quel serveur et quel client prend en compte chaque extension.

Ça complique bien sûr, mais c'est aussi l'intérêt : tu as le choix et surtout des outils adaptés à des cas particuliers. C'est un peu comme pour les courriels, tu as le choix entre des dizaines/centaines de clients, mais ils fonctionnent tous ensemble.

D'un autre côté, si tu regardes en dehors de XMPP pour la messagerie aujourd'hui c'est pire : tu as le choix entre des dizaines/centaines de logiciels, mais qui ne fonctionnent pas ensemble la plupart du temps.

Après si tu ne veux pas t'embêter, tu as des solutions tout en un (client + serveur), je crois qu'OpenFire et MongooseIM vont dans ce sens.

Au final, j'en retire toujours la même impression (peut être fausse, ce n'est qu'une impression) : que XMPP est un protocole open-source fragmenté.

« fragmenté » n'est pas le mot qui convient, c'est un protocole qui a de nombreuses implémentations, mais elle fonctionnent ensemble.

Existe-t-il un site qui répertorie tous les serveurs/clients les plus connus/utilisés, avec leurs fonctionnalités, sous forme d'un tableau, et à jour ?

Wikipédia en effet, également https://xmpp.org/software/clients.html, https://xmpp.org/software/servers.html ou encore https://www.zash.se/xmpp-features.html. Mais ça n'est pas super simple pour un nouveau venu et ces tableaux sont difficiles à lire/utiliser, il y a des améliorations à faire dessus c'est évident.

Ces évolutions (en particulier la gestion native des WebSockets) permettent-elles d'utiliser prosody pour faire tourner un client web comme Movim ?

Movim peut fonctionner avec Prosody, mais il sera en mode « dégradé » : la fonctionnalité qui manque principalement est la persistance des données en PubSub (le problème est pour la partie blog : les billets ne seront pas conservés après un redémarrage du serveur).

Le composant que nous développons pour SàT, SàT Pubsub mentionné plus haut, permet la persistance et fonctionne avec Prosody, donc il règle ce problème mais il faut attendre la sortie d'une version stable (enfin c'est utilisable en l'état, mais pas trivial à installer).

Par ailleurs, Aeris m'avait indiqué lors d'un bref échange sur Twitter qu'un outils à la Mastodon, avec des flux publics, ne pouvait pas fonctionner à base de XMPP. Qu'en pensez-vous ?

c'est des conneries.

On a déjà des flux publics, et côté blog mis à part XMPP a depuis longtemps montré qu'il était capable de tenir de très forte charges, notamment avec des serveurs comme Ejabberd. Mais bon, c'est pas la première fois et sans doute pas la dernière qu'on lit n'importe quoi à propos de XMPP.

jp a été pas mal amélioré sur ce point dans la version de dév, mais la 0.6.1 le permettait déjà. Tu as un tuto sur mon blog si tu veux, sinon jp blog --help et jp pubsub --help devraient te permettre de t'en sortir, ou alors viens sur le salon de SàT je peux t'aider.

Oui c'est ce que font OMEMO et OX (OpenPGP fait correctement), c'est d'ailleurs le principal intérêt par rapport à OTR.

Si l'implémentation est faite correctement (en suivant les recommandations de la XEP), le message n'est pas copié (seul le destinataire aura le message).

Si ça n'est pas fait correctement, le message chiffré sera copié, et ignoré par les appareils qui ne peuvent pas le lire, donc un peu de bande passante/processeur utilisés pour rien.

Je pense que la plupart des clients actuels sont dans le premier cas (donc le message n'est pas copié inutilement).

Beaucoup de serveur de cette liste sont bien placés. En revanche, seul conversations.im est compatible pour le chiffrage ONEMO pour un contact hors ligne. Cette fonctionnalité est-elle disponible avec ejabberd? Est-ce un chantier en cours? Il me semble que ce sera implémenté par mod_pep_plus mais il n'y a pas encore beaucoup d'activité.

je viens de jeter un œil au code qui teste ça, ça teste uniquement la présence de la fonctionnalité #publish-options et ça me semble un peu curieux voire trompeur. Cette fonctionnalité permet de configurer un nœud Pubsub à sa création. En d'autres termes et dans le cas présent, ça permet d'autoriser des gens qui ne sont pas dans la liste de contacts (roster) à accéder aux infos OMEMO (clef publique je suppose) au moment où on créé le nœud, c'est à dire l'endroit où sont enregistrées ces infos.

Sauf que si cette fonctionnalité n'est pas présente, il est tout à fait possible de faire la configuration dans un deuxième temps (avec une autre requête XMPP), c'est juste un peu moins efficace.

Bref, je ne vois pas l'intérêt ce test, ou alors j'ai loupé quelque chose.

La fonctionnalité #publish-options ne semble pas pas présente dans ejabberd (je viens de tester sur pubsub.movim.eu), et je ne sais pas pour mod_pep_plus (utilisant SàT pubsub, je ne suis pas le développement du composant interne de très près).

Pour Goffi: tu as développé le composant sat_pubsub qui se substitue au pubsub interne du serveur. Est-ce que ce composant est toujours utile?

Oui, et je pense qu'il sera toujours (longtemps du moins) utile et pas que pour Prosody, je dois écrire un billet de blog sur le sujet depuis un moment mais je manque de temps. En gros Pubsub c'est plus ou moins la base de donnée de XMPP (ou plutôt une interface standard pour les bases de données), et c'est un composant complexe à écrire. Les implémentations serveurs sont inégales, et quand une fonctionnalité apparaît, on est dépendant du bon vouloir/des possibilités des équipe de dév et du cycle de sortie des serveurs pour en profiter.

Avec SàT Pubsub, on a un composant générique et indépendant, on est sûrs d'avoir tout ce qu'on veut (si ça manque on implémente nous même) et il peut fonctionner potentiellement partout.

Qu'apporte-t-il de plus par rapport aux autres implémentations?

Outre ce que j'ai dit plus haut, je crois que c'est la seule implémentation libre actuelle qui implémente MAM qui permet notamment la recherche, il implémente l'attribut publisher (qui permet de vérifier qui a publié un élément), RSM (résultats par pages), a la persistance, les modèles d'accès open, presence, et whitelist (cf. l'épisode 8 de Parlons XMPP), et d'autre bricoles. Il est testé en permanence avec un client qui fait du blog, donc adapté à ça.

En plus de ces fonctionnalités, c'est aussi un terrain d'expérimentation avec notamment un accès spécifique publisher-roster qui couplé aux permissions fines permet d'avoir des éléments (billets de blog par exemple) réservés à un groupe (fonctionnalités appelée par ailleurs « cercles » ou « aspects »), et depuis récemment des « schémas de nœud » qui permettent entre autre de contrôler ce que les gens peuvent publier. Là aussi je dois écrire un billet sur le sujet, et je compte proposer ceci à la standardisation (quand j'aurai du temps là encore :-/ ).

Pour le 3ème point, je pense que Link Mauve ou mathieui pourront te répondre.

Je trouve XMPP très intéressant et je m'en sert au quotidien mais c'est vrai qu'il n'est pas toujours facile de trouver l'information pour faire des choses modernes. Cela semble changer et j'espère bien pouvoir expérimenter ces nouvelles possibilités prochainement.

Oui c'est vrai, et il y a un travail fait par différents acteurs pour améliorer ça, espérons que ça porte les fruits rapidement.

Sinon, à titre personnel, je trouve l’ambiance sur les salons officiels de SàT, Movim, JabberFR très conviviale et on y apprend souvent des choses intéressantes.

:).

La fois de trop j'ai décidé de basculer vers autre chose, à savoir prosody. Beaucoup plus sympa à administrer, mais : il faut plein de modules pour avoir des fonctionnalités, modules qui ne sont pas utilisables avec la version stable, du coup il faut se palucher une compilation locale depuis les sources. Je pense notamment à ce qui est mis en avant dans le journal, à savoir l'historique partagé, côté serveur. Il y avait aussi le stockage des mots de passe utilisateur, en clair dans des fichiers texte. Il y avait de la doc pour basculer vers autre chose, mais c'est/c'était le réglage de base.

Ben tu vas être content, la nouvelle version stable avec l'historique côté serveur (MAM) vient de sortir : https://blog.prosody.im/prosody-0-10-0-released/

Tu interprètes un peu, je n'ai pas que j'étais contre un service commercial (qui n'est d'ailleurs pas incompatible avec des associations, ni avec un système éthique). J'ai dit que je préfère de loin voir des solutions locales au maximum à des gros services nationaux/multinationaux. Et local ne veut pas dire pas sérieux ou de mauvaise qualité. Au contraire, je préfère pouvoir voir quelqu'un physiquement si nécessaire.

Ce serait peut-être un excellent argument de vente: "notre contrat d'utilisateur interdit explicitement et formellement l'exploitation de vos données personnelles et nous nous engageons à ne pas placer de publicité sur notre client officiel".
Ça pète quand même plus que les habituels
"Assurez-vous de bien lire le contrat de 152 pages en petits caractères avant de cliquer sur le bouton "Accepter le contrat". Votre formulaire d'inscription sera déclaré périmé dans 3min24. J'espère que vous lisez vite…"

On n'a pas écrit ça comme « argument de vente », mais https://salut-a-toi.org/social_contract.html

Regarde Matrix et Riot: un immense succès et presque tous les utilisateurs sur le même serveur officiel. Les serveurs persos, locaux, associatifs, ils arrivent après, quand la mayonnaise a pris.

« un immense succès » tu t'emballes un peu. Ils ont fait un marketing agressif qui a fonctionné auprès d'un public technique, et ils ont une application qui visiblement est léchée (pas testé moi même encore), mais de là à appeler ça « un immense succès » j'attends de voir.

Et puis, encore une fois: si tu veux te financer avec ça, il te faut la manne. Si tu ne comptes que sur les dons, ça fait mal, mais tu es alors en concurrence directe avec toutes les associations que tu souhaites voir devenir hébergeurs.

Non je ne compte pas que sur les dons (du moins pas à l'heure actuelle), et je pense qu'il y a de la place pour tout le monde (y'a pas non plus foule d'associations qui proposent des hébergements de service libres, et quand ça arrivera je serai content).

Je ne vois pas en quoi vendre de l'hébergement ça serait contraire à vos valeurs. Au contraire ça permet de développer vos valeurs : faire en sorte que le grand public puisse réellement utiliser XMPP.

ce n'est pas ce que j'ai dit, j'ai dit qu'on souhaitait en vivre en gardant nos valeurs, un hébergement n'est pas du tout contraire à ça bien entendu. Je sous entendais plutôt continuer à faire du libre, pas de publicité, pas de vente de donnée personnelles, etc.

Le grand public n'utilisera pas votre logiciel client s'il n'y a pas des offres d'hébergement grand public. La base quoi.

oui bien sûr. Mais j’espère plutôt voir des hébergements locaux/associatifs.

Tu pourras en discuter avec Daniel Gultsch qui visiblement a prévu d'assister à ta conférence : https://twitter.com/xmpp_berlin/status/912083945440899072

c'était mercredi dernier ;). Et Daniel n'était pas là, il est en Allemagne mais pas à Berlin il me semble.

Sincèrement Goffi je ne comprends pas pourquoi depuis le temps que tu promeus et travailles sur XMPP et étant donné ta maîtrise technique tu n'as pas développé un service de qualité comme Daniel Gultsch ou Nicolas Lœuillet avec Wallabag.it. Dans le même genre il y a aussi Antoine Nguyen qui développe Modoboa.

Je ne suis pas certain que l'administration d'un serveur XMPP puisse aider beaucoup à nous financer, et ça prend du temps (qu'on n'a pas).

Par contre vivre de XMPP en gardant nos valeurs c'est ce qu'on cherche à faire, notamment en faisant du service autour du développement et de notre projet. La sortie de la première version stable/grand public approchant, la question va bientôt pouvoir se poser sérieusement.

Tu oublie l'entête XML, la balise stream et tout ses namespaces. Et je ne parle pas du protocole de transport si on communique pas directement sur les ports XMPP (HTTP entre autre…)

Non je n'ai pas oublié la négociation de base, c'est juste que ça n'est pas pertinent ici. C'est une fois au début ça, ça n'est pas ce qui est envoyé à chaque message, et c'est présent dans n'importe quel protocole.

XMPP est indépendant du protocole de transport, tu peux l'utiliser sur TCP (ce qui est le cas courant décrit dans les RFC), ou HTTP, ou autre. Si tu choisis d'utiliser autre chose que TCP, tu as probablement des bonnes raisons (utilisation dans un navigateur, vouloir passer un NAT, ou que sais-je), et dans ce cas tu as les avantages/inconvénients du transport en dessous, mais ça n'a rien à voir avec XMPP lui même, donc je ne vois pas trop le rapport.

Et donc non, ce n'est pas léger. Le XML n'est pas léger. Si c'était le cas, il n'y aurait pas eu d'autres formats créés pour les échanges de données, comme YAML ou JSON.

J'ai pas non plus dit que XMPP était le format de sérialisation le plus léger du monde, j'ai dit que XMPP était relativement léger et certainement pas lourd comme tu l'indiques. Tu t'avances un peu sur les raisons de créations d'autre formats de sérialisation, JSON a l'avantage (pour le web) d'être un sous ensemble du Javascript, YAML est pratique pour la lecture, je ne suis pas sûr que la raison principal de leur création est la supposée lourdeur de XML. Si c'était l'objectif principal, on se tournerait vers des formats binaires.

IRC n'est peut être pas le bon exemple pour comparer. Alors prenons ICQ par exemple. Pour envoyer ton message d'exemple, avec un ICQ ça prend 32 octets + longueur du message (6) soit 38 octets. Avec XMPP, il faut 54 octets rien que pour ta balise message, sans compter l'en tête XML, la balise stream, les éventuels caractères blanc entre les balises etc.

Mais j'ai l'impression que tu penses que l'en-tête XML et la balise de stream sont envoyés à chaque message, ça n'est absolument pas le cas ! Et accessoirement le flux peut être compressé, donc ce qui passe effectivement dans les câbles est nettement plus petit que le message XML que le développeur peut voir/générer.

Elle définit que le schema XML du protocol, donc que celui-ci repose sur XML et pas sur autre chose à priori (à moins qu'il y ait une autre XEP qui propose une alternative à XML ?)

non, elle définit le fonctionnement du processus de standardisation, ce sont les RFCs qui indiquent que ça utilise du XML, et ça peut effectivement être changé par des XEPs comme celle que j'ai indiqué dans mon précédent message.

Alors on passe sur meet.jit.si, on perd la vidéo aussi régulièrement, mais pas le son

Essayez avec un autre serveur, cf. mon message par ailleurs. Le mieux serait d'avoir le votre pour être sûr d'avoir une bande passante dédiée, et de bien configurer pour avoir tout ce qu'il faut pour passer les NAT.

un message minimal c'est

<message to='toto@example.net'>
    <body>
        salut!
    </body>
</message>

C'est pas franchement terrible. Et si vraiment ça pose un problème (mémoire limitée en embarqué par exemple), tu as des méthodes de compression (Efficient XML Interchange (EXI) Format par exemple).

Ce qui prend vraiment de la bande passante à l'usage par contre, c'est les informations de présence (surtout de nos jours avec les appareils mobiles qui se connectent/déconnectent en permanence), et ça va être optionnel avec MIX (ça l'est déjà dans certaines implémentations, et le problème est réduit avec la gestion de flux (Stream Management) qui limite les déconnexions).

Et tu as le choix en fonction de ta configuration de limiter les infos que tu utilises, d'avoir une synchronisation ou pas, etc.

En pratique tu constateras que Prosody ou Conversations sont très peu gourmands en ressources là où d'autres ont des soucis. Oui XMPP est relativement léger.

Alors bien sûr si tu compares un XMPP avec plein de fonctionnalités activées (présence, accusés de réception, états de conversation etc.) à un IRC qui ne fait que du message simple, tu auras une bande passante nettement plus importante (y'a beaucoup plus d'infos qui passent). Mais si tu fais à fonctionnalités égales, je ne suis pas sûr que ça soit beaucoup plus gros, et si tu optimises comme expliqué plus haut, c'est probablement même moins demandant en bande passante.

mise à jour: je n'ai pas compris le rapport avec la XEP-0001 par contre

Pourquoi donc ? XMPP est parfaitement compatible avec WebRTC (https://xmpp.org/uses/webrtc.html), c'est même une très bonne chose. La vidéo conférence était quelque chose d'extrêmement compliqué à développer auparavant (codecs, annulation d'écho, etc) et c'est ce qui explique pourquoi ça a mis tant de temps à se développer (jingle ne s'occupe que la négociation de la session P2P et du « signal », ce qui n'est qu'une partie du problème).

WebRTC et ses implémentations offrent une résolution standard de ces problèmes, ce qui rend maintenant la visioconférence très accessible, et c'est pour ça qu'on la voit désormais presque partout, au moins dans les applications web.

edit: ah ben edhelas a répondu la même chose :)

Je n'apprécie pas les inscription via SMS pour une raison similaire (pas envie de filer mon numéro, pas envie que mon opérateur me spy).

Je n'aime pas filer mon numéro également, mais grâce à mes contacts qui utilisent Whats App (que je n'ai jamais utilisé) ou similaire, ils l'ont, et ils connaissent certaines de mes relations. Ça ne pose visiblement pas de problèmes à beaucoup de monde ici, mais moi ça m'en pose un, et un gros.

On connait d'autres cas d'usage d'XMPP hors messagerie instantanée ?

https://linuxfr.org/users/jnanar--2/journaux/mon-ami-se-fait-des-amis
https://linuxfr.org/news/authentifiez-vous-sans-mot-de-passe-grace-a-xmpp
https://linuxfr.org/tags/parlons_xmpp/public
https://salut-a-toi.org (que je développe)
https://movim.eu
http://projectmaxs.org
https://habahaba.im/
https://meet.jit.si/

pour les premiers qui me viennent à l'esprit. Souvent ça fait aussi messagerie (parce que bon, tant qu'à utiliser XMPP).

Dans l'embarqué (enfin pardon « l'internet des objets » ou IoT ça fait mieux), c'est de plus en plus utilisé aussi.

Jusqu'ici j'avais testé sans succès Jitsi: ça marchotait mais l'image bloquait assez vite ou autre problème. J'utilisais toujours https://meet.jit.si/ et hier j'ai testé avec https://framatalk.org suite à une discussion à Berlin sur le sujet qui m'a fait comprendre un truc tout bête : leur serveur est probablement surchargé, et du coup ça bloque. Pour le coup ça a marché vraiment super bien, et c'est un lien à envoyer c'est tout.

De toute les solutions libres (XMPP ou pas) que j'ai essayé jusqu'ici, Jitsi meet et celle qui a de loin marché le mieux (en audio pur il y a Mumble qui marche très bien, mais c'est beaucoup plus compliqué d'inviter quelqu'un, il y a un logiciel à installer et à configurer).

Par contre je ne sais pas si ça marche dans Android (ça doit marcher au moins dans le navigateur).

Pour le reste de la question (le journal), je trouve de plus en plus stérile les discussions sur le sujet ou sur ce qu'il faut ou pas faire. On sait parfaitement ce qu'il faut faire, mais on manque tout simplement de ressources pour que ça aille plus vite. Un logiciel comme Conversations qui a un certain succès est plus léché notamment parce qu'il a un développeur un plein temps dessus, tout simplement.

je pensais indépendamment d'un navigateur (ou alors avec quelque chose headless), et oui pour avoir du temps réel.

Si, par exemple, on est dans une application de chat proprio, qu'il n'y a pas d'API ni rien, pouvoir utiliser weboob pour faire une passerelle serait un bon moyen pour avoir une solution rapide le temps de faire un reverse engineering sur le protocole. Oui avec les Websocket ça serait bien aussi.

Je me doute que ça n'est pas possible à l'heure actuelle (vous n'en avez pas l'utilité a priori), mais je me demandais si c'était envisageable avec l'archi de Weboob, et apparemment oui donc :)

Salut,

bravo pour cette version.

Je me demandais si Weboob était capable de surveiller une page et réagir à des événements, notamment un nouvel élément DOM qui apparaît.

Un exemple serait une page web gérant une messagerie : est-ce qu'un nouveau message qui apparaît pourrait déclencher une callback par exemple ?

Je sais que ça n'est pas du tout l'objectif de base, et que ça complique énormément (notamment parce qu'il faut interpréter du Javascript, mais j'ai cru comprendre que Weboob commençait à le faire dans certains cas), je me demande juste si c'est possible/envisageable.

Encore une chose, en survolant la doc de l'API je ne vois rien qui permet de recevoir les messages/notifications en temps réel. Est-ce qu'un système type webhook, long polling ou autre est envisagé ? Merci

super, merci pour les infos c'est ce qu'il me fallait.

Déjà bravo pour cette version et le travail qui va avec.

Est-ce qu'il y a un endroit où on peut suivre l'évolution de l'API ? Je fais parti de ceux intéressés.

D'autre part en Python je vois principalement 2 modules : diaspy et federation. Si je comprends bien le premier utilise l'API (il y en a une provisoire donc ?) et le second est une implémentation du protocole, c'est bien ça ? Est-ce que l'évolution de l'API risque de casser diaspy ?

Bonne continuation.