Goffi a écrit 1537 commentaires

À chaque dépêche (du moins régulièrement), vous parlez de la compatibilité et des échanges avec Salut à toi et vice-versa, mais concrètement, qu’est-ce qu’on peut attendre comme communication entre les deux d’un point de vue utilisateur ?

Au niveau chat, on est 100 % compatibles, la problème est au niveau microblogage.

On utilise le même protocol, mais nous (SàT) on utilise notre propre serveur pubsub pour gérer ça, parce qu'on joue beaucoup avec la gestion des permissions, et ça n'est pas possible à l'heure actuelle avec les service pubsub intégrés aux serveurs (surtout que ce qu'on fait n'est pas encore standard). Du coup on ne peut pas communiquer avec Movim ou Jappix pour le microblog (ils sont eux complétement standards).

Nous travaillons actuellement sur 2 extensions qui devraient permettre d'utiliser notre service pubsub en remplacement du service interne, et Berlin nous a permis de confirmer que ça intéressait au moins l'auteur de Prosody. Donc la situation devrait assez rapidement changer (au pif je dirais que d'ici 3 semaines à 1 mois on devrait pouvoir être compatible Movim et Jappix).

Pour les autres services, je pense que Movim comme SàT cherchent à être 100 % compatibles XMPP, donc c'est surtout une question de degré d'implémentation, et il suffit de remonter un bogue si quelque chose vous manque ou marche mal.

Aujourd'hui Movim a déjà commencé la visio-conférence et pas SàT, d'un autre côté SàT fait OTR et pas encore Movim. Les priorités dépendent des équipes de dev et des demandes…

La plupart des infos étant sur les serveurs, on devrait pouvoir utiliser Movim et SàT alternativement ou en parallèle.

Donc d'un point de vue utilisateur, les fonctionnalités devraient être compatibles, ce qui changera ce sera surtout le degré d'implémentation (qui devraient tendre vers une implémentation complète avec le temps pour tout le monde), et la façon de présenter les choses. Dans Movim on aura plutôt une présentation sur une ou 2 colonnes, tandis que dans Libervia (interface web de SàT) ça fonctionne avec des widgets qu'on place où on veut; le choix est affaire de goûts.

Toi oui. Le mec qui arrive, regarde l'existant, et se dit que "bof c'est de la merde je vais tout reprendre à zéro vous êtes des branques" (désolé pour le raccourci ET le procès d'intention, mais il est tard), autant dire que c'est pas l'impression qu'il donne.

OK, désolé dans ce cas, j'ai compris que ton premier commentaire accusait les projets actuels d'être fermés sur eux-même. Pour Diaspora, un commentaire ici même indique que la communauté essaye de séparer et documenter le protocol pour pouvoir faire des passerelles notamment avec XMPP (ce en quoi je pourrais les aider avec plaisir).

Sinon oui l'auteur de ce journal est maladroit et ne se rend probablement pas bien compte de la tâche, mais bon c'est une chose qu'on voit régulièrement dans tous les domaines (quand j'étais plus jeune je m'intéressais au jeu vidéo amateur, et j'ai vu un paquet de personnes arriver avec l'idée du siècle ou le nouveau jeu massivement multi-joueurs qui va tout tuer en 2 mois). Et c'est formateur de s'attaquer à quelque chose, que ça marche ou non, alors ça n'est pas une mauvaise chose de tenter le truc.

Si c'est le cas pour Diaspora, c'est très nouveau. Et c'est globalement lui qui a toute la lumière.

C'est un peu dommage en effet qu'un seul projet soit beaucoup plus visible que les autres juste parce que les médias fonctionnent comme ça de nos jours. Après çça n'est pas un mauvais projet non plus, j'y crois moins qu'en d'autres mais il a ses qualités aussi. Je crois encore beaucoup au bouche à oreille une fois qu'un projet sortira un peu du lot, et j'espère qu'il n'y en n'aura pas qu'un.

Friendica commence à avoir quelques années dans les pattes, au moins autant que Diaspora. Ce n'est pas ce que j'appelle un "nouveau" projet.

C'est le « Le marché est déjà largement saturé de "réseaux" qui ne se parlent qu'à eux-même » qui m'a fait tilter, parce que c'est pile à l'opposé de ce qu'on essaye de faire. Après je n'ai rien contre Friendica, ni aucun projet libre à l'heure actuelle, et je ne vois pas le problème à ce qu'on essaye quelque chose de nouveau, par contre ça me gène quand on cherche à taper gratuitement sur les autres. Et à ma connaissance tous les réseaux libres ou presque cherchent à communiquer avec l'extérieur (bon évidemment vu mon historique il est évident que je pense qu'il vaut mieux se baser sur un protocol existant, mais ça ne veut pas dire que c'est la meilleure façon de faire, et tant mieux si de bonnes nouvelles idées émergent).

C'est complètement subjectif mais je trouve que le nom (Salut à Toi) est très sympa mais pas "vendeur". A cet égard, je trouve que Movim "passe" mieux.

Oui c'est un truc qui re-sort souvent. Le nom a été choisi pour plusieurs raison, notamment éviter d'avoir un énième nom anglophone (ou qui sonne comme tel).

« Salut à Toi » est le nom du projet dans son ensemble, les gens auront plutôt tendance à parler de Libervia ou Bellaciao qui sont les interfaces.

A propos de Movim, peut-on considérer que les deux projets ont la même cible fonctionnelle ou bien y a t-il des applications de l'un qu'on a peu de chances de voir sur l'autre (et vice versa) ?

Au niveau du microblogage and co (messagerie par exemple), ça ne sera pas forcément présenté de la même façon, mais on devrait avoir à peu près les même fonctionnalités. Après SàT est plus large sur ce qu'on veut faire, mais c'est pas forcément intéressant selon l'usage que tu veux en faire. Les interfaces multiples par exemple sont d'un intérêt ou manque d'intérêt évident selon l'utilisation que tu as.

Pour les fonctionnalités de base que les deux ont (ou auront) - chat, micro-blogging, partage, etc… - quels sont les critères qui peuvent conduire à préférer l'un plutôt que l'autre ? Par exemple, les deux permettent-ils de changer de serveur sans perdre son historique ? Puis-je passer de l'un à l'autre ?

On devrait à terme se valoir sur ces points, après tu pourras choisir de la même façon que tu choisies entre Gajim ou Swift, Pidgin, Psi, etc. On n'a pas les mêmes priorités non plus: Movim a déjà commencé à s'attaquer à la vidéo conférence par exemple, alors que nous on garde ça pour plus tard.

En tous cas bravo à tous les deux (et à ceux qui vous accompagnent dans ces deux projets).

Merci :). Faut pas hésiter à nous contacter au besoin, et Movim aussi, nous sommes des projets clairement amis…

Le marché est déjà largement saturé de "réseaux" qui ne se parlent qu'à eux-mêmes, qui rivalisent de complexité à déployer ("quoi, tout le monde n'a pas NodeJS sur son serveur?!"), et qui n'arriveront jamais à fédérer, au mieux, que des développeurs. Et même avec tous les développeurs du monde, un réseau sans utilisateur n'est … rien.

??? quoi ??? C'est une blague je suppose ? Et j'imagine que ça n'est pas le cas de Friendica sur lequel tu sembles contribuer ?

200 000 € c'est 4 développeurs pendant 1 peu plus d'un an (en gêrant pas super bien ce qui a dû être le cas). On peut faire des choses avec de l'expérience, mais ça ne m'étonne pas que ça soit parti vite avec des jeunes encore à l'école…

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.