Pour la petite question il faut ici définir serveur. Si c'est de serveur Movim, cela devrait se faire de façon totalement transparent, en effet l'intégralité des informations publiées via Movim sont en fait publiés sur le compte XMPP de la personne.
Pour "migrer", il suffit donc de se connecter à un autre "pod" ou un autre client XMPP tel que Salut à Toi, Conversations ou bien d'autres :)
Si il s'agit de changer de serveur XMPP, là c'est plus délicat, le processus étant similaire à changer d'adresse email.
Pour donner une réponse un peu plus précise, oui le service XMPP jappix.com à été transféré sur les serveurs du projet Movim.
On a eu quelques soucis ces dernières semaines avec cette migration, notamment à cause de spammeurs affectant la stabilité du service.
Le serveur XMPP jappix.com a été re-migré vers une machine différente du serveur XMPP movim.eu et porté sur la dernière version stable de Prosody, ce qui semble avoir résolu les problèmes jusqu'ici.
Développer un client iOS demande pas mal de prérequis que je n'ai pas et que je ne compte pas avoir :
- Connaissances en Objective C/Shift
- Un/des device(s) sur différentes versions de iOS pour tester
- Un ordinateur avec macOS + XCode pour développer et packager l'application
- De quoi envoyer l'application sur l'AppStore
La barre est pour le moment trop haute pour proposer un client qui ne sera au final qu'une webview de Safari avec quelques bouts de code autour.
D'ailleurs saches que Movim tourne plus que correctement sur le Safari de iOS et tu peux épingler l'URL sur ta home page pour avoir quasiment la même intégration que tu pourrais avoir avec une "App".
Pour l'ensemble des clients c'est une Webview avec une couche d'intégration pour s'adapter au mieux à chaque système.
Pour la partie bureau c'est du Electron d'ailleurs.
Il y a déjà plein de clients natifs (plus ou moins biens) sur chaque plateformes et le but du projet Movim n'est pas de réécrire un ensemble de clients pour chacun d'entre eux. Je pense que la solution que nous avons choisie est la meilleure pour intégrer toutes les fonctionnalités sur ces plateformes sans (trop) se disperser.
D'ailleurs porter une application, même au sein d'une webview demande du temps. Personnellement sur tout le temps de travail que je passe sur Movim, plus de 25% est alloué aux tests (Safari, IE, Edge, Chrome, Firefox, sur mobile, sur les différents OS…) et au packaging de ces applications pour être sûr que nous pouvons offrir un niveau satisfaisant d'intégration sur toutes ces plateformes. Le diable se cache toujours dans les détails ;)
Normalement l'abonnement à un Groupe devrait se comporter comme tu l'as décrit mais il semble y avoir un bug. Serait il possible d'ouvrir un bug ici https://github.com/movim/movim/issues avec toutes les information pour que je puisse reproduire et corriger le soucis ?
Concernant les publications publiques passés en non publiques, nous avons fait un gros changement concernant la gestion de cette fonctionnalité (qui n'était initialement propagée qu'au pod et qui est maintenant partagée sur l'intégralité du réseau). Ce changement a malheureusement réinitialisé ce statu pour ceux qui avaient basculé les articles en publiques avant son application.
Concernant les deux autres problèmes, je te remercie de ton retour et j'ai réussit à les reproduire. La correction devrait être faite d'ici peu.
Je vois plutôt ça comme une opportunité :) Movim met en commun les Groupes qui ont été explorés par les autres personnes du "pod" mais on pourrait en effet voir apparaître des espèces d'annuaires, ou moteurs de recherches qui exploreront le réseau XMPP. Il y a tout un ensemble d'outils a développer ici.
Je rebondit sur ce message pour dire que nous avons une liste comme ça sur Movim. C'est celle qui est proposée sur cette page https://pod.movim.eu/?account (et sur tous les pods Movim lors de l'étape de création de compte).
D'ailleurs petite précision, n'hésitez pas à utiliser les autres pods, surtout celui aux Pays-Bas qui est installé sur le même serveur que le serveur XMPP (ça se ressent coté performances).
Oui les commentaires sont aussi postés en utilisant des comptes XMPP (il faut donc être connecté et avoir accès au blog de la personne en la rajoutant dans sa liste de contacts).
L'application Android de Movim n'est qu'un container qui lance l'un des Pods déployés dans une WebView.
Pour ce faire j'ai réutilisé la WebView par défaut proposée dans Android qui se trouve être basée sur Chromium depuis la 5.0. Or nous avons besoin de certaines fonctionnalités (comme les Websockets) qui ne sont pas packagées avec le moteur WebKit disponible sur les versions antérieures.
J'ai vu qu'il existait des projets qui permettaient de packager Movim avec un moteur personnalisé mais cela multiplie la taille du paquet par 100 pour au final n'avoir que peu de différences avec le fait d'ouvrir directement Movim dans le navigateur du téléphone (qui peut être Chrome ou Firefox).
Je ne connais pas, hélas, l'ensemble du support de tous les serveurs. Néanmoins je sais que eJabberd, Metronome et OpenFire ont un support plus que correct de ce qui est requit par Movim (surtout sur le plan du support Pubsub). Je n'ai volontairement pas mentionné l'excellent Prosody ici car il manque une fonctionnalité centrale : la persistance des nœuds Pubsub (corrigez moi si je dit une bêtise), c'est le seul point qui nous retient de l'utiliser aujourd'hui.
Donc les serveurs principaux "sur le marché" sont presque tous pleinement compatibles avec Movim. Le soucis c'est de savoir si les instances déployés sont à jour, et ce n'est pas souvent le cas. Et là je ne peux pas faire grand chose à part vous proposer de contacter votre administrateur et de lui demander de mettre à jour son serveur ;)
Car je suis à l'aise avec ce langage, car je suis parvenu à faire assez simplement ce que je souhaitais faire avec.
N'empêche que je suis pleinement conscient de ses défauts mais ça fait déjà 7 ans que je travaille dessus et porter tout le code viendrait à tout recommencer.
À vrais dire depuis l'arrivée des PSR, de Composer et de PHP7 il devient de plus en plus intéressant de rester sur PHP.
Le support serveur est aussi excellent et des projets comme HHVM (et PHP7) amènent des performances très intéressantes, proche de ce qui pourrait se faire avec bien d'autres langages.
Oui l'histoire du support du serveur est toujours un problème.
Movim va automatiquement griser certaines parties de l'interface si celles-ci ne sont pas supportés. Certaines fonctionnalités ne seront juste pas disponibles mais je n'ai pas à ma connaissance de cas où ça couperait la session ou créerait de véritable problème.
Oui la tournure que prend XMPP ces derniers mois et très intéressante.
Telegram est en effet très bon dans ce domaine et j'ai vu beaucoup de libristes l'utiliser (même des gens de LaQuadrature parait-il !). Ce qu'il faut par contre comprendre avec XMPP c'est que tu n'auras pas "un projet" qui couvrira tous les supports, c'est comme le mail : sur ton bureau tu a Geary/Thunderbird et sur ton mobile K9 ou autre.
Sur Android je te conseille donc l'excellent Conversations qui implémente les dernières normes XMPP et est très sympa à utiliser, il est disponible sur Google Play et F-Droid. Pour parler un peu de nous le projet Movim complète également très bien Conversations sur navigateur et un portage "bureau" est également en cours (si tu veux participer, c'est par ici). Par contre nous n'avons pas de fonctionnalité de chiffrement de bout en bout pour le moment (OTR étant très difficile à porter sur notre architecture, mais les autres standards risquent d'être plus simple pour ça).
Les stickers c'est vraiment sympa oui et nous sommes entrain de regarder pour intégrer la fonctionnalité dans Movim. Nous sommes entrain de dialoguer avec quelques personnes pour avoir des sets de stickers exclusifs au sein de Movim ! Nous avons déjà le support des emojis d'ailleurs.
Il est parfaitement possible d'insérer une image au sein d'une discussion sur XMPP , via la XEP XHTML-IM, oui et dans Movim celles-ci seront hébergés sur le serveur web où Movim est déployé (ce qui permet également de les partager avec les autres personnes du Pod).
C'est toujours facile de comparer des pommes à des poires et d'en tirer des conclusions. Comparer Slack (un service-serveur-client) à IRC (un protocole) et à Jabber/XMPP (un protocole) n'est, à mon avis, pas une bonne façon d'initier le débat.
Le souci du "choix" amené par les protocoles décentralisés (et ici il n'y a plus que XMPP (qui est plutôt fédéré en fait), IRC n'est PAS un protocole décentralisé, peut être tout juste acentré) est en effet une chose difficile à surmonter.
La difficulté du choix du serveur que tu mentionne est un faux problème selon moi. Oui il y a une myriade de serveurs XMPP qui ont chacun des fonctionnalités propres et qu'une solution comme Slack à le mérite d'avoir une unité de ses services et clients et donc une bien meilleurs "user expérience".
Mais y'a t'il que Slack ? Et HipChat ? Et Skype ? Et WhatsApp ? Et Telegram ? Et Viber ? Et BlackBerryMessenger ? Et Facebook Messenger ? …
Nous avons en face des dizaines et des dizaines de services non compatibles entre eux mais offrant une intégration sympa avec leurs propres clients.
Pour ce souci je vois deux solutions, du moins pour les serveurs, services et clients utilisant XMPP :
- Je suis convaincu que la mise en place d'un "super-serveur" XMPP centralisé offrant tous les services modernes du protocole ainsi que les clients les implémentant est le meilleur moyen d'amener du monde vers ce protocole. Oui la plupart des gens s'en foutent, ils veulent un service qui "juste marche" et qu'on leur indique la liste des clients compatibles utilisables avec celui-ci (même les libristes), même si c'est centralisé. C'est ce que j'ai vu avec mon projet (Movim) ou chez Jappix, nos logiciels sont parfaitement déployables sur des serveurs auto-hébergés mais la quasi-totalité des utilisateurs sont sur les quelques "serveurs officiels" que nous offrons. Et ne nous voilons pas la face, je suis aussi sur IRC et à part Freenode et OFTC y'a pas grand monde qui est sur son propre serveur.
- Un seul mot : in-té-gra-tion. C'est de là que vient l'"user experience". Un service ou un client ayant des fonctionnalités bien intégrées sera toujours plus sympa à utiliser qu'un autre offrant juste une liste de fonctionnalités. Ce problème est aussi très présent parmi les clients XMPP. Gajim est "sympa" mais clairement pas utilisable par le grand public, Pidgin l'est peut être un peu plus mais offre une interface qui n'a presque pas changée en 10 (15 ?) ans. L'exception est peut être Empathy qui est bien intégré à Gnome mais est très léger en fonctionnalités.
Donc je suis d'accord avec toi, arrêtons de balancer de la fonctionnalité et commençons à intégrer tout ça proprement dans de belles interfaces et avec les serveurs existants. Sur Android le client Conversations (https://play.google.com/store/apps/details?id=eu.siacs.conversations&hl=fr) fait déjà un super travail en ce sens mais il manque toujours un client bureau sympa pour XMPP.
C'est exactement ça ;)
Sachant que sur Movim il y a aussi la possibilité de faire le truc dans les deux sens, de générer une page HTML simple + son flux Atom à partir d'un flux Pubsub (petit exemple https://nl.movim.eu/?q=grouppublic&s=blabla.movim.eu&n=random).
Je passe sur la création de compte, la connexion qui lève une alerte pour cause de certificat invalide, et l'ajout de contacts (qui contrairement à Telegram qui les retrouve automatiquement, doit être fait manuellement au cas par cas) vu que théoriquement ce n'est pas rencontré à chaque utilisation.
L'histoire des certificats c'est le même soucis que pour les pages web, si le certif est pas signé le client te retourne cette erreur.
Pour l'ajout de contacts, qu'est ce que tu veux que je te dise, Telegram, comme WhatsApp, LINE, Viber ou d'autres récupère l'intégralité de ta liste de contact :)
Contacts
Telegram uses phone numbers as unique identifiers, so that it is easy for you to switch from other messaging apps (SMS, WhatsApp, etc.) and retain your social graph. We ask your permission before syncing your contacts.
We store your contacts in order to notify you as soon as one of your contacts signs up for Telegram and to properly display names in notifications. We only need the number and name (first and last) for this to work and store no other data about your contacts.
Edhelas: thanks for list of XEPs. I think you are missing the point: the current typical dialect of XMPP revolves around 1:1 IMs and XEP-45 MUCs. If I am talking in a MUC with JID foo@bar.com and the server(s) at bar.com go down, i lose the whole conversation - including the conversation history if it's implementing XEP-313. This is a major design flaw: conversations should be owned by the people participating in them; not any single party or vendor. Plus with a decentralised approach you get offline operation and merging history after netsplits for free.
Sur l'idée d'avoir des MUC décentralisés je te l'accorde c'est bien sympa et en effet sur XMPP c'est pas pensé comme ça. Mais encore une fois ce sont des choses qui peuvent être imaginés et étendues sans soucis.
Concernant le fait de perdre l'historique si le serveur tombe, ce n'est pas totalement vrais. MAM permet de garder un historique sur notre propre serveur, même si le serveur distant n'est plus disponible.
You could implement these semantics on top of XMPP, which is what FMUC and BuddyCloud do - but you are effectively creating a whole new dialect (with very limited compatible server and client implementations, increasing fragmentation) just using XMPP as a basic message passing transport. So we decided to skip XMPP altogether and just use plain HTTP API with a higher set of baseline functionality (whilst still being extensible), rather than arbitrarily build on XMPP given the end result wouldn't be compatible with normal MUCs and XMPP IMs anyway. (We also only discovered the BC and FMUC XEPs after designing and launching Matrix).
C'est ici que je ne suis pas d'accord avec toi. XMPP (Extensible Messaging and Presence Protocol) n'est pas/plus Jabber. Aujourd'hui le "cœur Jabber" n'est plus qu'une petite partie du protocole, mais je te l'accorde ici aussi, oui ça a été construit "par dessus" donc il y a encore l'état d'esprit du protocole original.
Par ailleurs, XMPP n'a pas vocation a être implémenté dans sa totalité par les clients et serveurs, libre à vous de choisir/casser ce qui vous plait, ou pas, dans XMPP. Mais le fait de garder une architecture commune permet de limiter la difficulté quand il s'agira de construire les "ponts" entre les réseaux.
I'm sorry that the existence of Matrix seems to upset some people who have successfully invested in XMPP. If XMPP works for you, then we're very happy and we're not stopping you. And we'll provide an XMPP s2s to Matrix bridge to let you enjoy Matrix too.
In terms of your concerns on HTTP long polling: with HTTP/2 it's really not that bad and only slightly worse than websockets. And anyway we only mandate plain HTTP as a baseline protocol for compatibility - if you want to put JSON or capn proto over WS or COAP or MQTT or whatever than go for it :)
HTTP/2 est encore très loin d'être déployé et utilisé partout, mais en effet les avancées faites vont considérablement réduire la signalisation et le temps de latence lors de l'échange des données.
Dans mon projet j'ai fait le chemin inverse, je suis partit du long polling HTTP pour aller vers les WebSockets, puis sur du Socket simple. Pensez aussi aux mobiles, le long-polling implique systématiquement un "ping" pour savoir si la ressource est encore disponible, le mobile/navigateur risque donc d'envoyer des centaines/milliers de requêtes quotidiennement pour simplement garder une connexion ouverte sur le serveur.
Edhelas: this is the third time we've had the same discussion - if it still doesn't make sense please tell me what is confusing so we don't get stuck in groundhog day…
Oui nous en avons déjà parlé mais sans avoir le temps de creuser exactement les points où nous n'étions pas d'accord. Je sais que je donne des fois l'impression d'être quelqu'un de têtu mais je trouve dommage d'avoir un explosion de protocoles d'IM (tant libre que propriétaires) et de passer notre temps a écrire des librairies de transports alors qu'il existe déjà tout ce qu'il faut comme standard dans la nature.
Ne pas être d'accord ou essayer de penser "hors de la boite" est super, c'est d'ailleurs l'essence même de ce que fait le logiciel libre. Mais ce qui caractérise aussi le libre c'est l'utilisation des standards. On a réussit à se mettre d'accord sur beaucoup d'entre elles, mais ça bloque pour l'IM/social et ça fait maintenant 5 ans que je pense que XMPP a la possibilité de devenir une norme universelle au même niveau que IMAP/SMTP/POP ont fait ce qu'on appelle aujourd'hui "l'email".
D'ailleurs ce qui est rigolo c'est qu'une fois qu'une norme arrive a émerger, l'innovation tend à se faire finalement plus sur les clients avec le temps. IMAP/SMTP/POP ça n'a pas fondamentalement changé depuis des années, pourtant on a eu Outlook, Thunderbird, les webmails, les clients mobiles avec plein d'interfaces… pareil pour le Web, pendant des années on s'est tapé dessus pour normaliser tout ça et au final, une fois que tout le monde s'est mis d'accord (HTML5…) on a vu ce que ça a donné : des applications web dynamiques, des systèmes d'exploitation (FirefoxOS), des intégrations poussées (notification, visio-conférence…) sur toutes les plateformes inimaginables.
Donc oui les normes c'est chiant, mais on fait avec. Je vais te faire une confidence, je n'aime pas particulièrement certains trucs dans XMPP, j'ai déjà eu des échanges assez mouvementés avec la XSF (comme sur certains problèmes relatifs à PubSub http://wiki.xmpp.org/web/PubSubIssues ou sur les Bookmarks http://mail.jabber.org/pipermail/standards/2014-April/028833.html), mais bon je fais avec. Mais je préfère prendre du temps pour discuter, proposer des corrections et faire évoluer tout ça. Et finalement le temps que je vais prendre pour "casser des choses" dans XMPP sera tout autant de temps gagné pour les autres projets qui souhaitent intégrer ces fonctionnalités/changements.
C'est une architecture distribuée dans laquelle les données sont persistées, n'importe qui peut déployer son serveur et garder le contrôle de ses données.
Je chipote un peu mais c'est également le cas de XMPP.
historique par défaut
http://xmpp.org/extensions/xep-0313.html XEP-0313: Message Archive Management, déjà implémenté sur de nombreux serveurs et commence à être implémenté dans de nombreux clients
XMPP supporte l'authentification SASL, le chiffrement est maintenant obligatoire entre les serveurs (voir l'initiative https://xmpp.net/) et très souvent sur les clients (via StartTLS). Pour du chiffrement bout en bout des normes comme OTR sont maintenant largement déployés sur les clients XMPP (même si je trouve ça pas très très propre sur le coté protocolaire).
Je me suis penché sur Matrix il y a quelques semaines, car je me suis demandé qu'est ce qui pouvait pousser un groupe de développeurs à vouloir réinventer un nouveau protocole pour une énième fois alors que XMPP semble offrir tout ce qu'il faut.
Mais bon j'ai bien eu l'impression qu'il s'agissait plus d'une envie de repartir sur une nouvelle base au lieu de prendre le chemin de la difficulté et d'avoir à travailler avec la XSF pour améliorer/compléter XMPP.
Si c'est l'interconnexion avec le Web qui les embêtes :
Oui, lire des normes c'est compliqué, et on est pas toujours d'accord avec ce qui est écrit. Mais quand le protocole est utilisé par des dizaines de serveurs utilisés par des universités, entreprises, multinationales, gouvernements, particulier; des centaines de clients sur toutes les plateformes et a plus de 15 ans d'ancienneté avec plusieurs RFC à l'IETF c'est plus compliqué de mettre tout le monde d'accord :) Pour le reste j'ai déjà écrit un commentaire là dessus il y a quelques jours http://linuxfr.org/nodes/105862/comments/1606599.
Le dernier point que je voulais aborder concerne l'une des spécificités de Matrix : fonctionner en HTTP.
Je pense que cette décision est une grave erreur, pourquoi ? Car HTTP amène un overhead énorme (oui c'est considérable quand il s'agit de gérer des listes de 400 contacts avec plusieurs dizaines de connections, des salons et des messages dans tous les sens). De plus cantonner un protocole "social/IM" au Web uniquement a une conséquence terrible : c'est compliqué de faire autre chose que du Web.
Le Web n'est qu'une petite partie d'Internet. Donc quand on base un protocole sur des technologies Web (HTTP en l'occurence) c'est plus difficile d'en sortir.
Getting live state
This will block waiting for an incoming event, timing out after several seconds. Even if there are no new events (as in the example above), there will be some pagination stream response keys. … If it has been a long period of inactivity, there may be LOTS of events waiting for the user. In this case, you may wish to get all state instead and then resume getting live state from a newer end token.
C'est ce qu'on appelle plus communément du long-polling, j'ouvre une requête HTTP, le serveur me répond quand il a quelque-chose à dire et j'en renvoie une autre derrière. Croyez moi sur des grosses charges ça ne tiens pas. Si vous voulez avoir du temps réel faite du socket (pure TCP ou WebSocket), encore une fois vous vous compliquez la vie et vous allez compliquer la vie des clients qui souhaiteraient faire du "vrais" temps réel et qui devront le simuler en utilisant des librairies comme Curl pour recréer un système évènementiel derrière.
J'ai l'impression que le débat va plutôt tourner autour de Matrix.
Néanmoins je trouve ça dommage de voir un énième protocole de messagerie apparaitre… comme si on en avait pas assez.
Pour répondre globalement à ce post je dirais que ces grosses boites ont souhaités se passer de XMPP pour plusieurs choses :
- Les standards c'est chiants, et comme tu le dis si bien, si tu contrôle la chaine, pourquoi s'emmerder à vouloir être compatible avec les autres ? Quand tu es un grand acteur (comme Google) et que tu es imposant sur un marché (le mail avec Gmail), mais pas assez pour dominer, tu te plie aux standards et tu reste compatible. Se passer de XMPP casse des choses mais pas tant que ça en fait vu la "faible" utilisation de celui-ci atour de ces acteurs.
- XMPP est utilisé à 10% de sa capacité, voir moins. À combien de personnes, même dans la communauté du libre, je dois expliquer que non XMPP n'est pas uniquement pour le chat mais peut faire bien plus? On a plus de 300 extensions maintenant mais certaines d'entre elles sont a peine implémentés (Pubsub, sortit en 2008, jamais implémenté en totalité sur un serveur, et coté client…)
- Elles ont pas "compris" l'intérêt de XMPP, parcequ'elles se sont cantonnés à faire du chat par dessus, comme 80% des autres projets. Mais je pense que ce soucis vient aussi de la XSF qui doit activement communiquer sur les possibilités offertes par XMPP.
Avant de critiquer les multinationales parcequ'elles font des chôses dans leurs intérêts, regardons nous, libristes. On a attendu que Mozilla arrive pour faire du Web l'un des domaines les plus innovants de l'informatique moderne. Coté réseaux sociaux on a des dizaines de projets (StatusNet, Pump.io, Diaspora, Matrix…) qui sont certes très intéressants mais qui ne règlent pas le "problème" général. Quand Mozilla a bossé sur Firefox, ils ne voulaient pas créer UN Web pour eux, ils voulaient améliorer LE Web dans son ensemble.
Donc oui XMPP est critiquable, oui le XML sépabo, oui c'est chiant d'écrire une XEP pour dire comment gérer la sauvegarde d'un message sur un serveur mais c'est nécessaire.
Quand Google a voulu se mettre à XMPP ils ont tenté la fédération et ont proposé un client simple (Google Talk) et qui était dispo sur pas mal de plateformes à l'époque. Ils ont également travaillé à la "standardisation" (à leur manière certes) et au développement de la visio sur le protocole, ce qui nous a apporté Jingle. As t'on vu une révolution depuis ? Peut-on facilement faire de la visio sur nos machines de libristes ? Non. La norme est là pourtant. Et pourtant Pidgin n'a pas bougé, Gajim a une implémentation plus que buggé, Empathy pareil, les seuls qui se bougent sont Jitsi.
Résultat des courses, c'est grâce au Web qu'on a de la visio pas trop pourrit avec WebRTC, grâce à qui ? Mozilla et Google (principalement).
Donc avant d'aller voir pourquoi ça marche pas chez les autres améliorons nos clients, Pidgin ne semble pas bouger depuis plusieurs années, pourtant c'est pas compliqué il suffit juste d'implémenter la norme. Pour les nouveaux projets (comme Empathy) ils se cantonne au strict minimum (liste de contact, vcard et présence).
Je bosse sur le protocole XMPP depuis plus de 5 ans déjà et mon principal problème n'est pas d'écrire des normes ni d'essayer de l'implémenter dans mon client (Movim). Mon problème c'est de voir que je suis le seul (avec Jappix, SàT et quelques autres clients) à vouloir aller de l'avant, et c'est usant, très usant. J'ai créé un petit tableau récapitulatif du support de la normes sur les principaux clients ici https://pod.movim.eu/?q=about#caps_widget , il y a encore de très grosses lacunes chez pas mal de clients.
Donc avant de vouloir réinventer un énième protocole "social" essayez d'améliorer l'existant. XMPP offre, selon moi, les ingrédients pour créer une petite révolutions dans le domaine des échanges sociaux sur le Internet.
Pour vous donner quelques idées :
- Sur le papier on peut associer WebRTC et Jingle, Jappix l'a fait et semble être le seul à le faire assez bien. WebRTC colle au niveau protocolaire avec les solutions de visio "classiques" (hors du Web) pourquoi ne travaillons nous pas à rendre compatible Pidgin, Gajim… avec WebRTC ? Les normes sont là, il "suffit" juste de les implémenter.
- Sur XMPP on peut sauvegarder les bookmarks de nos clients (salons de discussions…), la norme existe… et pourtant. Pidgin sauvegarde ses bookmarks en local, Gajim fait à sa façon… bref même un truc aussi simple n'est pas fini. Du coup Goffi, moi et quelques autres motivés allons réécrire et simplifier la norme (http://xmpp.org/extensions/xep-0048.html) pour, espérons le, faciliter l'implémentation dans ces clients.
- Les XEP Vcard4 et Avatar permettent de "pusher" les informations entre les contacts, qu'est ce qui est encore majoritairement implémentés ? vcard-temp, XEP historique (http://xmpp.org/extensions/xep-0054.html) sortie en 2008 et qui fonctionne en pulling (il faut requêter une à une les vcard de vos contacts). J'ai implémenté Vcard4 tout seul en une après-midi sans grande difficulté, le nombre de projets qui ont fait de même se comptent sur les doigts d'une main. Petit détail, il n'y a rien à faire coté serveur (enfin il faut qu'ils supportent PEP, ce qui est déjà fait pour la majorité d'entre eux).
Donc pour résumer, la solution on l'a sous nos yeux, il faut juste l'implémenter et rendre compatible nos projets existants.
Je suis heureux de voir que ce long travail porte enfin ses fruits et que nous allons enfin avoir une solution Pubsub générique et facilement adaptable aux serveurs XMPP du moment.
De la même façon nous allons pouvoir, pour la première fois avoir une pleine compatibilité avec des clients XMPP sur la gestion de flux et nous allons donc pouvoir faire du "réseautage social" :
- En temps réel (alors que de nombreux autres protocoles sont construit sur du polling HTTP)
- Multi-client et multi-serveur
- Extensible pour transporter de nombreuses normes (je me concentre sur Atom pour le moment)
- Décentralisé
- Hors du Web, car selon moi un réseau social n'a rien à faire sur le Web, c'est un réseau avant tout. Le Web n'est qu'une interface à celui-ci (au même niveau que le réseau mail, chat ou de partage de fichier).
En tous cas, Movim est prêt à accueillir les publications de SàT et je serais heureux de corriger les petits défauts pour que nous soyons pleinement compatibles :)
[^] # Re: déplacement d'un profil
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 3.
Merci encore :)
Pour la petite question il faut ici définir serveur. Si c'est de serveur Movim, cela devrait se faire de façon totalement transparent, en effet l'intégralité des informations publiées via Movim sont en fait publiés sur le compte XMPP de la personne.
Pour "migrer", il suffit donc de se connecter à un autre "pod" ou un autre client XMPP tel que Salut à Toi, Conversations ou bien d'autres :)
Si il s'agit de changer de serveur XMPP, là c'est plus délicat, le processus étant similaire à changer d'adresse email.
[^] # Re: demande à movim
Posté par edhelas (site web personnel) . En réponse au message Ou est passé Jappix ? Remplacé par Movim ?. Évalué à 2.
Pour donner une réponse un peu plus précise, oui le service XMPP jappix.com à été transféré sur les serveurs du projet Movim.
On a eu quelques soucis ces dernières semaines avec cette migration, notamment à cause de spammeurs affectant la stabilité du service.
Le serveur XMPP jappix.com a été re-migré vers une machine différente du serveur XMPP movim.eu et porté sur la dernière version stable de Prosody, ce qui semble avoir résolu les problèmes jusqu'ici.
Si vous avez des questions, n'hésitez pas à venir les poser sur le salon XMPP du projet :)
[^] # Re: Client mobile et desktop
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.10 - Holmes. Évalué à 5.
Développer un client iOS demande pas mal de prérequis que je n'ai pas et que je ne compte pas avoir :
- Connaissances en Objective C/Shift
- Un/des device(s) sur différentes versions de iOS pour tester
- Un ordinateur avec macOS + XCode pour développer et packager l'application
- De quoi envoyer l'application sur l'AppStore
La barre est pour le moment trop haute pour proposer un client qui ne sera au final qu'une webview de Safari avec quelques bouts de code autour.
D'ailleurs saches que Movim tourne plus que correctement sur le Safari de iOS et tu peux épingler l'URL sur ta home page pour avoir quasiment la même intégration que tu pourrais avoir avec une "App".
[^] # Re: Client mobile et desktop
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.10 - Holmes. Évalué à 4.
Pour l'ensemble des clients c'est une Webview avec une couche d'intégration pour s'adapter au mieux à chaque système.
Pour la partie bureau c'est du Electron d'ailleurs.
Il y a déjà plein de clients natifs (plus ou moins biens) sur chaque plateformes et le but du projet Movim n'est pas de réécrire un ensemble de clients pour chacun d'entre eux. Je pense que la solution que nous avons choisie est la meilleure pour intégrer toutes les fonctionnalités sur ces plateformes sans (trop) se disperser.
D'ailleurs porter une application, même au sein d'une webview demande du temps. Personnellement sur tout le temps de travail que je passe sur Movim, plus de 25% est alloué aux tests (Safari, IE, Edge, Chrome, Firefox, sur mobile, sur les différents OS…) et au packaging de ces applications pour être sûr que nous pouvons offrir un niveau satisfaisant d'intégration sur toutes ces plateformes. Le diable se cache toujours dans les détails ;)
[^] # Re: Ça marche sur it.movim.eu ?
Posté par edhelas (site web personnel) . En réponse au journal Movim Groups réinvente les flux d'actualité . Évalué à 1.
Une petite réponse tardive à ton soucis.
Normalement l'abonnement à un Groupe devrait se comporter comme tu l'as décrit mais il semble y avoir un bug. Serait il possible d'ouvrir un bug ici https://github.com/movim/movim/issues avec toutes les information pour que je puisse reproduire et corriger le soucis ?
Merci :)
[^] # Re: Bogues dans la fonction de blog
Posté par edhelas (site web personnel) . En réponse au journal Movim Groups réinvente les flux d'actualité . Évalué à 2.
Bonjour et merci de tes retours !
Concernant les publications publiques passés en non publiques, nous avons fait un gros changement concernant la gestion de cette fonctionnalité (qui n'était initialement propagée qu'au pod et qui est maintenant partagée sur l'intégralité du réseau). Ce changement a malheureusement réinitialisé ce statu pour ceux qui avaient basculé les articles en publiques avant son application.
Concernant les deux autres problèmes, je te remercie de ton retour et j'ai réussit à les reproduire. La correction devrait être faite d'ici peu.
[^] # Re: Annuaire ou outil de recherche pubsub
Posté par edhelas (site web personnel) . En réponse au journal Movim Groups réinvente les flux d'actualité . Évalué à 1.
Je vois plutôt ça comme une opportunité :) Movim met en commun les Groupes qui ont été explorés par les autres personnes du "pod" mais on pourrait en effet voir apparaître des espèces d'annuaires, ou moteurs de recherches qui exploreront le réseau XMPP. Il y a tout un ensemble d'outils a développer ici.
[^] # Re: URL
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 1.
Il y a toujours moyen de les réécrires, que proposes tu ?
[^] # Re: si votre serveur XMPP le prend en charge
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 4.
Je rebondit sur ce message pour dire que nous avons une liste comme ça sur Movim. C'est celle qui est proposée sur cette page https://pod.movim.eu/?account (et sur tous les pods Movim lors de l'étape de création de compte).
D'ailleurs petite précision, n'hésitez pas à utiliser les autres pods, surtout celui aux Pays-Bas qui est installé sur le même serveur que le serveur XMPP (ça se ressent coté performances).
[^] # Re: Blog et commentaire
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 4.
Oui les commentaires sont aussi postés en utilisant des comptes XMPP (il faut donc être connecté et avoir accès au blog de la personne en la rajoutant dans sa liste de contacts).
Pour le petit bug, je l'ai rajouté il y a quelques jours sur Github ici https://github.com/movim/movim/issues/109 :)
[^] # Re: Lollipop minimum
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 7.
L'application Android de Movim n'est qu'un container qui lance l'un des Pods déployés dans une WebView.
Pour ce faire j'ai réutilisé la WebView par défaut proposée dans Android qui se trouve être basée sur Chromium depuis la 5.0. Or nous avons besoin de certaines fonctionnalités (comme les Websockets) qui ne sont pas packagées avec le moteur WebKit disponible sur les versions antérieures.
J'ai vu qu'il existait des projets qui permettaient de packager Movim avec un moteur personnalisé mais cela multiplie la taille du paquet par 100 pour au final n'avoir que peu de différences avec le fait d'ouvrir directement Movim dans le navigateur du téléphone (qui peut être Chrome ou Firefox).
[^] # Re: si votre serveur XMPP le prend en charge
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 3.
Je ne connais pas, hélas, l'ensemble du support de tous les serveurs. Néanmoins je sais que eJabberd, Metronome et OpenFire ont un support plus que correct de ce qui est requit par Movim (surtout sur le plan du support Pubsub). Je n'ai volontairement pas mentionné l'excellent Prosody ici car il manque une fonctionnalité centrale : la persistance des nœuds Pubsub (corrigez moi si je dit une bêtise), c'est le seul point qui nous retient de l'utiliser aujourd'hui.
Donc les serveurs principaux "sur le marché" sont presque tous pleinement compatibles avec Movim. Le soucis c'est de savoir si les instances déployés sont à jour, et ce n'est pas souvent le cas. Et là je ne peux pas faire grand chose à part vous proposer de contacter votre administrateur et de lui demander de mettre à jour son serveur ;)
[^] # Re: Pourquoi Php?
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 10.
Oui pourquoi PHP tiens ?
Car je suis à l'aise avec ce langage, car je suis parvenu à faire assez simplement ce que je souhaitais faire avec.
N'empêche que je suis pleinement conscient de ses défauts mais ça fait déjà 7 ans que je travaille dessus et porter tout le code viendrait à tout recommencer.
À vrais dire depuis l'arrivée des PSR, de Composer et de PHP7 il devient de plus en plus intéressant de rester sur PHP.
Le support serveur est aussi excellent et des projets comme HHVM (et PHP7) amènent des performances très intéressantes, proche de ce qui pourrait se faire avec bien d'autres langages.
[^] # Re: XEP...
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.9 - Tchouri. Évalué à 4.
Oui l'histoire du support du serveur est toujours un problème.
Movim va automatiquement griser certaines parties de l'interface si celles-ci ne sont pas supportés. Certaines fonctionnalités ne seront juste pas disponibles mais je n'ai pas à ma connaissance de cas où ça couperait la session ou créerait de véritable problème.
[^] # Re: Ouah!
Posté par edhelas (site web personnel) . En réponse à la dépêche XMPP à fond !. Évalué à 3.
Oui la tournure que prend XMPP ces derniers mois et très intéressante.
Telegram est en effet très bon dans ce domaine et j'ai vu beaucoup de libristes l'utiliser (même des gens de LaQuadrature parait-il !). Ce qu'il faut par contre comprendre avec XMPP c'est que tu n'auras pas "un projet" qui couvrira tous les supports, c'est comme le mail : sur ton bureau tu a Geary/Thunderbird et sur ton mobile K9 ou autre.
Sur Android je te conseille donc l'excellent Conversations qui implémente les dernières normes XMPP et est très sympa à utiliser, il est disponible sur Google Play et F-Droid. Pour parler un peu de nous le projet Movim complète également très bien Conversations sur navigateur et un portage "bureau" est également en cours (si tu veux participer, c'est par ici). Par contre nous n'avons pas de fonctionnalité de chiffrement de bout en bout pour le moment (OTR étant très difficile à porter sur notre architecture, mais les autres standards risquent d'être plus simple pour ça).
Les stickers c'est vraiment sympa oui et nous sommes entrain de regarder pour intégrer la fonctionnalité dans Movim. Nous sommes entrain de dialoguer avec quelques personnes pour avoir des sets de stickers exclusifs au sein de Movim ! Nous avons déjà le support des emojis d'ailleurs.
Il est parfaitement possible d'insérer une image au sein d'une discussion sur XMPP , via la XEP XHTML-IM, oui et dans Movim celles-ci seront hébergés sur le serveur web où Movim est déployé (ce qui permet également de les partager avec les autres personnes du Pod).
Si tu as d'autres questions n'hésites pas !
# Attention à ne pas tout mélanger
Posté par edhelas (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à 10.
C'est toujours facile de comparer des pommes à des poires et d'en tirer des conclusions. Comparer Slack (un service-serveur-client) à IRC (un protocole) et à Jabber/XMPP (un protocole) n'est, à mon avis, pas une bonne façon d'initier le débat.
Le souci du "choix" amené par les protocoles décentralisés (et ici il n'y a plus que XMPP (qui est plutôt fédéré en fait), IRC n'est PAS un protocole décentralisé, peut être tout juste acentré) est en effet une chose difficile à surmonter.
La difficulté du choix du serveur que tu mentionne est un faux problème selon moi. Oui il y a une myriade de serveurs XMPP qui ont chacun des fonctionnalités propres et qu'une solution comme Slack à le mérite d'avoir une unité de ses services et clients et donc une bien meilleurs "user expérience".
Mais y'a t'il que Slack ? Et HipChat ? Et Skype ? Et WhatsApp ? Et Telegram ? Et Viber ? Et BlackBerryMessenger ? Et Facebook Messenger ? …
Nous avons en face des dizaines et des dizaines de services non compatibles entre eux mais offrant une intégration sympa avec leurs propres clients.
Pour ce souci je vois deux solutions, du moins pour les serveurs, services et clients utilisant XMPP :
- Je suis convaincu que la mise en place d'un "super-serveur" XMPP centralisé offrant tous les services modernes du protocole ainsi que les clients les implémentant est le meilleur moyen d'amener du monde vers ce protocole. Oui la plupart des gens s'en foutent, ils veulent un service qui "juste marche" et qu'on leur indique la liste des clients compatibles utilisables avec celui-ci (même les libristes), même si c'est centralisé. C'est ce que j'ai vu avec mon projet (Movim) ou chez Jappix, nos logiciels sont parfaitement déployables sur des serveurs auto-hébergés mais la quasi-totalité des utilisateurs sont sur les quelques "serveurs officiels" que nous offrons. Et ne nous voilons pas la face, je suis aussi sur IRC et à part Freenode et OFTC y'a pas grand monde qui est sur son propre serveur.
- Un seul mot : in-té-gra-tion. C'est de là que vient l'"user experience". Un service ou un client ayant des fonctionnalités bien intégrées sera toujours plus sympa à utiliser qu'un autre offrant juste une liste de fonctionnalités. Ce problème est aussi très présent parmi les clients XMPP. Gajim est "sympa" mais clairement pas utilisable par le grand public, Pidgin l'est peut être un peu plus mais offre une interface qui n'a presque pas changée en 10 (15 ?) ans. L'exception est peut être Empathy qui est bien intégré à Gnome mais est très léger en fonctionnalités.
Donc je suis d'accord avec toi, arrêtons de balancer de la fonctionnalité et commençons à intégrer tout ça proprement dans de belles interfaces et avec les serveurs existants. Sur Android le client Conversations (https://play.google.com/store/apps/details?id=eu.siacs.conversations&hl=fr) fait déjà un super travail en ce sens mais il manque toujours un client bureau sympa pour XMPP.
[^] # Re: Intelligent ça...
Posté par edhelas (site web personnel) . En réponse à la dépêche Libervia/Salut à Toi : campagne pour une version Android et de bureau. Évalué à 0.
Tout comme moi.
[^] # Re: Movim
Posté par edhelas (site web personnel) . En réponse au journal Parlons XMPP - épisode 8 - PubSub et PEP. Évalué à 2.
C'est exactement ça ;)
Sachant que sur Movim il y a aussi la possibilité de faire le truc dans les deux sens, de générer une page HTML simple + son flux Atom à partir d'un flux Pubsub (petit exemple https://nl.movim.eu/?q=grouppublic&s=blabla.movim.eu&n=random).
[^] # Re: XMPP
Posté par edhelas (site web personnel) . En réponse au journal Telegram Desktop en Français. Évalué à 1.
L'histoire des certificats c'est le même soucis que pour les pages web, si le certif est pas signé le client te retourne cette erreur.
Pour l'ajout de contacts, qu'est ce que tu veux que je te dise, Telegram, comme WhatsApp, LINE, Viber ou d'autres récupère l'intégralité de ta liste de contact :)
D'après https://telegram.org/privacy
Pour les soucis relatifs à Beem, ce n'est pas XMPP qui est à blammer, mais les clients et en effet je trouve Beem pas terrible.
Je te conseille Conversations (https://play.google.com/store/apps/details?id=eu.siacs.conversations) ou Xabber (https://play.google.com/store/apps/details?id=com.xabber.android), les deux sont également disponible sur F-Droid je le crois.
[^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?
Posté par edhelas (site web personnel) . En réponse au journal Qui veux débattre Messagerie Instantané au Jardin Entropique . Évalué à 1.
Sur l'idée d'avoir des MUC décentralisés je te l'accorde c'est bien sympa et en effet sur XMPP c'est pas pensé comme ça. Mais encore une fois ce sont des choses qui peuvent être imaginés et étendues sans soucis.
Concernant le fait de perdre l'historique si le serveur tombe, ce n'est pas totalement vrais. MAM permet de garder un historique sur notre propre serveur, même si le serveur distant n'est plus disponible.
C'est ici que je ne suis pas d'accord avec toi. XMPP (Extensible Messaging and Presence Protocol) n'est pas/plus Jabber. Aujourd'hui le "cœur Jabber" n'est plus qu'une petite partie du protocole, mais je te l'accorde ici aussi, oui ça a été construit "par dessus" donc il y a encore l'état d'esprit du protocole original.
Par ailleurs, XMPP n'a pas vocation a être implémenté dans sa totalité par les clients et serveurs, libre à vous de choisir/casser ce qui vous plait, ou pas, dans XMPP. Mais le fait de garder une architecture commune permet de limiter la difficulté quand il s'agira de construire les "ponts" entre les réseaux.
Et je pense qu'il y aura également des transports XMPP vers le réseau Matrix :) Ce n'est pas la première fois qu'on essayera de créer un pont en utilisant une interface Web, je viens de packager 2 librairies (pour le réseau Skype et QQ) qui passent par une interface Web pour interagir avec leurs réseaux respectifs (voir http://edhelas.movim.eu/blog/?post/2015/06/06/Packaging%2C-d%C3%A9ploiement-et-int%C3%A9gration-de-nouveaux-transports-XMPP) .
HTTP/2 est encore très loin d'être déployé et utilisé partout, mais en effet les avancées faites vont considérablement réduire la signalisation et le temps de latence lors de l'échange des données.
Dans mon projet j'ai fait le chemin inverse, je suis partit du long polling HTTP pour aller vers les WebSockets, puis sur du Socket simple. Pensez aussi aux mobiles, le long-polling implique systématiquement un "ping" pour savoir si la ressource est encore disponible, le mobile/navigateur risque donc d'envoyer des centaines/milliers de requêtes quotidiennement pour simplement garder une connexion ouverte sur le serveur.
Oui nous en avons déjà parlé mais sans avoir le temps de creuser exactement les points où nous n'étions pas d'accord. Je sais que je donne des fois l'impression d'être quelqu'un de têtu mais je trouve dommage d'avoir un explosion de protocoles d'IM (tant libre que propriétaires) et de passer notre temps a écrire des librairies de transports alors qu'il existe déjà tout ce qu'il faut comme standard dans la nature.
Ne pas être d'accord ou essayer de penser "hors de la boite" est super, c'est d'ailleurs l'essence même de ce que fait le logiciel libre. Mais ce qui caractérise aussi le libre c'est l'utilisation des standards. On a réussit à se mettre d'accord sur beaucoup d'entre elles, mais ça bloque pour l'IM/social et ça fait maintenant 5 ans que je pense que XMPP a la possibilité de devenir une norme universelle au même niveau que IMAP/SMTP/POP ont fait ce qu'on appelle aujourd'hui "l'email".
D'ailleurs ce qui est rigolo c'est qu'une fois qu'une norme arrive a émerger, l'innovation tend à se faire finalement plus sur les clients avec le temps. IMAP/SMTP/POP ça n'a pas fondamentalement changé depuis des années, pourtant on a eu Outlook, Thunderbird, les webmails, les clients mobiles avec plein d'interfaces… pareil pour le Web, pendant des années on s'est tapé dessus pour normaliser tout ça et au final, une fois que tout le monde s'est mis d'accord (HTML5…) on a vu ce que ça a donné : des applications web dynamiques, des systèmes d'exploitation (FirefoxOS), des intégrations poussées (notification, visio-conférence…) sur toutes les plateformes inimaginables.
Donc oui les normes c'est chiant, mais on fait avec. Je vais te faire une confidence, je n'aime pas particulièrement certains trucs dans XMPP, j'ai déjà eu des échanges assez mouvementés avec la XSF (comme sur certains problèmes relatifs à PubSub http://wiki.xmpp.org/web/PubSubIssues ou sur les Bookmarks http://mail.jabber.org/pipermail/standards/2014-April/028833.html), mais bon je fais avec. Mais je préfère prendre du temps pour discuter, proposer des corrections et faire évoluer tout ça. Et finalement le temps que je vais prendre pour "casser des choses" dans XMPP sera tout autant de temps gagné pour les autres projets qui souhaitent intégrer ces fonctionnalités/changements.
[^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?
Posté par edhelas (site web personnel) . En réponse au journal Qui veux débattre Messagerie Instantané au Jardin Entropique . Évalué à 9.
Pour la signalisation d'appels WebRTC il y a Jingle dans XMPP avec entre autres :
Jingle est déjà implémenté dans de nombreux clients tel que Jappix (via WebRTC) ou Jitsi (https://jitsi.org/).
Pour l'IoT :
Avec des intérêt par des industriels tel que Cisco (http://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-protocols).
Je chipote un peu mais c'est également le cas de XMPP.
XMPP supporte l'authentification SASL, le chiffrement est maintenant obligatoire entre les serveurs (voir l'initiative https://xmpp.net/) et très souvent sur les clients (via StartTLS). Pour du chiffrement bout en bout des normes comme OTR sont maintenant largement déployés sur les clients XMPP (même si je trouve ça pas très très propre sur le coté protocolaire).
Je me suis penché sur Matrix il y a quelques semaines, car je me suis demandé qu'est ce qui pouvait pousser un groupe de développeurs à vouloir réinventer un nouveau protocole pour une énième fois alors que XMPP semble offrir tout ce qu'il faut.
Mais bon j'ai bien eu l'impression qu'il s'agissait plus d'une envie de repartir sur une nouvelle base au lieu de prendre le chemin de la difficulté et d'avoir à travailler avec la XSF pour améliorer/compléter XMPP.
Si c'est l'interconnexion avec le Web qui les embêtes :
Et même :
Oui, lire des normes c'est compliqué, et on est pas toujours d'accord avec ce qui est écrit. Mais quand le protocole est utilisé par des dizaines de serveurs utilisés par des universités, entreprises, multinationales, gouvernements, particulier; des centaines de clients sur toutes les plateformes et a plus de 15 ans d'ancienneté avec plusieurs RFC à l'IETF c'est plus compliqué de mettre tout le monde d'accord :) Pour le reste j'ai déjà écrit un commentaire là dessus il y a quelques jours http://linuxfr.org/nodes/105862/comments/1606599.
Le dernier point que je voulais aborder concerne l'une des spécificités de Matrix : fonctionner en HTTP.
Je pense que cette décision est une grave erreur, pourquoi ? Car HTTP amène un overhead énorme (oui c'est considérable quand il s'agit de gérer des listes de 400 contacts avec plusieurs dizaines de connections, des salons et des messages dans tous les sens). De plus cantonner un protocole "social/IM" au Web uniquement a une conséquence terrible : c'est compliqué de faire autre chose que du Web.
Le Web n'est qu'une petite partie d'Internet. Donc quand on base un protocole sur des technologies Web (HTTP en l'occurence) c'est plus difficile d'en sortir.
Et quand je vois ça dans la documentation de Matrix (http://matrix.org/docs/howtos/client-server.html) :
C'est ce qu'on appelle plus communément du long-polling, j'ouvre une requête HTTP, le serveur me répond quand il a quelque-chose à dire et j'en renvoie une autre derrière. Croyez moi sur des grosses charges ça ne tiens pas. Si vous voulez avoir du temps réel faite du socket (pure TCP ou WebSocket), encore une fois vous vous compliquez la vie et vous allez compliquer la vie des clients qui souhaiteraient faire du "vrais" temps réel et qui devront le simuler en utilisant des librairies comme Curl pour recréer un système évènementiel derrière.
# Ça ca parler de Matrix ou de l'IM en général au final ?
Posté par edhelas (site web personnel) . En réponse au journal Qui veux débattre Messagerie Instantané au Jardin Entropique . Évalué à 3.
J'ai l'impression que le débat va plutôt tourner autour de Matrix.
Néanmoins je trouve ça dommage de voir un énième protocole de messagerie apparaitre… comme si on en avait pas assez.
[^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?
Posté par edhelas (site web personnel) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 6. Dernière modification le 31 mai 2015 à 00:49.
Pour répondre globalement à ce post je dirais que ces grosses boites ont souhaités se passer de XMPP pour plusieurs choses :
- Les standards c'est chiants, et comme tu le dis si bien, si tu contrôle la chaine, pourquoi s'emmerder à vouloir être compatible avec les autres ? Quand tu es un grand acteur (comme Google) et que tu es imposant sur un marché (le mail avec Gmail), mais pas assez pour dominer, tu te plie aux standards et tu reste compatible. Se passer de XMPP casse des choses mais pas tant que ça en fait vu la "faible" utilisation de celui-ci atour de ces acteurs.
- XMPP est utilisé à 10% de sa capacité, voir moins. À combien de personnes, même dans la communauté du libre, je dois expliquer que non XMPP n'est pas uniquement pour le chat mais peut faire bien plus? On a plus de 300 extensions maintenant mais certaines d'entre elles sont a peine implémentés (Pubsub, sortit en 2008, jamais implémenté en totalité sur un serveur, et coté client…)
- Elles ont pas "compris" l'intérêt de XMPP, parcequ'elles se sont cantonnés à faire du chat par dessus, comme 80% des autres projets. Mais je pense que ce soucis vient aussi de la XSF qui doit activement communiquer sur les possibilités offertes par XMPP.
Avant de critiquer les multinationales parcequ'elles font des chôses dans leurs intérêts, regardons nous, libristes. On a attendu que Mozilla arrive pour faire du Web l'un des domaines les plus innovants de l'informatique moderne. Coté réseaux sociaux on a des dizaines de projets (StatusNet, Pump.io, Diaspora, Matrix…) qui sont certes très intéressants mais qui ne règlent pas le "problème" général. Quand Mozilla a bossé sur Firefox, ils ne voulaient pas créer UN Web pour eux, ils voulaient améliorer LE Web dans son ensemble.
Donc oui XMPP est critiquable, oui le XML sépabo, oui c'est chiant d'écrire une XEP pour dire comment gérer la sauvegarde d'un message sur un serveur mais c'est nécessaire.
Quand Google a voulu se mettre à XMPP ils ont tenté la fédération et ont proposé un client simple (Google Talk) et qui était dispo sur pas mal de plateformes à l'époque. Ils ont également travaillé à la "standardisation" (à leur manière certes) et au développement de la visio sur le protocole, ce qui nous a apporté Jingle. As t'on vu une révolution depuis ? Peut-on facilement faire de la visio sur nos machines de libristes ? Non. La norme est là pourtant. Et pourtant Pidgin n'a pas bougé, Gajim a une implémentation plus que buggé, Empathy pareil, les seuls qui se bougent sont Jitsi.
Résultat des courses, c'est grâce au Web qu'on a de la visio pas trop pourrit avec WebRTC, grâce à qui ? Mozilla et Google (principalement).
Donc avant d'aller voir pourquoi ça marche pas chez les autres améliorons nos clients, Pidgin ne semble pas bouger depuis plusieurs années, pourtant c'est pas compliqué il suffit juste d'implémenter la norme. Pour les nouveaux projets (comme Empathy) ils se cantonne au strict minimum (liste de contact, vcard et présence).
Je bosse sur le protocole XMPP depuis plus de 5 ans déjà et mon principal problème n'est pas d'écrire des normes ni d'essayer de l'implémenter dans mon client (Movim). Mon problème c'est de voir que je suis le seul (avec Jappix, SàT et quelques autres clients) à vouloir aller de l'avant, et c'est usant, très usant. J'ai créé un petit tableau récapitulatif du support de la normes sur les principaux clients ici https://pod.movim.eu/?q=about#caps_widget , il y a encore de très grosses lacunes chez pas mal de clients.
Donc avant de vouloir réinventer un énième protocole "social" essayez d'améliorer l'existant. XMPP offre, selon moi, les ingrédients pour créer une petite révolutions dans le domaine des échanges sociaux sur le Internet.
Pour vous donner quelques idées :
- Sur le papier on peut associer WebRTC et Jingle, Jappix l'a fait et semble être le seul à le faire assez bien. WebRTC colle au niveau protocolaire avec les solutions de visio "classiques" (hors du Web) pourquoi ne travaillons nous pas à rendre compatible Pidgin, Gajim… avec WebRTC ? Les normes sont là, il "suffit" juste de les implémenter.
- Sur XMPP on peut sauvegarder les bookmarks de nos clients (salons de discussions…), la norme existe… et pourtant. Pidgin sauvegarde ses bookmarks en local, Gajim fait à sa façon… bref même un truc aussi simple n'est pas fini. Du coup Goffi, moi et quelques autres motivés allons réécrire et simplifier la norme (http://xmpp.org/extensions/xep-0048.html) pour, espérons le, faciliter l'implémentation dans ces clients.
- Les XEP Vcard4 et Avatar permettent de "pusher" les informations entre les contacts, qu'est ce qui est encore majoritairement implémentés ? vcard-temp, XEP historique (http://xmpp.org/extensions/xep-0054.html) sortie en 2008 et qui fonctionne en pulling (il faut requêter une à une les vcard de vos contacts). J'ai implémenté Vcard4 tout seul en une après-midi sans grande difficulté, le nombre de projets qui ont fait de même se comptent sur les doigts d'une main. Petit détail, il n'y a rien à faire coté serveur (enfin il faut qu'ils supportent PEP, ce qui est déjà fait pour la majorité d'entre eux).
Donc pour résumer, la solution on l'a sous nos yeux, il faut juste l'implémenter et rendre compatible nos projets existants.
edhelas
[^] # Re: Excellent travail
Posté par edhelas (site web personnel) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 7.
Je suis heureux de voir que ce long travail porte enfin ses fruits et que nous allons enfin avoir une solution Pubsub générique et facilement adaptable aux serveurs XMPP du moment.
De la même façon nous allons pouvoir, pour la première fois avoir une pleine compatibilité avec des clients XMPP sur la gestion de flux et nous allons donc pouvoir faire du "réseautage social" :
- En temps réel (alors que de nombreux autres protocoles sont construit sur du polling HTTP)
- Multi-client et multi-serveur
- Extensible pour transporter de nombreuses normes (je me concentre sur Atom pour le moment)
- Décentralisé
- Hors du Web, car selon moi un réseau social n'a rien à faire sur le Web, c'est un réseau avant tout. Le Web n'est qu'une interface à celui-ci (au même niveau que le réseau mail, chat ou de partage de fichier).
En tous cas, Movim est prêt à accueillir les publications de SàT et je serais heureux de corriger les petits défauts pour que nous soyons pleinement compatibles :)
edhelas
# Laravel ?
Posté par edhelas (site web personnel) . En réponse au message Quel framework pour développer une api REST/Json ?. Évalué à 2.
J'ai créé une petite API REST/JSON pour mon projet : https://api.movim.eu/ et je suis content d'avoir choisir Laravel pour ça :)