Larry Cow a écrit 5011 commentaires

La plupart des XEPs sont en expérimental ou deferred, et ça n'est pas standard dans ce cas.

C'est aussi un aspect important de l'impopularité d'XMPP, à mon avis. Trop de XEP mort-nées. Ca décourage, et puis ça éclate un peu les efforts : tu sais aussi bien que moi que le fait d'être expérimental ou deferred n'empêche pas d'avoir une implémentation qui marche dans la nature. On a bien vu avec Jingle et Google ce que ça a pu donner.

Friendica est toujours là, ainsi que redmatrix, le projet lié.

Je sais bien, je les suis de près. Mais Friendica a changé (au moins) deux fois de noms, sans compter Red (qui a aussi eu son lot de dénominations variables), d'où ma remarque.

Non, ça c'est si tu veux contribuer au standard, et c'est un cas plutôt rare

Oui et non. Si je m'emmerde à créer un client XMPP pour un besoin, ce n'est pas pour qu'il puisse ne parler qu'à lui (sinon, pour ça, on a des tas de manières plus simples de faire). Je peux me contenter du dénominateur commun d'XMPP (chat et présence), mais il est assez probable que j'ambitionne mieux (après tout, ICQ ça commence à dater un peu). Mais si je veux que mes améliorations soient un tant soit peu acceptées par d'autres clients, pas trop de choix : il faut passer par un XEP (sans garantie d'implémentation, d'ailleurs).

En caricaturant un peu (mais pas tant que ça), aujourd'hui le mec qui démarre un projet à base de XMPP, soit il a besoin d'une XEP, soit il n'avait pas besoin d'XMPP (voire de faire un nouveau projet).

Ben c'est exactement pareil pour les projets XMPP. Il faut bien différencier standard et projets qui l'utilisent.

C'est peut-être un problème de communication, mais pour quelqu'un d'extérieur à l'écosystème c'est loin d'être évident. Et même pour moi, qui ait suivi et évangélisé comme un cochon il y a quelques années, c'est parfois (un peu) nébuleux.

Ce sont des façons de faire différentes, c'est comme pour Kde et Gnome ou Vim et Emacs. Mais tu peux toujours aider les différents projets en même temps, comme dit plus haut.

FreeDesktop a malheureusement montré les limites de la standardisation "volontaire". Même si XMPP est loin d'être aussi mal barré.

Comme pour toute techno, il y a un ticket d'entrée, mais je pense qu'apprendre à lire des XEPs et repérer celles qui t'intéressent c'est pas hors de portée du tout. Et après ça s'adapte très très facilement à un cas particulier.

Il y a toujours un ticket d'entrée, mais avec la déferlante WebRTC le ticket d'entrée est cher pour ce qu'il apporte. Si je veux bricoler un truc rapide, je peux récupérer un Conversation.js et me démerder avec "juste" du Web (et un serveur de signaling, mais autrement plus simple que de devoir gérer un serveur XMPP). Si je veux mettre en œuvre du compliqué, l'historique des projets "compliqués" de l'écosystème n'est pas spécialement encourageant (oui, Buddycloud, c'est à toi que je pense).

on n'est pas du tout au même niveau. XMPP peut très bien utiliser WebSocket et WebRTC

Et c'est un des points qui me (re)donne un peu espoir. Mais ça reste encore peu répandu.

(Movim le fait d'ailleurs).

Alors là par contre, je me marre un peu : venant d'un projet qui préférait (et revendiquait) l'établissement de la connexion XMPP par le serveur, c'est drôle :)

Je ne sais pas comment ils ont évolué, du coup. Je vais aller me repencher dessus.

Tu vois où je veux en venir?

Pas vraiment pour être honnête.

Simplement au fait qu'une des meilleurs vitrines "concrètes" pour XMPP est un logiciel qui ne se contente pas d'XMPP (pour raisons historiques, certes, mais la partie SIP est encore très correcte et très utilisée, surtout en entreprise).

Bref

Comme d'habitude, je me suis un peu dispersé. Désolé. Je vais essayer de préciser.

Quand Jabber a commencé à bouger, l'idée était très bonne. Proposer un standard qui corresponde à la base de la messagerie instantanée d'alors, avec une possibilité d'extension. Ça aurait pu séduire, et si MSN n'avait pas existé ça aurait probablement été le cas. Pouvoir implémenter des comportements "métiers" par dessus une base commune et compatible avec d'autres logiciels (éventuellement utilisés dans d'autres domaines), c'était de la grosse balle. Et sur le principe, c'est toujours de la grosse balle.

Sauf qu'aujourd'hui, la "base commune" a changé. Chat et présence, même avec la possibilité de salons, c'est très léger par rapport à la concurrence (notamment Skype). Du coup, le "cadre" XMPP n'apporte plus grand chose par rapport à - mettons - un TogetherJS, et ce pour un "coût" technique considérable.

C'est facile de critiquer de ma position de mec qui n'a pas foutu grand chose sur le sujet, je sais. Mais le coche a été raté il y a des années, à mon avis. Il avait été question de définir des profils XMPP, avec des ensembles croissants de XEP à supporter pour se conformer à tel ou tel profil. Je ne sais pas ce que ça a donné de concret, mais imposer un profil avec au moins voix/vidéo/filetransfer comme étant la base aurait pu sauver Jabber. Le simple fait que ces fonctions-là ne marchent pas entre tous les logiciels XMPP qui les implémentent, c'est très mauvais signe.

Et ça ne me réjouit pas, tu peux me croire.

Il y a surement un humain quelque-part derrière à contacter, non? ;)

Quand on a réduit la semaine de travail de 48 heures à 40, y'a des patrons qui étaient pas contents. Bah on a dit "tant pis pour eux". Meme chose quand on a instauré les congés payés. Je suis à peu près sur qu'à l'epoque aussi, on a fait du chantage à l'emploi.

Et l'histoire a largement prouvé, depuis, que c'était du bluff-Martoni.

Le DIF dans le public, c'est assez différent, dans mon souvenir. À part le nom, ça n'avait pas grand chose de commun avec le DIF du privé : nombre de refus possibles supérieur (et potentiellement illimité si ta hiérarchie se démerde bien), droit de regard sur le sujet de la formation, etc.

Ils ont aussi un mode de fonctionnement différent: ils ont leur propre trucs, ils ne standardisent pas

Jusque-là, tout le monde a toujours un peu l'impression que ceux d'en face ne standardisent pas. Pour un développeur non-XMPP, une XEP c'est pas un standard (en tous cas pas plus que la spécification de StatusNet). Bon après, certains ont vraiment fait les gorets avec leurs spec', genre Diaspora à leurs débuts.

et il y avait une boite derrière si je ne m'abuse, avec un certain nombre de dévs.

C'est vrai, mais c'est le cas aussi chez certains acteurs XMPP (OneTeam, IgniteRealtime, …). Et si tu veux du microbloggage tout seul et sans boîte, il y avait le Friendika de l'époque qui correspondait assez. Bref, ça existait.

mais j'ai l'impression que identi.ca a fait une belle erreur en passant à pump.io.

J'ai l'impression qu'ils ont fait pas mal de belles erreurs, en fait. Pump en est peut-être une, je connais assez mal. En revanche, avoir voulu à tout prix intégrer de la confidentialité dans un modèle qui ne s'y prêtait pas (et qui ciblait Twitter qui n'en avait guère non plus de toutes manières), ça a probablement tué StatusNet.

Le problème c'est toujours le même: on n'est pas beaucoup aidés.

C'est vrai, et je plaide coupable. Ceci étant, si on considère la raison pour laquelle on s'est mis à parler d'XMPP ici, il y a peut-être un élément de réponse dans le caractère extrèmement formel d'une contribution XMPP "utile" : je peux toujours faire un truc perso pas standard dans mon coin, mais si je veux être un bon citoyen XMPP il faut que je me farcisse une XEP, que je la défende, maintienne, etc.

Alors que si je veux contribuer à RedMatrix (pour en citer un que je connais), il me suffit d'aller discuter le bout de gras avec le développeur principal, de faire un pull request, et c'est parti : j'ai contribué et tout le monde en profite.

À vouloir être un standard et/ou un écosystème avant d'être un produit, XMPP tend à n'être qu'une solution pour développeurs, pas pour utilisateurs. Or, les développeurs libres sont très souvent d'abord des utilisateurs.

Matrix, le sujet de ce journal, ils ont eu la bonne idée de faire une implémentation de référence. Alors on sait comment ça se passe, il y a toutes les chances que celle-ci reste durablement la seule et unique implémentation, et que les contributeurs soient davantage contributeurs à cette implémentation qu'au standard. Certes. Mais fonctionnellement, ça ne sera qu'un demi-échec : Matrix évoluera quand même. Chez XMPP, il me faut choisir : soit je contribue à SàT, soit je contribue à Movim, soit je contribue à Jitsi… avec à chaque fois des technos radicalement différentes, et pas de "leader" qui se dégage. Et si je veux implémenter MES idées avec MA techno, la marche est considérable, sans garantie de pouvoir échanger plus avec l'écosystème que du chat texte et de la présence.

Fut un temps, j'ai cru que ça pourrait décoller. On voyait sortir des nouvelles librairies XMPP facilitant le boulot, et se lancer dans un nouveau client promettait de devenir "simple". On mettait du Web plein dans XMPP, et c'était cool. D'aucuns ont commencé à pousser XMPP (+BOSH) comme LE protocole pour remplacer AJAX. Là encore, la sauce n'a pas pris et WebSocket+WebRTC rendent les atouts d'XMPP-on-the-Web non-déterminants.

Ils font des conférences à plusieurs avec vidéo, il n'y a pas beaucoup de logiciels qui permettent ça à ma connaissance.

En libre, non, clairement. Il y a Subrosa, dont je parlais un peu plus haut. Mais le problème reste toujours le même : la connectivité coûte cher, et personne n'est prêt à en faire cadeau à des clients sans contrepartie.

Après, je vais être honnête : Jitsi, c'est probablement le "produit" le plus bandant pour un utilisateur lambda, et ce de tout l'écosystème XMPP. Notamment par son côté couteau suisse, dont le fait qu'il sache aussi parler le SIP. Tu vois où je veux en venir?

Enfin, pour la tour Eiffel, on peut imaginer une banque d'objet 3D (format 'obj' wavefront par exemple) avec info d'implantation latitude/longitude/orientation.

C'est assez exactement ce que font OpenBuildingModels, sauf qu'ils passent par du VRML. Il peut quand même y avoir du code à s'échanger (dans la mesure où quelqu'un arrive à faire marcher leur truc).

Twitter est centralisé. Si tu veux le comparer, compare le à Elgg. C'est autrement plus simple de faire un truc centralisé (sans renier le travail sur ces logiciels).

XMPP tu peux le comparer à Diaspora ou Gnu Social (Status Net), et je crois qu'il n'a pas trop à rougir de ce côté. Surtout que son évolution dans un sens dépend de l'intérêt des développeurs, et l'intérêt pour le microblogage est plus récent que celui pour la visio par exemple.

Justement : Status Net, ça fait au moins 4 ou 5 ans que ça fait (faisait?) des trucs qu'XMPP a encore du mal à faire en matière de microbloggage. C'était tout sauf parfait (en termes de permissions notamment), mais ça juste-marchait.

Côté XMPP, on a eu des trucs très encourageants (Jappix à ses débuts est celui qui m'a le plus bluffé, mais d'aucuns citeraient Movim ou SàT). Et puis, alors qu'on aurait raisonnablement pu espérer que l'ensemble de l'écosystème profite de la dynamique et que tous les µblogs se parlent indépendamment des clients et des serveurs … ça reste très laborieux. Pas pire qu'il y a 4-5 ans, mais on ne sent pas vraiment arriver le moment où on pourra le conseiller à tata Michue.

Et ce n'est pas spécifique à SàT du tout (d'autant que si j'ai bonne mémoire tu n'es pas loin d'être le dernier arrivé).

C'est pareil pour la voix/vidéo. Il y a quelques années, avec Jingle, ça allait marcher. Toutes les implémentations allaient converger vers la même version du standard et tout le monde pourrait se parler. On a remis le couvert quand, poussé par Jitsi, est arrivé Jingle Nodes : Skype n'aurait plus qu'à bien se tenir. Et là, en 2015, quand je dois proposer une alternative au-dit Skype je suis bien emmerdé : c'est encore les solutions WebRTC qui s'en tirent le mieux (chapeau bas à SubRosa qui m'a donné de très bons résultats récemment, d'ailleurs).

Des super-clients comme OneTeam ont disparu des radars. Les serveurs XMPP les plus utilisés sont en train de changer de crèmerie. Jitsi, qui faisait partie des plus dynamiques des clients "génériques", ne bouge plus bien fort et sa dernière version vend vraiment du rêve : support d'IRC, support de Java 8, un nouveau codec et un splash screen (je caricature un peu, il y a beaucoup de boulot côté bugfix, mais ça n'est pas vraiment révélateur d'une phase d'expansion).

J'aime l'idée d'XMPP, j'ai joué le jeu longtemps, j'ai évangélisé comme j'ai pu. D'aucuns peuvent témoigner que j'étais même "grave chiant" avec ça, à pas vouloir faire comme tout le monde, et à vouloir en mettre partout. J'y croyais, et j'aimerais pouvoir dire que j'y crois encore. Sauf que, si je suis lucide, c'est de plus en plus difficile d'y croire.

Mais c'est difficile de bosser régulièrement, d'expliquer à famille et amis pourquoi on fait ça, de ne pas se décourager quand on passe une semaine sur un truc qu'on pensait faire en une aprem, de ne pas vouloir faire trop de bruit trop tôt par risque de déception, mais pas trop tard non plus parce qu'on va avoir besoin d'en vivre et d'avoir une motivation extérieure.

Ce n'est que trop vrai, hélas.

Très bonne initiative, comme souvent dès qu'on touche à OSM. Question bête : tu comptes te limiter aux "Simple 3D Buildings" ou pas? Parce qu'ils sont assez rapidement limitatifs (j'ai un exemple sur le territoire que je maintiens à jour, c'est vite chiant… la tour Eiffel en est un autre).

Il y a bien http://openbuildingmodels.uni-hd.de/ mais je n'ai jamais réussi à leur fournir un VRML qui leur plaise.

Merci, c'est sympa d'avoir un cas d'utilisation de Docker pour se faire la main, je vais finir par me laisser tenter. Par contre, une première lecture rapide me chipote un peu : pourquoi est-ce qu'on a l'impression que tu fais des trucs en double dans le premier Dockerfile? Genre les lignes suivantes :

ADD ./alban.garrigue.me.conf /etc/apache2/sites-available/
RUN a2ensite alban.garrigue.me.conf

Surement une merdouille, si - en tous cas c'est le cas pour Webex que j'utilise (malheureusement) bien plus. Mais ça reste "simple" par rapport à une ouverture de port ou l'installation d'un Tomcat.

Merci, c'est bon à savoir et je zieuterais. Reste que restreindre les marges d'extension "sans compilation" (quand elles sont disponibles techniquement, j'entends) me semble relativement contraire à l'esprit du libre, sinon à sa lettre. Quand un fournisseur matériel interdit de lancer du code (libre) non-signé, c'est un chacal. Quand un OS interdit de lancer du code (libre) non-signé, c'est un chacal. Quand un navigateur, qui commence de plus à en plus à ressembler à un OS et/ou à une plateforme matérielle, se permet la même chose c'est bénéfice du doute.

Es-tu en train de dire que si firefox était peu connu, le fait d'utiliser un store utilisant des DRM serait ok ? (ce avec quoi je ne suis pas d'accord: l'idée de Mozilla est foireuse quoi qu'il est soit)

Non. Juste qu'une des raisons pour ne pas être populaire, c'est d'être un mauvais logiciel. Après, je ne le connais pas, donc bénéfice du doute. En tous cas, ça ne gène que ceux qui s'en servent, qui sont manifestement beaucoup moins nombreux que chez Firefox.

possibilité d’installer des extensions privées

Oui, enfin si ça implique de les filer à Mozilla avant, ça va un tout petit peu coincer dans les chaumières (enfin, les entreprises surtout). Quand tu te fais suer à créer une extension spécifique pour ta boîte, c'est généralement pour faciliter la vie de tout le monde. Donc potentiellement tu as des mots de passe ou des clefs d'API dedans.

Je me vois mal demander à un client d'installer ça avant de pouvoir le dépanner.

Ceci dit, dans des environnements contrôlés, c'est assez génial. Mais l'intérêt de Teamviewer (et de ses copains), c'est de marcher aussi dans des environnements non-contrôlés.

Est-ce que cela implique que qupzilla est tout aussi mauvais que firefox-avec-extensions-restreintes ?

Je ne sais pas si ça répond à ta question, mais je n'avais jamais entendu parler de Qupzilla avant, ni ne l'avais rencontré sur le PC de quelqu'un.

Il y a 3 acteurs: Mozilla, les utilisateurs, les développeurs.

Je suis un grand naïf, doublé d'un idéaliste. C'est plus fort que moi. Il y a quelques années, j'entendais les tenants d'un Internet (et d'un Web, bisous à Thierry) libre, ouvert à tous, j'y ai cru. Quand on nous a vendu un système dans lequel, enfin, il n'y aurait plus de différence fondamentale entre producteurs et consommateurs, j'ai applaudi. Et ça a marché : de nombreux acteurs sont apparus, souvent dans des garages. Et puis ont pris du galon, ont pignon sur rue, etc.

Alors certes, Mozilla n'a pas commencé dans un garage, ou alors il y a bien longtemps et sous un autre nom. Mais ils se sont largement fait un nom autour de cette idée d'un web participatif. Du coup, cette idée de relation tri-partite, j'adhère moyen. Et même si je ne vais pas lâcher Firefox en tant qu'utilisato-développeur (développo-utilisateur?), je vais quand même commencer à sérieusement regarder ce qui se fait à côté.

Parce que oui, me protéger c'est bien, très bien. Protéger ma tatie qui entrave que dalle aux ordinateurs, c'est encore mieux. Par contre, me protéger contre moi-même, je commence à trouver que ça sonne un peu trop comme les grands discours de plusieurs autres grosses firmes du domaine. Le genre qu'on trouve puantes et nauséabondes céans, et dont les pratiques m’agacent assez régulièrement dans ma vie professionnelle.

Que vous n’ayez pas confiance en Mozilla, c’est votre droit, mais peut-on savoir pourquoi ?

Ne vaut-il pas mieux attendre de voir si Mozilla a vraiment des intentions despotiques avant de les accuser ? L’arbitraire, c’est une accusation facile, tout ce que font les hommes est arbitraire. Ton jugement et le mien sont arbitraires.

Oué, et la volonté du gouvernement français de dresser un listing des juifs dans les années 30, c'était arbitraire aussi. Pas de bol que les nazis soient passés derrière (et oui, j'assume le Godwin là-dessus).

Attendre de voir si tel comportement potentiellement liberticide (ou n'importe-quoi-cide d'ailleurs) va profiter de son potentiel ou pas, c'est un peu crétin. Il y a heureusement des nuances entre boycotter/interdire Mozilla et leur faire une confiance aveugle. Entre les deux, il y a moyen de débattre, de leur dire ce qu'on en pense, de se renseigner sur les alternatives, de mesurer l'impact, etc.

Parce que dans le fond, ton problème, c’est que tu ne les crois pas honnêtes, semble-t-il.

J'ai le même problème avec Oracle, Adobe, Microsoft, Google, Facebook, … : je ne les crois ni honnêtes, ni malhonnêtes. La confiance n'exclut pas la vérification, et si je ne crois pas Mozilla malhonnête, j'ai tendance à regarder d'un œil soupçonneux quiconque met en place un système qui lui permet de l'être plus facilement.

Il fait la vidéo, l'audio et cela sans installer de logiciel. Sinon Mumble, Ekiga, Jitsi ils ont tous leurs défauts (skype aussi) mais au moins tu reprends le controle de tes données…

Et tous ont en commun le problème de ne pas passer certains NATs, sauf à payer de la connectivité pour TURN, ce que ma tatie ne fera pas (puisqu'elle a la même chose gratuitement avec Skype).

Encore une fois, si il y a une alternative libre à Teamviewer, je suis le premier à prendre!

Avant Windows Vista/7 et leur connerie d'UAC (qui son utilité, mais dans ce cas précis ça nous emmerde), UltraVNC en mode SingleClick fonctionnait assez bien : le serveur VNC tourne en mode "inversé" et se connecte à un relai, le client fait de même, et sur un numéro commun ils sont mis en relation par le-dit relai. Ça demandait un peu de boulot de mise en place, mais une fois que c'était fait ça roulait indépendamment de l'infrastructure réseau des deux parties concernées. Pas de problème de NAT. En outre, UltraVNC proposait un transfert de fichier et un chat intégré. Bon, c'était assez vilain graphiquement, il faut bien dire.

J'ai l'impression que les développeurs l'ont un peu abandonné et sont partis faire du non-libre, depuis.

STUN, c'est bien, très bien même. Mais ça ne marche pas à tous les coups, loin s'en faut. En particulier dans le cas des NATs symétriques, pour lesquels ont est généralement obligés de passer par un proxy, genre TURN.

Les gens font ça en priorité parce qu'ils sont contents que quelqu'un s'intéresse à leur vie (oui ça existe, et en masse).

C'est déjà un biais énorme, ça, non?

Ben en fait, si, ça permet d'utiliser BT dans le navigateur. Simplement, pour l'instant, les clients BT basés sur WebTorrent (y compris la version nodejs, si j'ai bien compris) ne savent pas parler aux clients BT classiques. Mais il semble que ce soit prévu.

Après, si le but est de filer un lien web aux gens, le fait de pouvoir fonctionner avec un client BT classique est un peu moins essentiel, non?

Génial. Plus qu'à coupler ça avec WebTorrent (http://webtorrent.io/) et on a un CDN-du-pauvre qui poutre des bébé chats :)

on parle de free software, pas d'open source (pas de majuscules => pas des noms propres donc pas de sens customisé).

Sauf que l'open source a aussi un sens "customisé", cf. OSI. L'absence de majuscules, il me semble que tu la tolères bien sur "free software", non?