Monter votre propre réseau social avec Movim et Metronome

Posté par (page perso) . Édité par ZeroHeure, palm123, NeoX, Valdenaire Denis, Benoît Sibaud, thomasv, Loïc Blot, Ymage, Pierre Maziere et Bruce Le Nain. Modéré par patrick_g. Licence CC by-sa
Tags : aucun
22
23
sept.
2013
Do It Yourself

Grâce au protocole XMPP, il est devenu relativement facile de monter son service de messagerie instantanée sur son serveur et de le connecter au reste du monde pour chatter avec n'importe qui (surtout grâce à Google Talk qui accepte les connexions entre serveurs et Android, qui a permis de créer énormément de compte Google Talk et de connecter les clients).

Mais aujourd'hui, suite à l'extension pubsub du protocole (qui n'est pas encore dans la standardisation d'XMPP), nous pouvons monter un réel réseau social sur nos serveurs. En effet, "pubsub" signifie "publish subscribe" qui se traduit par "publier et s'inscrire". Ce système permet de publier des messages vers des groupes de personnes et de suivre différents groupes pour voir les messages publiés par les autres.

Merci aux contributeurs de la dépêche pour la relecture, les corrections et les conseils (leur nom est dans le lien sous le titre de la dépêche) !

Sommaire

Les logiciels en pratique

En pratique, il vous faudra donc d'abord un logiciel de service XMPP qui implémente l'extension pubsub.

Grâce à la sortie récente de Prosody 0.9.1, vous pouvez installer et configurer facilement un tel serveur. Malheureusement, pubsub est une nouveauté récente dans Prosody et est encore en cours de développement. C'est pourquoi seul votre dernier message sera enregistré et il ne sera enregistré qu'en mémoire (ce qui signifie qu'au moindre redémarrage de Prosody, ce message sera perdu).

Mais heureusement, Maranda de LightWitch.org avait déjà commencé à modifier pas mal de code de Prosody 0.9 pour satisfaire les besoins de son site plus rapidement (Prosody a eu besoin de 2 ans pour sortir sa version 0.9). Comme le code devenait trop divergent, il a forké Prosody et nommé son projet Metronome IM qui est un serveur XMPP qui implémente entre autres beaucoup mieux pubsub (plus d'un message est enregistré et ceux-ci peuvent être stockés sur le disque avec ou sans base de données).

Ensuite, il vous faudra des clients XMPP capables d'utiliser l'extension pubsub pour afficher et rédiger les messages.

Bien que peu de clients ont un tel support, nous avons la chance d'avoir deux projets français qui proposent deux clients web différents : Jappix qui utilise beaucoup JavaScript et Movim qui s'efforce de faire travailler à minima le butineur en utilisant PHP.

Movim comme interface XMPP et pubsub

En fait, Movim est un client XMPP que vous utilisez à travers votre navigateur web. Il est donc compatible avec tous les logiciels XMPP plus classiques comme Pidgin, Gajim, Xabber,… et garde l'avantage du réseau XMPP d'être décentralisé.

Par contre, comme c'est un service web, il aura besoin d'un intermédiaire avec le serveur XMPP pour transformer les messages du format HTTP au format XMPP.

Pour ce faire, il sera donc nécessaire de placer un serveur BOSH entre Movim et Metronome pour le transfert de données entre le client et le serveur. Actuellement, vous avez le choix entre utiliser des services BOSH publiques (listés sur le site de Movim) ou de monter votre propre serveur BOSH comme expliqué sur le wiki de Movim.

Dès que vous avez trouvé votre solution BOSH, que vous vous êtes créé une base de donnée MySQL (ou PostgreSQL pour la version 0.7.2 en développement) et que vous aurez une version de PHP suffisamment récente (au moins 5.3), vous serez prêt à installer Movim tel n'importe quel service web.

Si tout cela est trop compliqué pour vous, vous pouvez aussi utiliser des clients Movim ouverts au public, mais vous devrez faire confiance au mainteneur du service, car vos messages seront sauvés dans le cache du serveur et votre mot de passe XMPP sera utilisé pour se connecter à votre serveur (il est donc important d'utiliser une couche de protection SSL, tel que HTTPS).

Les nouveautés de la récente version 0.7.1 de Movim

Pour les utilisateurs

  • Un nouveau thème original ;
  • ce thème est également adapté pour les mobiles ;
  • les blogs de groupes qui permettent d'avoir plusieurs utilisateurs qui postent sur un même blog ;
  • le formatage des messages avec MarkDown ;
  • l'envoi d'images et leur ajout dans les messages (le stockage des images n'étant pas supporté par pubsub, elles sont enregistrées dans le client Movim) ;
  • une fenêtre popup pour avoir toutes les conversations au même endroit ;
  • la possibilité de vider le cache de la base Movim pour retrouver les informations directement depuis le serveur XMPP (le cache permet d'éviter de solliciter trop souvent le serveur XMPP) ;
  • grande amélioration de la vitesse suite à la correction de différents bugs ;
  • l'utilisateur peut configurer son compte pour stocker de façon permanente ses messages de blogs — ainsi même après un redémarrage du serveur XMPP les différents messages seront conservés ;
  • les messages publics sont consultables au format de blog ;
  • le client Movim est reconnu comme application pour FirefoxOS et disponible dans leur gestionnaire d'application.

Pour les développeurs

  • l'utilisation de templates PHP avec le moteur RainTPL qui permet de mieux structurer le code ;
  • l'utilisation de JSON à la place d'XML pour discuter avec le serveur XMPP.

Futur

Le futur du développement dépend de vous ;-) Même si vous ne connaissez pas PHP ou XMPP, vous pouvez remplir des rapports de bugs, proposer des modifications dans le thème, de nouvelles traductions, … Pour cela tout se passe sur leur launchpad.

La version 0.7.2 est actuellement en bêta et permet entre autre de se connecter aux salons XMPP qui sont des discussions instantanées à plusieurs correspondants.
Actuellement, elle permet également d'utiliser PostgreSQL comme gestionnaire de base de données et elle a eu beaucoup d'optimisations dans le code.

Metronome IM comme serveur XMPP

Pour installer Metronome, il suffit de suivre les instructions du wiki (ou celles de Jappix). Comme le développement évolue assez vite, vous pourrez mettre à jour votre serveur grâce au Makefile inclus.

Comme Metronome IM a été forké de Prosody 0.9 sa configuration est très proche, à ces quelques détails près. Ainsi, vous pourrez utiliser la bonne documentation de Prosody pour configurer Metronome et modifier ces points-là.

Si vous avez déjà installé Prosody et que vous voudriez migrer vers Metronome, ne vous inquiétez pas, la migration des données est assez aisée, car Metronome est resté en grande partie compatible avec le format de Prosody.

Conclusions

En conclusion, voilà un type de réseau social libre et décentralisé1 qui est très intéressant et qui aura sûrement un futur prometteur, notamment grâce au standard XMPP.

Grâce à Jappix, Movim et Metronome IM, nous avons les premières implémentations de pubsub concrètes qui fonctionnent bien ensemble et qui permettent d'éprouver la version actuelle du brouillon du système publish/subscribe de XMPP.

Il reste encore beaucoup de développement pour avoir des services plus simples à utiliser et plus stables, mais avec les dernières version des logiciels, l'objectif est de plus en plus proche. Il faudra convaincre ensuite les autres clients XMPP d'intégrer pubsub dans leur code (Gajim, Pidgin, Telepathy, …).

1 : évidemment le réseau ne sera jamais totalement décentralisé, cela demande trop de technique, mais il sera déjà plus décentralisé qu'actuellement…

  • # Installation de Metronome

    Posté par . Évalué à 3.

    Merci pour cette dépêche qui permet de mieux faire découvrir le « nouvel écosystème » qui est en train de se construire autour de XMPP. Je trouve que la dynamique qui a été créée est très encourageante.

    J'ai tout récemment écrit un tuto décrivant l'installation de Metronome sur Debian ; vous pourrez le trouver ici : www.cypouz.com/article/130919/installation-serveur-xmpp-metronome

    Il sera suivi d'autres, décrivant justement la configuration de BOSH puis l'installation de Jappix et Movim.

  • # Deux projets français autour de XMPP

    Posté par (page perso) . Évalué à 10.

    Je dirais même trois avec Salut à Toi qui propose plusieurs interfaces en tant que client XMPP.

    Merci pour la dépêche :)

  • # Oula

    Posté par (page perso) . Évalué à 10.

    Comment des approximations pareilles ont pu passer dans une dépêche collective ?

    l'extension pubsub du protocole (qui n'est pas encore dans la standardisation d'XMPP)

    Quoi ??? Bien sûr qu'elle est dans les standards: http://xmpp.org/extensions/xep-0060.html , c'est un brouillon de standard (Draft), une étape relativement avancée dans la procédure (l'avant dernière même avant l'état « final ») qui indique une implémentation recommandée, et la possibilité de modifications tant que possible mineures suite aux retours sur les implémentations.
    PubSub est implémenté (de manière inégale) dans tous les serveurs XMPP que je connais (openfire, ejabberd, prosody, tigase, métronome) et probablement dans bon nombre de bibliothèques/cadriciels comme wokkel que j'utilise.
    Alors peut-être que le phrase sous entend qu'elle n'est pas au statut de standard final, mais pubsub est dans les standards XMPP.

    Ce système permet de publier des messages vers des groupes de personnes et de suivre différents groupes pour voir les messages publiés par les autres.

    PubSub ne permet pas que de passer des messages (au sens message microbillet), et pas forcément vers des personnes: ça peut être utilisé par exemple pour stocker des données publiques (http://xmpp.org/extensions/xep-0222.html) ou privée (http://xmpp.org/extensions/xep-0223.html).

    J'ai l'impression qu'il y a une confusion avec le microblogage (http://xmpp.org/extensions/xep-0277.html) qui est également dans les standards, mais dans un stade moins avancé.

    Malheureusement, pubsub est une nouveauté récente dans Prosody et est encore en cours de développement. C'est pourquoi seul votre dernier message sera enregistré et il ne sera enregistré qu'en mémoire (ce qui signifie qu'au moindre redémarrage de Prosody, ce message sera perdu).

    Quoi (bis) ??? PubSub est certe officielement dans prosody depuis la 0.9 qui est sortie récemment, mais ça fait un petit moment qu'ils sont dessus. Je n'utilise pas cette implémentation, mais je doute très fortement que « seul votre dernier message sera enregistré et il ne sera enregistré qu'en mémoire ». Une confusion avec PEP peut-être ?

    Bien que peu de clients ont un tel support, nous avons la chance d'avoir deux projets français qui proposent deux clients web différents : Jappix qui utilise beaucoup JavaScript et Movim qui s'efforce de faire travailler à minima le butineur en utilisant PHP.

    Comme d'hab « Salut à Toi » passe à la trappe.

    Pour ce faire, il sera donc nécessaire de placer un serveur BOSH entre Movim et Metronome pour le transfert de données entre le client et le serveur.

    Ça ne me semble pas clair: BOSH fait partie de XMPP: http://xmpp.org/extensions/xep-0124.html et c'est inclus dans prosody (j'imagine dans metronome aussi du coup): http://prosody.im/doc/setting_up_bosh . Il est possible d'utiliser un module de prosody, ou un proxy BOSH externe.

    le stockage des images n'étant pas supporté par pubsub

    Il est tout à fait possible d'enregistrer des images ou n'importe quel fichier binaire via pubsub. C'est juste qu'il n'y a pas encore de XEP sur le partages d'images en particuliers, ce qui à n'en pas douter arrivera tôt ou tard.

    Grâce à Jappix, Movim et Metronome IM, nous avons les premières implémentations de pubsub concrètes qui fonctionnent bien ensemble et qui permettent d'éprouver la version actuelle du brouillon du système publish/subscribe de XMPP.

    Euh c'est complètement faux. Il y a des tas d'implémentations de pubsub qui tournent depuis des années, j'en ai cité au dessus, et il y a d'autres projets plus ou moins connus (au FOSDEM il y a 2 ans j'avais vu une démonstration d'un suivi de transports en commun utilisant pubsub). On entend peut-être plus parler des Jappix, Movim ou SàT sur DLFP, mais il ne faut pas cracher sur le super boulot qui a été fait jusqu'ici par tous les autres.

    Bon, ceci mis à part, un grand bravo à l'équipe de Movim (et en particulier Timothée) pour le boulot et les progès de Movim: j'ai testé l'application Firefox OS rapidement, elle est très agréable à utiliser et prometteuse. Les mois à venir vont être excitants :)

    • [^] # Re: Oula

      Posté par (page perso) . Évalué à 8.

      P.-S.: en relisant mon commentaire: je n'ai pas voulu avoir un ton si agressif, que les contributeurs de la dépêche ne le prennent pas trop mal, c'est toujours bien d'avoir ce genre de dépêche.

      Ceci dit, DLFP est un site très influant, et lire que Prosody ne garde que le dernier item en mémoire ou que PubSub n'est pas dans les standards, c'est répandre de mauvaises informations qui peuvent cause du tort à ces projets.

      Merci tout de même pour la dépêche :)

      • [^] # Re: Oula

        Posté par (page perso) . Évalué à 2.

        Merci pour les précisions, c'est vrai que je n'ai un point de vue que de mise en pratique des outils et que je ne connais pas XMPP.

        Par contre, je t'assure que Prosody implément(e/ait?) de façon très bizarre pubsub et que l'année passée en tout cas, durant le développement de la version 0.9, Movim ne trouvait toujours qu'un seul message par personne.

        Sinon, personnellement, quand je vois le statut "Draft" et l'avertissement ci-dessous (sur la page xep que tu as cité), je ne considère pas l'extension faisant parti du standard.

        NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

        • [^] # Re: Oula

          Posté par . Évalué à 3.

          Il me semble que l'argument majeur de la 0.9, c'était un pubsub "qui marche" (c'est du moins ce qu'ils attendaient chez Jappix, dernière fois que j'en ai causé avec eux).

        • [^] # Re: Oula

          Posté par (page perso) . Évalué à 4.

          Par contre, je t'assure que Prosody implément(e/ait?) de façon très bizarre pubsub et que l'année passée en tout cas, durant le développement de la version 0.9, Movim ne trouvait toujours qu'un seul message par personne.

          Pour Movim je ne sais pas, mais je sais que Jappix utilisait les notifications PEP qui de base envoient le dernier item uniquement (même s'il peut en envoyer plus). Le truc est que cette notif du dernier élément n'est pas prévue pour ça, c'est fait pour des événements personnels (d'où le nom de la XEP) du style l'humeur de quelqu'un ou la musique en cours d'écoute. Le problème peut venir de là (mais les développeurs confirmeront ou infirmeront s'ils passent par là).

          Pour le microblogage, il faut explicitement demander les X derniers items pour tous ses contacts, et ça Prosody sait forcément le faire s'il fait du PubSub.

          Sinon, personnellement, quand je vois le statut "Draft" et l'avertissement ci-dessous (sur la page xep que tu as cité), je ne considère pas l'extension faisant parti du standard.

          Draft est un standard brouillon, mais c'est un standard. Disons que ce que je n'aimais pas dans la dépêche, c'est qu'on avait l'impresson que c'était un truc non officiel implémenté par Metronome, alors que ça fait des années que c'est tout à fait officiel et utilisé, le statut annonce simplement que des ajustements peuvent encore avoir lieu.
          Si tu veux une description précise des différents statuts des XEP, c'est la première qui explique tout ça: http://xmpp.org/extensions/xep-0001.html .

    • [^] # Re: Oula

      Posté par (page perso) . Évalué à 3.

      Je n'utilise pas cette implémentation, mais je doute très fortement que « seul votre dernier message sera enregistré et il ne sera enregistré qu'en mémoire »

      La reponse dans le message du dev principal: Prosody ne conserve pas les messages sur le disque parce que c'est difficile de faire ça proprement, et qu'ils ont d'autres priorités.

      C'est juste qu'il n'y a pas encore de XEP sur le partages d'images en particuliers

      Quoi (ter) ? Entre le Out-of-band, le In-band et le Bits-of-Binary quand c'est pas trop gros, il y a largement de quoi faire pour échanger du binaire.

      • [^] # Re: Oula

        Posté par (page perso) . Évalué à 3.

        La reponse dans le message du dev principal: Prosody ne conserve pas les messages sur le disque parce que c'est difficile de faire ça proprement, et qu'ils ont d'autres priorités.

        J'ai discuté entre temps. Effectivement l'implémentation n'est pas persistante, et c'est une des différence majeure avec metronome, qui aurait une implementation « naive » de la persistance. Ceci dit, tu ne récupères pas que le dernier message avec l'implémentation de Prosody (ce qui serait aberrant avec PubSub), l'affirmation est donc fausse.

        C'est juste qu'il n'y a pas encore de XEP sur le partages d'images en particuliers

        Quoi (ter) ? Entre le Out-of-band, le In-band et le Bits-of-Binary quand c'est pas trop gros, il y a largement de quoi faire pour échanger du binaire.

        Tu me parles de transfert de fichier, moi je te parle de XEP qui défini le partage d'images (ou de galeries) par PubSub: est-ce qu'on code l'image en XML ? Est-ce qu'on utilise le SI File Transfer ? Est-ce qu'on utilise Jingle ? Comment on envoit les métadonneés ? Lesquelles ? Etc.
        J'ai déjà dit qu'on pouvait transférer des données binaires avec PubSub.

        • [^] # Re: Oula

          Posté par (page perso) . Évalué à 2.

          Tu me parles de transfert de fichier, moi je te parle de XEP qui défini le partage d'images (ou de galeries) par PubSub

          Ah oui pardon, en effet j'avais rien compris. Qu'est-ce que tu entends par partage d'images via PubSub ? La notification d'une nouvelle image a un contact, l'envoi de l'image elle-même dans la notification ?

          • [^] # Re: Oula

            Posté par (page perso) . Évalué à 2.

            Oui la notification d'une nouvelle image ou d'une galerie, les formats à supporter, les résolutions recommandées, les métadonnées à mettre, etc. Une simple notification ou un envoi complet c'est à définir, mais je pense que l'idéal serait de juste notifier, et de récupérer ensuite l'image via un transfert de fichiers Jingle (ou éventuellement mettre un aperçu dans la notification).

  • # Compatibilité entre les clients

    Posté par (page perso) . Évalué à 3.

    Les différents clients (movim, jappix, sat, autre?) utilisent tous l'extensions PubSub d'XMPP pour publier les messages mais ils ont une approche différente.

    Est-ce que la différence est seulement sur qui fait le travail (le client pour Jappix, le serveur pour Movim, … pour SAT) ou c'est plus fondamental (la structure des messages, les méta données associées, …) ?

    Posé autrement : Est-ce que Alice qui utilise Movim pourra échanger sans problème avec Bob qui utilise Jappix ? Ou est-ce que XMPP/PubSub n'est qu'une couche transport et chacun utilise son format de données (incompatible) à l'intérieur ?

    Matthieu Gautier|irc:starmad

    • [^] # Re: Compatibilité entre les clients

      Posté par (page perso) . Évalué à 4.

      Movim et Jappix utilisent la XEP-0277(microblogage) et sont compatibles entre eux. Pour les images vu que ce n'est pas standardisés, ils ont tous les 2 leur solution maison, je ne sais pas si elles sont compatibles.

      SàT gère aussi la XEP-0277, mais l'implémentation des permissions fines (cf http://www.goffi.org/post/2012/06/24/Permissions-fines-pour-PubSub) qui permettent d'envoyer un message juste à un groupe m'ont obligé à faire ma propre implémentation expérimentale de pubsub (http://repos.goffi.org/sat_pubsub/), en attendant de proposer ça à la standardisation. Ça devrait être compatible, sauf qu'une implémentation externe ne me permet pas d'utiliser PEP (une version simplifiée de pubsub qui associe notamment un jid à un nœud pubsub), et du coup ça ne l'est pas. Mais la structure des messages, le protocole est globalement le même (il est enrichie pour SàT de manière compatible).

      C'est un peu technique, je peux détailler plus si tu veux, mais en gros pour l'instant ça n'est pas compatible, et dans le futur ça devrait l'être.

      C'est la XEP-0277 qui défini le format de données (en gros c'est du atom).

      • [^] # Re: Compatibilité entre les clients

        Posté par (page perso) . Évalué à 2.

        Ben j’espère que ça va vite se standardiser bien comme il faut tout ça, parce que je sais pas vous mais je n’arrive pas à envoyer ou recevoir de fichiers via un XMPP avec un autre client que Pidgin (pourtant j’ai souvenir d’avoir réussi avec Kopete il y a un moment).

        C’est à dire que ça ne fonctionne pas avec les logiciels basés sur telepathy (Empathy et KDE-Telepathy (KTP) avec telepathy-gabble, j’ai pas réussi à faire fonctionner telepathy-haze) ou Kopete.

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Compatibilité entre les clients

          Posté par (page perso) . Évalué à 2.

          D’ailleurs, j’ai pas testé mais il y a le même genre de problème avec l’audio et la vidéo. Tout ça pour dire que les standards c’est bien, mais souvent il y a des incompatibilités qui gâchent tout…

          Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Compatibilité entre les clients

          Posté par (page perso) . Évalué à 2.

          Ben j’espère que ça va vite se standardiser bien comme il faut tout ça, parce que je sais pas vous mais je n’arrive pas à envoyer ou recevoir de fichiers via un XMPP avec un autre client que Pidgin (pourtant j’ai souvenir d’avoir réussi avec Kopete il y a un moment).

          Attention, je parle uniquement du microblogage, parce que c'est expérimental, et il y a plusieurs projets (dont les 3 sus-cités) qui travaillent dessus. Mes modifs pour SàT je ne les ai pas encore proposées parce que ça prend du temps de faire une XEP propre, et que pour l'instant je ne l'ai pas trouvé.

          Par contre le transfert de fichier donc tu parles est tout à fait standard, il y a la vieille méthode avec la XEP-0096 que pratiquement tout le monde gère mais qui ne passe pas facilement les NATs et autres joyeusetés, et la nouvelle via Jingle qui marche beaucoup mieux mais qui est beaucoup moins implémentée, j'avais expliqué ça (ouch avec des fautes d'ailleurs à la relecture) dans un commentaire.

          Bref si tu n'arrives pas à transférer un fichier, tu devrais le signaler sur les outils de débogage des clients concernés.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.