edhelas a écrit 85 commentaires

  • [^] # Re: dépêche en cours de rédaction

    Posté par (page perso) . En réponse au message Comparatif réseaux sociaux. Évalué à 3.

    le réseau XMPP est éclaté au gré des versions, là où je suppose que tout les serveurs Movim fournissent les mêmes fonctionnalités avec la même interface.

    Bah c'est juste que le protocole évolue, donc non il n'y a pas de "versions" mais plutôt qui implémente quel bout de version du protocole (c'est un peu pareil pour tous les autres protocoles en fait).
    Movim a une liste de fonctionnalités a peu prêt stables depuis quelques années en effet mais l'interface et features évoluent quand même un peu mois après mois.

    Si j'ai un compte Movim, je peux donc faire de la messagerie instantanées avec les applications type Conversation, Pidgin, Gajim, etc?

    Tu n'as pas de compte Movim, c'est tout le concept, tu as un compte XMPP, Movim est un client XMPP orienté "social" où tu te connecte avec ton compte XMPP dessus, c'est tout. Donc oui, par extension il est compatible avec tous les autres clients XMPP déjà dans la nature :)

    Movim est-il sécurisé ?

    Définir "sécurisé", Movim se connecte aux serveurs XMPP en utilisant la norme SASL (définit dans XMPP), en forçant TLS (définit dans XMPP) et délivre aussi le contenu en HTTPS/WSS. Si tu parles de chiffrement de bout en bout, la réponse courte et non, la réponse longue se situe ici https://github.com/movim/movim/issues/63.

  • [^] # Re: dépêche en cours de rédaction

    Posté par (page perso) . En réponse au message Comparatif réseaux sociaux. Évalué à 4.

    Petite précision, pour pas se mélanger les pinceaux il va falloir être attentif à séparer proprement les "clients" des "réseaux".

    Là ou un réseau centralisé comme Facebook est plutôt une solution tout en un Diaspora/Mastodon sont des solutions dont les "pods" hébergent aussi les comptes (c'est fédéré SUR les pods). Movim par exemple n'est qu'un client qui se connecte aux serveurs XMPP, les comptes ne sont pas sur les "pods" Movim mais sur les serveurs XMPP (plus à la manière des serveurs mails).

    Je pense que c'est un détail qui a toute son importance.

  • [^] # Re: erreur de recruteur...

    Posté par (page perso) . En réponse au journal Etude comparée de la popularité des langages de programmation sur linuxfr. Évalué à -5.

    TapTempo? Ah c'est le truc qui SPAM LinuxFR en ce moment avec une méthodologie digne d'une publicité TV Mercurochrome. Désolé j'ai même pas regardé ce que c'était à part un machin qui voulait être écrit dans tous les langages.

  • # PHP…

    Posté par (page perso) . En réponse au journal Etude comparée de la popularité des langages de programmation sur linuxfr. Évalué à 10.

    J'ai vraiment du mal à justifier le bashing continuel envers PHP.

    Le langage à certes des défauts mais depuis quelques années, avec des frameworks comme Laravel, les PSR, Composer, la documentation… franchement je commence à douter du sérieux de ces points de vue.

    On peut aussi parler de l'environnement autour de JS? Du clivage de la communauté Python avec l'arrivée de Python 3.

    Ah et aussi, c'est vendredi.

  • [^] # Re: Interopérabilité avec le Social Web ?

    Posté par (page perso) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 5.

    Peut être que le soucis ici c'est le mot "Web". L'IETF (et XMPP) a vocation à standardiser des protocoles s'appliquant sur le réseau "Internet" alors que le W3C ne s'occupe principalement que ce qui touche au Web (donc, en gros, ce qui est construit sur HTTP).

    Ce que j'ai répété pendant pas mal de temps dans mes conférences c'est que le "Web" et un sous-ensemble de "Internet" (HTTP repose sur TCP…).

    Ce n'est pas un soucis en soit mais XMPP a vocation d'être accessible depuis un nombre d'application bien plus grandes "by design" (ce qui est aussi une critique qu'on lui apporte, les premiers pas sur XMPP sont plus difficiles que de jouer avec une simple API REST/JSON). Aussi essayer de transformer un protocole "connecté" (construit sur des flux) comme XMPP en protocole "déconnecté" (construit sur des requêtes) est bien plus simple que l'inverse.

  • [^] # Re: O'RLY

    Posté par (page perso) . En réponse à la dépêche Movim 0.12 — Lovejoy. Évalué à 3.

    C'est assez rigolo qu'on trouve toujours quelqu'un pour critiquer un truc qui va pas :D

    Les noms sont juste pris un peu au hasards dans la liste des comètes de Wikipedia D'ailleurs si tu souhaitais participer j'avais offert le choix à la communauté de trouver le nom de la release pour cette version https://nl.movim.eu/?node/pubsub.movim.eu/Movim/8d77979d-5485-4742-be83-b2669f58fbdd, vu que je n'ai pas eu de retours particulier j'ai choisit Lovejoy :) Le nom de la prochaine release reste à choisir ;)

  • [^] # Re: O'RLY

    Posté par (page perso) . En réponse à la dépêche Movim 0.12 — Lovejoy. Évalué à 6. Dernière modification le 03/11/17 à 08:01.

    Lovejoy c'est le nom d'une comète, comme pour les précédentes version depuis le passage à l'architecture temps-réel sur Movim (v0.11 – Tuttle, v0.10 – Holmes, v0.9 – Tchouri) ;)

    Sinon la communauté (merci à eux) bosse sur des paquets pour les différentes distros (que ça soit pour les clients ou l'instance serveur).

    Pour IRC ça va pas être simple de convaincre tout le monde mais movim.eu fournit un service pour se connecter au réseau très facilement, il se base sur l'excellent Biboumi (j'en parle ici d'ailleurs https://nl.movim.eu/?node/pubsub.movim.eu/Movim/8e3ab235-2de8-45c0-a3c7-62d6b40a9ef2).

  • [^] # Re: XMPP, Pas facile de s'y retrouver

    Posté par (page perso) . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 6. Dernière modification le 14/10/17 à 19:30.

    irssi dans un screen permettait de le faire depuis 1999 pour IRC.

    En lançant une VM avec une Ubuntu et un client XMPP, puis ne me connectant en bureau à distance dessus j'arrive aussi à garder synchronisé mes messages tout le temps depuis partout! Génial!

  • [^] # Re: Conséquences ?

    Posté par (page perso) . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 4.

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

    Petite précision ici, Movim utilise bien la technologie WebSocket, mais coté navigateur, il se connecte à XMPP de façon standard (flux TCP avec TLS), rien de particulier n'est à configurer coté serveur pour qu'il fonctionne donc :)

  • [^] # Re: Ici aussi

    Posté par (page perso) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 4.

    Ça tombe bien, Jingle (la partie "visio/p2p") de XMPP est pleinement compatible avec WebRTC (il y a même des extensions spécialement écrites pour ça https://xmpp.org/extensions/xep-0343.html).

    J'appelle ma moman de temps en temps en utilisant Movim et WebRTC entre nos deux comptes XMPP entre Chrome et Firefox, en 720p stéréo :)

  • [^] # Re: Parce que xmpp est un protocole

    Posté par (page perso) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 9.

    Ça marchera sûrement très bien en Chine

    Le recensement effectué en 2007 en Chine populaire donne 4700 noms, dont une centaine de doubles et de rares noms plus longs. Chez les Han, on compte en moyenne 320 000 personnes par nom, avec de très grandes variations en pratique. Une centaine de grands noms nomment réunis 84,77% des Chinois. Wang (王) vient en tête avec 92,881 millions de porteurs (7,25% de la population) suivi de Li (李) (92,074 millions, 7,19%) et Zhang (張/张) (87,502 millions, 6,83%).
    https://fr.wikipedia.org/wiki/Nom_de_famille_chinois#Statistiques

  • [^] # Re: Tentative de réponse

    Posté par (page perso) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 10. Dernière modification le 29/09/17 à 09:26.

    On est d'accord, il y a eu un problème de calendrier. Et oui je te l'accorde, XMPP a mis du temps, beaucoup de temps, à se réveiller et enfin intégrer des fonctionnalités "modernes" de messagerie (partage de fichier, synchronisation des messages entre clients, gestion de l'historique, édition des messages publiés…).

    Là où il faut faire attention, et c'est un soucis de rôle qui revient couramment, c'est que "XMPP" n'a pas comme vocation de proposer une solution clé-en-main avec services et clients aux internautes. XMPP est un protocole, au même niveau que SMTP/IMAP/POP ou HTTP le sont pour l'email et le Web. La XSF offre juste une solution de messagerie fédéré.

    D'ailleurs c'est une question qui revient assez souvent au sein de la XSF (dont je suis moi même membre). La XSF doit elle pousser ou mettre en avant certains clients ou solutions implémentant XMPP au détriment des autres? Jusqu'ici la réponse a été de jouer la carte de la neutralité et de se cantonner à simplement "faire le job de standardisation".

    Mais pour revenir à ta remarque le problème de XMPP a bien été un problème temporel. Aujourd'hui on ne se pose plus la question de savoir quel protocole utiliser pour l'email et le Web, car très tôt un standard a émergé (surtout pour l'email, pour le "Web" ça a été un peu plus compliqué, on se souvient de la bataille des navigateurs dans les années 90-début 2000). Les protocoles et standards gravitant autour de l'email et du Web ne sont pas parfaites, loin de là, mais ont comme avantage de proposer une vision unifiée forçant même les "géants" à se plier à eux (tu peux envoyer un email d'un compte Outlook à un compte Gmail depuis un iPhone sur un Thunderbird installé sur une distro Linux).

    Pour la messagerie instantanée (et même le réseau social, ce que j'essaye de montrer avec Movim), malheureusement ce sont les outils qui sont venus avant les protocoles, si bien qu'aujourd'hui il devient difficile d'expliquer que non le problème ne vient pas d'XMPP en lui même, mais du fait qu'il lui faut se justifier face à des solutions centralisées, complète, faciles et intégrées aux interfaces et appareils des utilisateurs.

    La question que je poserais donc serait de savoir pourquoi aujourd'hui nous n'avons pas encore de clients/serveurs/plateformes qui permettent d'offrir des solutions de messageries instantanées "modernes" et étant construit sur LE standard (norme IETF, au même titre que POP/IMAP/SMTP/HTTP… le sont) existant.
    Cela est entrain de changer, on commence (enfin) à avoir des clients complets et accessibles (Conversations ou Dino https://github.com/dino/dino, voir même Movim (dont je suis le développeur principal)) et les serveurs rattrapent leurs retard rapidement sur ce qui a été standardisé ces dernières années.

    Il y a quelques années (je bosse sur Movim depuis 9 ans maintenant) j'étais très dubitatif quand au fait que XMPP soit réellement un protocole viable pour construire une solution moderne de messagerie instantanée (et de réseautage social dans mon cas) mais en travaillant de consorts avec les autres projets (clients comme serveurs) implémentant XMPP, en ouvrant des bugs et discutant continuellement des implémentations et de l'amélioration du protocole j'ai la forte impression qu'on est entrain de transformer l’essai.

    Les discussions au sein de la XSF se sont énormément fluidifiés ces derniers mois, les nouvelles fonctionnalités peuvent être standardisés et intégrés en l'espace de quelques mois (alors qu'il fallait bien souvent des années auparavant). Même si nous avons nos propres points de vues je suis heureux de voir qu'il y a des échanges continuels sur comment "bien faire" avant de simplement implémenter et de voir ensuite. Tout ça permet de proposer des serveurs et clients compatibles à leur sortie et d'avoir systématiquement une documentation de référence pour les futur entrants souhaitant communiquer avec les projets existants.

  • [^] # Re: Les informaticiens veulent pouvoir converser avec le reste du monde

    Posté par (page perso) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 9.

    Attention ne mélangeons pas tout.

    XMPP n'a pas comme vocation à régler le problème de portabilité des comptes d'un serveur à un autre, qui est un problème plutôt complexe dans un réseau fédéré. Tu l'as dit toi même, pour l'email, ô combien c'était compliqué (je noterais tout de même que sur XMPP la liste de contacts est synchronisé avec le serveur ce qui facilite la transition).

    Les réseaux centralisés n'amènent pas nom plus de solution à ce problème, au contraire, Facebook a t'il codé une solution pour permettre à ses utilisateur de migrer aisément sur Google+ ? Je ne le crois pas.
    Nous pouvons tout de même noter que l'Europe est entrain de forcer la main à ces géants concernant la portabilité des données entre les plateformes (dans la section concernant la Data Portabity du tout récent GDPR https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) et cela passera pas la mise en place et le développement d'outils prenant appuis sur des standards et protocoles existants.

    L'histoire de l'identifiant unique "qui le suit toute sa vie" c'est une fausse solution, car elle amène également un grand nombre de soucis, notamment concernant la traçabilité et le recoupage. Il n'y a pas de solution miracle et XMPP à fait le choix d'être fédéré ("à la email") avec tous les défauts et contraintes inhérents à ce genre d'architecture.

    L'un des gros points positifs, et tu l'as mentionné, d'un système centralisé c'est la découverte de contenu. Ou, dit d'une nouvelle façon, le "tu as déjà 9 contacts sur le réseau, on le sait car tout le monde est dans la même base de donnée". Cette fonctionnalité et ce qui marche le plus en ce moment, le dernier grand exemple étant WhatsApp: le recoupage et la découverte étant d'une simplicité absolue puisqu'il s'agit d'aspirer la liste de contacts (téléphonique) de l'utilisateur et de la comparer aux identifiants (numéros téléphoniques) des membres déjà inscrits.

    Il n'y a pas de solution magique malheureusement, la découverte de contenu/contacts dans un réseau fédéré (ou pire décentralisé) est un problème très complexe. La solution la plus simple (et "scalable") que nous avons pour l'instant et d'indexer le réseau en un point: le moteur de recherche/annuaire (Google pour le Web, ThePirateBay pour le réseau Torrent…).

  • # Enfin!

    Posté par (page perso) . En réponse au journal dino, un nouveau client jabber GTK+ façon GNOME 3. Évalué à 6.

    Pour ma pat je porte beaucoup d'attention à ce projet, on a enfin un client bureau qui implémente du XMPP "moderne" et qui n'a pas une interface du début des années 2000 (n'en déplaise à certains).

    Je pense que l'upload de fichiers ne devrait pas tarder (le projet est encore jeune) ;)

  • # Radio Paradise, une webradio qu'elle est bien

    Posté par (page perso) . En réponse à la dépêche À la (re)découverte de Radio Paradise. Évalué à 3.

    Merci à toi pour ce petit article pour faire découvrir cette merveilleuse radio sur LinuxFR.

    Radio Paradise c'est depuis pas mal d'années déjà la webradio que j'écoute quand je ne sais pas quoi écouter dans mon audio-thèque MPD :) Elle a même un bouton assigné sur la télécommande IR de mon RPi (qui me sert de médiacenter à la maison).

    Radio Paradise c'est bon, mangez-en.

  • [^] # Re: Installer son propre serveur ?

    Posté par (page perso) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 2.

    C'est l'intérêt d'avoir ce genre d'infrastructure :) Au choix.

    Il existe déjà plein d'instances déployées de part le monde ainsi que plusieurs serveurs XMPP compatibles mais rien ne t'empêche d'héberger toi même ton instance, voir ton serveur XMPP si tu le souhaites.

    L'intérêt principal est souvent d'avoir le contrôle sur tes données.

  • [^] # Re: L'appli .rpm n'est pas disponible

    Posté par (page perso) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 3.

    Corrigé ;)
    Petite précision, le paquet RPM n'est qu'une conversion du paquet DEB en utilisant Alien. Je n'ai malheureusement pas le temps de packager proprement Movim sur toutes les distros mais je suit ouvert à toute aide extérieure sur ce genre de tâche.

  • [^] # Re: Petit retour utilisateur

    Posté par (page perso) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 7.

    Merci à toi !
    - En effet ce bouton n'est pas super évident, je vais voir ce que je peux faire
    - La recherche/découverte est quelque-chose de très difficile sur un réseau décentralisé puisqu'il faut continuellement indexer et rapatrier des information du "réseau" sur le nœud sans pour autant tout récupérer. Ici cela doit être fait avec les contraintes d'XMPP également.
    - Voici un des exemples de mon point précédent :D Comment proposer du contenu intéressant pour que l'utilisateur ne soit pas devant une interface vide au premier lancement sans pour autant avoir à le traquer ou le profiler dans les moindres détails.
    - Basculer un article en "public" se fait en éditant chaque articles un par un.
    - Merci :) Il est aussi possible d'ajouter une feuille de style CSS personnalisée dans la configuration pour customizer un peu le blog.
    - Je vais y réfléchir

    J'ai renégocié mon contrat de travail de 40h à 36h pour me dégager une journée toutes les deux semaines sur le projet. Cela est lié à la création de Movim Europe. L'idée étant d'essayer de rémunérer le travail fait sur Movim pendant cette journée afin de compléter la perte de salaire dû à la réduction du temps de travail. Pour l'instant c'est difficile mais je continue à chercher des entreprises et/ou structures qui seraient partantes pour supporter le développement du projet ou de certains fonctionnalités.

  • [^] # Re: déplacement d'un profil

    Posté par (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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 (page perso) . 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.