Movim, le réseau social standard et décentralisé sort en version 0.8. Cette dépêche sera l'occasion de revenir sur le projet, les nouveautés apportées ainsi que sur le travail prévu pour ces prochains mois.
Beaucoup de nouveautés dans l'optimisation qui sont détaillées en seconde partie. L'utilisateur verra surtout l'apparition de la visio-conférence via l'extension Jingle de XMPP et des grosses améliorations visuelles.
Sommaire
- Mais d'abord, qu'est-ce que Movim ?
- Movim 0.8, quoi de neuf ?
- Pour la suite
- Levée de fonds
- Super bonus - Mise à jour de la 0.7
Mais d'abord, qu'est-ce que Movim ?
Présentation générale
Il est toujours bon de resituer le projet ainsi que son environnement avant de partir dans les détails.
Movim a pour but d'offrir une interface sociale sur le réseau de communication XMPP, standard de messagerie depuis plus de 10 ans maintenant.
L'idée générale étant de limiter l'effet "Not Invented Here" en réutilisant un maximum de briques logicielles et protocolaires déjà existantes ainsi qu’en participant au développement de celles-ci. Et c'est ici notre point majeur de différenciation par rapport à d'autres réseaux sociaux décentralisés comme Diaspora par exemple.
Le projet se déploie donc sur un serveur Web traditionnel à la manière d'un blog (il est écrit en PHP et fonctionne sur les bases de donnée MySQL et PostGreSQL) et va faire l'intermédiaire entre le réseau XMPP et les navigateurs des utilisateurs.
D'un point de vue XMPP, Movim se comporte donc comme un simple client tout en offrant à l'utilisateur une expérience de navigation similaire aux autres réseaux sociaux. L'architecture étant elle-même conçue pour permettre la connexion de plusieurs comptes simultanément.
Fonctionnalités
De nombreuses fonctionnalités ont été ajoutées au fil des versions. En voici une liste non exhaustive.
Une liste des extensions du protocole XMPP (appelées XEP) est également tenue à jour à cette adresse : Wiki Movim - Protocol Implementation.
Comme tout client XMPP digne de ce nom, Movim implémente déjà tout ce qui est nécessaire pour faire de la messagerie instantanée : liste de contacts, présences, échange de messages, salons de discussion.
L'interface de chat
De nombreux ajouts ont également été faits comme la possibilité d'avoir un accusé de réception à l'envoi d'un message, le support du contenu enrichi (liens, formatage du texte), la synchronisation des discussions entre les clients (pour continuer sur votre ordinateur une discussion commencée sur votre mobile par exemple) ou encore la transmission et réception des états de rédaction ("en train d'écrire", "en pause").
Le but étant de systématiquement pousser le standard un peu plus loin que ce qui a été fait dans les autres clients, tout en discutant avec les autres projets basés sur XMPP pour les inviter à faire de même (tel que le projet Salut à Toi ou encore Jappix).
Au niveau des profils, Movim implémente naturellement les vCards XMPP.
La page profil
Les salons de discussion sont également de la partie, même s'ils vont être sensiblement revus par la suite (voir la suite du billet).
Les grosses différences apparaissent donc sur les fonctionnalités dites "sociales" du projet. Tout d'abord le support complet de la norme Publish-Subscribe (PubSub pour les intimes) permet à Movim d'offrir un système de flux sur les comptes des utilisateurs et de façon plus générale via la fonctionnalité que nous appelons "Groupes" et qui permet de créer des flux de discussion publics (un peu à la manière d'un forum).
Un groupe
Vous pouvez également partager avec vos contacts les différents groupes auxquels vous avez souscrit via la fonction "Groupes Publics". Tout cela est paramétrable depuis la page de Configuration de votre compte.
La gestion de groupes partagés
À part ça la version 0.8 inclut également un support expérimental de la visio-conférence via WebRTC. Pour cela nous implémentons la norme Jingle standardisée au sein de XMPP. À terme Movim devrait être capable d'initier une session multimédia avec l'ensemble des clients implémentant la norme.
L'interface générale a été pensée pour être totalement « responsive », Movim s'adaptera donc à l'écran de votre téléphone tout comme aux écrans de très grande taille (grâce à un affichage du contenu principal sur deux colonnes).
Movim 0.8, quoi de neuf ?
Pour le coeur du projet
Les changements sont conséquents et touchent tant l'interface que les données en elles-mêmes. Le plus important ici étant que nous restons pleinement compatibles avec les anciennes versions de Movim ainsi que tous les autres clients XMPP. Il n'y aura donc pas de rupture de compatibilité comme nous l'avons vu pour Diapora* ou StatusNet.
Concernant le cœur du projet, de nombreux refactorings ont été faits pour mettre en conformité Movim avec les normes de codage (spécialement les normes PHP PSR). Ainsi les bibliothèques utilisées sont maintenant déclarées comme dépendances et ont été sorties du code du projet (via l'utilisation de Composer et du service Packagist). Movim utilise également la bibliothèque Monolog pour la gestion des journaux système.
Le système de traduction a été réécrit pour tenter d'éviter au maximum les erreurs de détection qui ont été rencontrées auparavant. Désormais toutes les chaînes de caractères à traduire seront placées dans des fichiers INI simplifiant par ailleurs la vie des développeurs.
La quasi-totalité des "Widgets" de Movim ont été nettoyés et réécrits vers une structure MVC plus propre. L'idée est surtout d'uniformiser leur fonctionnement en utilisant les outils offerts par le cœur de Movim (moteur de template, gestion des événements…).
Cette version accueille également une nouvelle librairie de gestion des images avec un nouveau système de génération des miniatures.
De très nombreuses optimisations ont été faites suite au traçage de l'exécution de Movim, une grande partie d'entre elles concernent l'accès (lecture et écriture) à la base de données. Certaines optimisations ont permis d'accélérer le temps de chargement des pages de plus de 50%.
La configuration a également été déplacée vers la base de données (sauf la partie concernant la base de données, vous imaginerez bien pourquoi :p).
Movim utilise maintenant la librairie SASL2 lui permettant de supporter un grand nombre de méthodes d’authentification sécurisée coté XMPP. Du travail reste à faire pour la sécurisation de l'authentification entre le navigateur et le serveur web.
L'ensemble des échanges en AJAX entre le navigateur et le serveur sont désormais structurés en JSON (contre XML auparavant) allégeant la taille des paquets et le temps de traitement des informations contenues (particulièrement coté Javascript).
La gestion des sessions a également été réécrite pour mieux contenir les erreurs de synchronisation d'identifiants rencontrées dans les précédentes versions. Appelée SessionX, celle-ci essaye d'effectuer les traitements de mise à jour des identifiants de session au plus bas niveau possible (dans notre cas dans la base de données).
Coté base de données des améliorations notables ont été apportées à Modl (la librairie de gestion de base de données propre à Movim). Des optimisations ont été faites sur la partie s'occupant d'hydrater les objets suite à une requête (en tentant de minimiser les appels). Le système SmartDB, s'occupant de mettre à jour la base de données a été également amélioré et supporte maintenant les mises à jour de type sur les colonnes (longueur et catégorie de données). Quelques bugs mineurs relatifs à MySQL ont également été corrigés.
Cette version 0.8 inclut désormais le support de la version 4 de vCard (voir XEP-0292: vCard4 Over XMPP) ainsi que la nouvelle norme de transmission des avatars basée sur le système événementiel PEP (voir XEP-0163: Personal Eventing Protocol). En gros cette nouvelle méthode permet de "pousser" les changements (mise à jour du profil, de l'avatar) vers les utilisateurs plutôt que de les forcer à requêter fréquemment des informations auprès de leurs contacts. Cela réduit considérablement le trafic et est plus en phase avec le fonctionnement général de XMPP.
Beaucoup de traductions ont été faites et je remercie tous les traducteurs pour leurs superbes travaux !
Pour l'utilisateur
Pour l'utilisateur c'est une flopée de nouvelles fonctionnalités qui arrivent avec cette version.
Comme expliqué dans la précédente section, suite à un projet fait pendant nos études nous (moi et ma copine) avons travaillé sur l'intégration de la technologie WebRTC dans Movim. Ainsi cette version offre un support expérimental de la visio-conférence via l'extension Jingle de XMPP.
L'affichage sur deux colonnes des billets permet également une utilisation optimale de la surface d'affichage sur les grands écrans.
Le support des salons de discussion a été en partie réécrit pour mieux s'intégrer à l'interface. Vous pouvez maintenant vous connecter d'un simple clic une fois le salon que vous souhaitez rejoindre listé dans vos favoris.
Les favoris
Pour les administrateurs un énorme travail de nettoyage et de simplification a été fait dans le panneau d'administration du projet. Une API a également été ajoutée permettant de très facilement lister votre serveur sur la liste des Pods officiels (l'API est disponible à cette adresse).
La page Explorer a été complètement retravaillée pour être plus lisible et accessible à tous. Vous retrouverez toujours la liste des utilisateurs ayant choisi de partager leur profil mais également les serveurs de Groupes ainsi qu'une nouvelle section appelée "What's Hot" qui liste les derniers Groupes ayant été mis à jour sur le Pod.
Lors de la publication d'un billet, vous pouvez maintenant préciser un titre.
La page de profil a été divisée en 3 onglets pour faciliter la navigation et la mise à jour des éléments.
Le chat implémente maintenant l'extension XMPP Carbons (voir XEP-0280: Message Carbons) permettant de synchroniser les discussions entre les différents clients XMPP.
Et ce sont plusieurs dizaines de bugs qui ont été corrigés afin d'unifier le comportement des éléments composant l'interface et d'améliorer la navigation de l'utilisateur.
Pour la suite
Ce qui peut être dit c'est que ce n'est pas prêt de s'arrêter. Il y a encore énormément de fonctionnalités qui peuvent être intégrés dans Movim.
Il est question de faire fortement évoluer le cœur du projet pour le rendre encore plus dynamique et performant. Pour le moment, Movim se connecte aux serveurs XMPP via le module BOSH (permettant d'encapsuler les paquets XMPP dans des requêtes HTTP). Outre la relative lourdeur amenée par le protocole HTTP (qui, à l’origine, n'est pas fait pour du temps réel) c'est la fragilité de la session (qui est tenue coté client) qui est la plus dérangeante.
L'idée serait donc de "maintenir" les sessions coté serveur via la mise en place d'un démon et d'utiliser des Websockets pour relayer les événements. Ce système serait beaucoup plus léger à exécuter et à débugger. Un des gros avantages de cette solution serait de garder les sessions XMPP ouvertes coté serveur, même après le départ de l'utilisateur et ainsi de synchroniser efficacement tout nouveau contenu publié sur le réseau.
Le travail lié à cette nouvelle fonctionnalité est conséquent. C'est pourquoi une partie de l'argent récolté par la petite levée de fonds que nous préparons sera investie dans le temps consacré au développement.
Une autre fonctionnalité majeure est également en préparation pour la prochaine version. C'est l'intégration d'une puissante interface de messagerie. Nous souhaiterions offrir une interface similaire aux webmails existants mais en exploitant les nombreuses fonctionnalités offertes par XMPP pour parvenir à nos fins (gestion de l'historique, messages différés, mise en copie d'un message…). Cette fonctionnalité mêlera également la fonctionnalité chat traditionnelle déjà implémentée qui sera retravaillée pour être intégrée au sein de la "messagerie type mail".
Deux autres fonctionnalités sont également prévues pour la version 0.9.
Nous souhaiterions intégrer le support du protocole OTR au sein de l'interface de Chat pour rattraper notre retard sur le chiffrement de bout en bout.
Finalement, un nouvel onglet apparaitra dans l'interface de configuration et permettra la gestion des comptes externes afin de les lier au compte XMPP (en passant par les modules de transport proposés par le serveur de l'utilisateur).
Levée de fonds
Contrairement aux précédentes versions, celle-ci sera accompagnée d'une levée de fonds sur Kickstarter. Cette levée servira essentiellement à assurer le fond de roulement du projet dont principalement :
- L'achat et/ou la location de serveurs permettant d'assurer l'hébergement de notre infrastructure (rassurez-vous on a pas besoin d'un datacenter)
- Quelques goodies pour la promotion lorsqu'on fait des rencontres salons (stickers, T-shirts, kakémono…)
- Le remboursement d'une partie des frais lors des déplacements vers ces mêmes événements.
Je ne souhaite pas partir sur une version commerciale du projet ni monter de structure autour de celui-ci pour le moment. Movim est un logiciel libre vivant grâce au temps qu'on consacre à son élaboration et sa promotion, rien d'autre. Cet argent sera donc gardé précieusement pour m'éviter d'apporter de ma poche tout ce qui est nécessaire pour son développement.
J'essayerai d'être le plus transparent possible sur les dépenses qui seront faites avec cet argent, au vue des projets de même envergure sur Kickstarter le montant demandé sera de l'ordre de la dizaine de milliers d'euros, bien sûr plus grand sera le montant plus longtemps le projet sera financé :).
Super bonus - Mise à jour de la 0.7
Si vous avez déployé la version 0.7 de Movim sur votre serveur, la mise à jour vers la version 0.8 ne devrait pas être très difficile. Je vous conseille tout de même de faire une copie de la base de données si possible avant toute manipulation.
Afin de partir sur une base propre je vous conseille de déployer la 0.8 dans un dossier à part et de copier le dossier users/ de la 0.7, Movim s'occupera de recréer le cache ainsi que toutes les miniatures.
La configuration est désormais enregistrée directement dans la base de données vous n'aurez donc qu'à renseigner les identifiants de connexion au serveur MySQL ou PostgreSQL en copiant et renommant le fichier db.example.inc.php en db.inc.php et complétant son contenu.
En passant alors par l'interface d'administration (dont les identifiants sont, par défaut, 'admin' et 'password') vous aurez la possibilité de mettre à jour votre base de données et de configurer correctement votre serveur.
N'hésitez pas à vous enregistrer sur l'API de Movim si vous souhaitez être listé sur la liste des pods officiels (une vérification manuelle est systématiquement faite pour éviter les abus).
That's all folks !
Aller plus loin
- Movim - Site Officiel (1372 clics)
- Movim - Wiki Officiel (156 clics)
- Le compte Launchpad du projet (sources, bugs et traductions) (71 clics)
- Pod officiel (163 clics)
# sqlite
Posté par zurvan . Évalué à 3.
je vois que dans les anciennes versions movim permettait d'utiliser sqlite (http://www.planet-libre.org/index.php?post_id=9935), est-ce toujours le cas ?
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: sqlite
Posté par edhelas (site web personnel) . Évalué à 8.
Non, la nature même de SQlite et les changements d'architecture apportés à Movim depuis ces versions nous empêchent de l'utiliser efficacement. Par contre Movim supporte pleinement PostGreSQL et MySQL.
[^] # Re: sqlite
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Si l'hébergement facile n'est plus une priorité, pourquoi continuer le support de mysql? Autant gagner du temps en n'utilisant que la base la plus puissante.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: sqlite
Posté par edhelas (site web personnel) . Évalué à 3. Dernière modification le 14 septembre 2014 à 19:21.
"la base la plus puissante" est ici une remarque assez subjective. Même si en effet nous avons des performances un peu meilleures avec PostGreSQL nous souhaitons garder une compatibilité avec un grand nombre de serveurs, et MySQL n'est pas très difficile à supporter compte tenu de notre bibliothèque de gestion de base de données ;)
[^] # Re: sqlite
Posté par etenil . Évalué à 3.
Si les précédentes versions permettaient effectivement d'utiliser SQLite, celle-ci était surtout utile à des fins de développement. SQLite est en effet beaucoup trop lente pour un Movim en production; MySQL ou postgresql sont beaucoup plus performants.
[^] # Re: sqlite
Posté par Zylabon . Évalué à 5.
Même pour un nœud avec un seul utilisateur ? Personnellement si je me met à utiliser Movim, il n'y aura guère plus d'un utilisateur sur mon serveur (comme beaucoup de gens qui s'auto-hébergent).
Je pense que c'est dommage, là, s'il avait été possible d'en installer un avec SQLite je l'aurais fais suite à a la lecture de cette dépêche. Mais comme je n'ai pas envie d'apprendre à me servir d'autres choses, ni de donner mon mot de passe à quelqu'un d'autre…
Please do not feed the trolls
[^] # Re: sqlite
Posté par zurvan . Évalué à 1.
idem. C'est vraiment pratique à utiliser sqlite, un seul fichier, pas de mot de passe, facile à migrer etc, peut-être que les perf sont un peu moins bonnes, mais si le but c'est justement de décentraliser au maximum on peut s'attendre à avoir 1, 2 ou 3 utilisateurs par noeud.
Il me semble qu'en utilisant pdo ça permet de coder une seule interface compatible avec plusieurs types de base de données, comme ça ce sont les utilisateurs qui décident ce qui leur convient le mieux comme bdd.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: sqlite
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
PDO ne fait pas abstraction des différences du langage SQL d'un moteur de DB à l'autre, donc gérer mysql, pgsql et sqlite est un peu compliqué dès qu'on a des requêtes un peu complexes à traiter.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: sqlite
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
C'est tout à fait faux. SQLite est très performant, mais il y a quelques petites choses à savoir, telles que l'usage des transactions en écriture.
[^] # Re: sqlite
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 16 septembre 2014 à 17:06.
Yep, SQLite est très efficace et rapide, ce n'est pas une question de lenteur, plutôt une question de complexité de développement : mysql et SQLite ne comprennent pas le langage SQL de la même manière et ont chacun des spécificités qui peuvent être complexes à gérer si on veut marcher avec les deux. Par exemple la gestion des dates, ou la gestion de la recherche full text, etc.
Quelqu'un qui vous dit que SQLite est trop lent c'est quelqu'un qui ne sait pas utiliser SQLite en général ;-)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: sqlite
Posté par Larry Cow . Évalué à 6.
De manière plus générale, quelqu'un qui vous dit que $_SGBDR est trop lent est souvent quelqu'un qui n'a pas compris à quoi servait un index.
# Comparaison (amicale) entre Movim et Salut à toi ?
Posté par Ryzz . Évalué à 10.
Bravo pour le travail accomplit et le travail de rédaction de la dépêche!
À chaque dépêche (du moins régulièrement), vous parlez de la compatibilité et des échanges avec Salut à toi et vice-versa, mais concrètement, qu’est-ce qu’on peut attendre comme communication entre les deux d’un point de vue utilisateur ? Si vous pouviez avec Goffi faire une petite dépêche un jour pour nous expliquer les points communs, les différences ainsi que la manière de communiquer entre Movim et Sàt, ce serait très intéressant.
Après le travail qu’a dû demander la rédaction de cette dépêche, reposez-vous un peu quand même !
[^] # Re: Comparaison (amicale) entre Movim et Salut à toi ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Au niveau chat, on est 100 % compatibles, la problème est au niveau microblogage.
On utilise le même protocol, mais nous (SàT) on utilise notre propre serveur pubsub pour gérer ça, parce qu'on joue beaucoup avec la gestion des permissions, et ça n'est pas possible à l'heure actuelle avec les service pubsub intégrés aux serveurs (surtout que ce qu'on fait n'est pas encore standard). Du coup on ne peut pas communiquer avec Movim ou Jappix pour le microblog (ils sont eux complétement standards).
Nous travaillons actuellement sur 2 extensions qui devraient permettre d'utiliser notre service pubsub en remplacement du service interne, et Berlin nous a permis de confirmer que ça intéressait au moins l'auteur de Prosody. Donc la situation devrait assez rapidement changer (au pif je dirais que d'ici 3 semaines à 1 mois on devrait pouvoir être compatible Movim et Jappix).
Pour les autres services, je pense que Movim comme SàT cherchent à être 100 % compatibles XMPP, donc c'est surtout une question de degré d'implémentation, et il suffit de remonter un bogue si quelque chose vous manque ou marche mal.
Aujourd'hui Movim a déjà commencé la visio-conférence et pas SàT, d'un autre côté SàT fait OTR et pas encore Movim. Les priorités dépendent des équipes de dev et des demandes…
La plupart des infos étant sur les serveurs, on devrait pouvoir utiliser Movim et SàT alternativement ou en parallèle.
Donc d'un point de vue utilisateur, les fonctionnalités devraient être compatibles, ce qui changera ce sera surtout le degré d'implémentation (qui devraient tendre vers une implémentation complète avec le temps pour tout le monde), et la façon de présenter les choses. Dans Movim on aura plutôt une présentation sur une ou 2 colonnes, tandis que dans Libervia (interface web de SàT) ça fonctionne avec des widgets qu'on place où on veut; le choix est affaire de goûts.
# Conservation de ses données en cas de changement de POD
Posté par mahikeulbody . Évalué à 2.
Peut-on facilement transférer ses données en cas de changement de POD ?
J'attends le lancement de la campagne sur kickstarter pour contribuer (au fait, vous avez prévu un post ici pour nous en informer quand elle sera ouverte ?).
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par edhelas (site web personnel) . Évalué à 4.
Pour l'instant il n'y a pas de système pour "transférer" son compte d'un pod à l'autre, par contre ce qu'il faut comprendre c'est que Movim n'est ici qu'un client et que la majeure partie des informations se situent sur le compte XMPP :)
Donc en se connectant avec le même compte depuis un autre pod toutes ces informations seront automatiquement synchronisées. Il y a également possibilité, depuis la page de configuration de "nettoyer" la base de donnée d'une grande partie des traces laissées sur un pod (les contacts, messages et billets).
Le seul truc qui ne peut pas être déplacé sont les images hébergés sur l'ancien pod :)
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par mahikeulbody . Évalué à 2. Dernière modification le 13 septembre 2014 à 15:58.
> Donc en se connectant avec le même compte depuis un autre pod toutes ces informations seront automatiquement synchronisées.
Super ! Même si ma question portait surtout sur la possibilité de changer de pod je suis curieux de savoir de quel type de synchro il s'agit : bi-directionnelle (et si oui, "nettoyer" un pod ne risque pas de "nettoyer" l'autre ?)
> Le seul truc qui ne peut pas être déplacé sont les images hébergés sur l'ancien pod.
C'est une limitation intrinsèque à XMPP, à la techno utilisée coté serveur ou bien est-ce une limitation qui pourrait être levée un jour si nécessaire ? Et quand on parle d'image hébergée, cela inclut également les images insérées dans un post (auquel cas, une synchronisation sur un autre pod pourrait "dégrader" certains posts) ?
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par edhelas (site web personnel) . Évalué à 2.
En gros Movim crée juste un gros cache de ce qui se passe sur le réseau XMPP, donc quand on se connecte sur un autre pod il recrée ce cache… et y'a possibilité de supprimer la majeure partie du contenu de ce cache ;). Donc non nettoyer un pod ne nettoiera pas l'autre.
C'est une limitation quasiment impossible à lever, l'hébergement d'images sur Movim est totalement indépendante de XMPP, c'est de l'hébergement HTTP "pure" (comme n'importe quel autre service tel que Imgur, ImageShack…). Le problème c'est que ces images seront liées à des messages, billets… donc les déplacer casserait de nombreux liens, et il est impossible de retrouver tous les articles qui pointent vers elles (il y a sûrement eu duplication des messages et billets entre temps par exemple).
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Argon . Évalué à 3.
Pour le moment mon expérience est très mitigé, j'ai un compte xmpp qui fonctionne bien (ch3kr.net) j'ai essayé de me connecter sans succès (pod par défaut), j'ai essayé un autre pod pareil, j'en ai essayé un autre mais il stipule quelques serveurs autorisés et c'est tout. J'ai finalement réussi à me connecter au pod de alwaysdata qui est en fait un pod de test… Soit j'ai loupé une information soit ce n'est pas si beau et rose au niveau de l'inter-connectivité. Donc qu'est ce qui coince ?
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Kioob (site web personnel) . Évalué à 1.
Je viens de tester sur le Pod officiel et j'ai le même problème, pas moyen de me connecter, la «Connexion…» mouline depuis plusieurs minutes déjà. Le fond change de couleur pour faire patienter un peu, mais je préférerais que ça fonctionne ;)
Bref, que pasa ?
Mon compte Jabber est hébergé sur une machine perso, avec une instance de Prosody (0.8.2). Est-ce que ça peut-être lié ? Genre, je n'active pas Bosh sur mon serveur, Movim cherche à l'utiliser ?
alf.life
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Zylabon . Évalué à 2.
Truc très bête (j'ai fais l'erreur) tu as ouvert le port pour les connexions clients ?
Please do not feed the trolls
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Kioob (site web personnel) . Évalué à 1. Dernière modification le 13 septembre 2014 à 23:33.
Yep, mon compte Jabber me sert tous les jours, avec des gens venant d'autres «serveurs» (principalement Gmail d'ailleurs).
EDIT : bon bah semblerait que ce soit un petit bug de refresh. En retournant sur la page d'accueil du pod, me voilà connecté.
alf.life
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Kioob (site web personnel) . Évalué à 1. Dernière modification le 13 septembre 2014 à 23:57.
Je me demande si ce n'est pas un bug de JS plus général : je n'avais pas de vcard, Movim m'invite donc à la saisir, ce que je fais. Une fois saisie, je clique sur «Submit» et rien ne se passe. Je clique plusieurs fois, en vain. Je retourne à l'accueil, et je constate qu'elle a bien été soumise.
Sinon au niveau interface, c'est pas mal pour le moment, je découvre un peu.
J'ai toutefois ce message :
« Your server doesn't support post publication, you can only read contact's feeds »
(message non traduit en français d'ailleurs)
Un lien vers une doc un quelque chose expliquant de quoi il retourne m'aurait aidé :)
alf.life
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par navaati . Évalué à 2.
T'as activé PubSub sur ton serveur ? Je crois que Movim s'en sert lourdement.
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Kioob (site web personnel) . Évalué à 1. Dernière modification le 14 septembre 2014 à 12:39.
Merci pour cette piste. Je ne connais pas du tout, et mon Prosody 0.8.x non plus. J'ai donc forcé une mise à jour vers Wheezy backports pour avoir un Prosody 0.9.x et le support du composant «pubsub». Installé, redémarré, pas d'erreur dans les logs, mais toujours même erreur coté Movim.
Y a moyen de tester cette fonctionnalité autrement ? Y a une liste des modules XMPP requis quelque part ?
alf.life
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par edhelas (site web personnel) . Évalué à 3.
La plupart du temps je redirige les administrateurs vers le Wiki du projet Jappix et ici plus spécialement vers la page détaillant le déploiement du serveur Metronome (la configuration est similaire).
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Kioob (site web personnel) . Évalué à 2.
Merci pour ce lien, mais pas mieux. Les seuls modules non activés ne sont tout simplement pas dispos dans Prosody.
En l'état je vais simplement laisser tomber, ça semble bien trop «bleeding edge» à mon goût pour que j'arrive à m'en servir.
alf.life
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par Argon . Évalué à 2.
J'ai essayé avec mon compte apinc ça marche mais pas avec ch3kr, les deux sont des serveurs jabber qui sont indiqués comme de bonnes qualités sur la page officiel xmpp.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Données conservées sur le serveur XMPP
Posté par mahikeulbody . Évalué à 1. Dernière modification le 14 septembre 2014 à 20:03.
> la majeure partie des informations se situent sur le compte XMPP.
Les quelques lectures que j'ai pu faire sur XMPP m'indiquent qu'un serveur XMPP stocke essentiellement les contacts et les messages en attente de pouvoir être délivrés (si le client - ici Movim - est offline). J'en déduis que l'historique des messages est seulement stocké dans le pod Movim. Or, ta réponse ci-dessus laisse penser que même les messages/billets sont stockés sur le serveur XMPP puisqu'en se connectant sur un autre pod celui-ci va récupérer ces infos.
Que stocke un serveur XMPP ?
[^] # Re: Données conservées sur le serveur XMPP
Posté par navaati . Évalué à 2.
Ça dépends des XEP qu'il implémente, et il existe une XEP pour le stockage des logs sur le serveur.
# Super mais....
Posté par shingo (site web personnel) . Évalué à 6.
Pourriez-vous régler ces deux erreurs sur votre page d'accueil ?
[^] # Re: Super mais....
Posté par edhelas (site web personnel) . Évalué à 1.
Oui je vais essayer de corriger ça ;)
# Merci !
Posté par maatunix . Évalué à 3.
Super news, je suis content d'apprendre de bonnes nouvelles pour ce projet. Qui garde la tête hors de l'eau en comparaison à Diaspora et consorts… :)
# Jingle?
Posté par Larry Cow . Évalué à 3.
Comment ça se passe, sachant que ça nécessite (sauf erreur de ma part) du XMPP côté client?
[^] # Re: Jingle?
Posté par edhelas (site web personnel) . Évalué à 2.
Comme expliqué dans l'introduction de la dépêche, le client d'un point de vue XMPP est ici Movim. Par contre nous faisons le lien avec le navigateur utilisant WebRTC via deux librairies (JingletoSDP et SDPtoJingle) afin de faire dialoguer la partie WebRTC du navigateur et Jingle :)
[^] # Re: Jingle?
Posté par Larry Cow . Évalué à 2.
Donc pas de lien pair-à-pair entre deux utilisateurs?
[^] # Re: Jingle?
Posté par edhelas (site web personnel) . Évalué à 2.
Si et c'est avec WebRTC que ça se passe, simplement, pour mettre en liaison les deux navigateurs (liaison qui servira à envoyer les flux audio-vidéo) il faut échanger quelques paquets préalables, et ces paquets passent par la connexion XMPP des utilisateurs, donc par Movim et leurs serveurs XMPP respectifs.
[^] # Re: Jingle?
Posté par Larry Cow . Évalué à 5.
Et ça arrive à rester compatible Jingle? Typiquement, je peux espérer me connecter en P2P à un utilisateur de Movim si je suis sur Jitsi ou Jappix?
# Mmh
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'ai essayé la démo:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mmh
Posté par maatunix . Évalué à -2.
Il faut mieux essayer avec un bon serveur en "production". Mes settings sont normalement bon.
Viens donc t'amuser par ici: movim.maatunix.eu
[^] # Re: Mmh
Posté par edhelas (site web personnel) . Évalué à 3.
Ton serveur n'est pas à jour, je vois qu'il est actuellement à la version 0.8beta3, pas mal de choses ont été corrigées depuis :)
[^] # Re: Mmh
Posté par maatunix . Évalué à -2.
Fait, merci pour la remarque. :)
[^] # Re: Mmh
Posté par navaati . Évalué à 1.
T'as oublié un truc :
# Ce que qui
Posté par Maxime (site web personnel) . Évalué à 2.
"Ce que qui peut être dit c'est que ce n'est pas prêt de s'arrêter."
hein?
[^] # Re: Ce que qui
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Droits
Posté par voxmundix . Évalué à 2. Dernière modification le 14 septembre 2014 à 16:44.
Je suis en train de l'essayer et je me demandais si c'est normal que le dossier /var/www/movim doit avoir un chmod 777 pour pouvoir accéder à l'interface? :)
[^] # Re: Droits
Posté par voxmundix . Évalué à 1.
En passant, je suis actuellement bloqué par:
Failed to connect to localhost port 5280: Connection refused
(j'ai tenté de me connecter avec une adresse jit.si, est-ce ça qui foire? est-ce mon pare-feu? celui du Nat?) ^ ^
[^] # Re: Droits
Posté par voxmundix . Évalué à 1. Dernière modification le 14 septembre 2014 à 16:55.
Sorry pour le triple post mais le message précédent c'est posté en double, si un modérateur pouvait supprimer ce message svp.
merci
[^] # Re: Droits
Posté par edhelas (site web personnel) . Évalué à 6.
Il n'a jamais été question de mettre des droits 777 sur le dossier. Dans le tutoriel d'installation seul des droits en écriture pour le serveur web (ici www-data) sont nécessaires. ;)
[^] # Re: Droits
Posté par voxmundix . Évalué à 1. Dernière modification le 14 septembre 2014 à 18:46.
autant pour moi j'avais fais une erreur dans les groupes.
et pour l'erreur:
Failed to connect to localhost port 5280: Connection refused
J'ai voulu tester avec le compte de démo mais ça ne fonctionne pas. ^ ^
[^] # Re: Droits
Posté par Kioob (site web personnel) . Évalué à 2.
5280 est un port BOSH. Il cherche visiblement à se connecter à une passerelle HTTP<>XMPP sur la machine locale.
Donc soit tu en configures une, soit tu utilises une passerelle publique (me semble en avoir vu sur le wiki de Movim).
alf.life
[^] # Re: Droits
Posté par voxmundix . Évalué à 0. Dernière modification le 14 septembre 2014 à 23:27.
oki d'ac merci a vous deux.
Pour l'anecdote j'ai suivis le tuto qui indique qu'on peut tester avec les "bosh" publiques de movim mais quand je le rentre dans la page d'admin rien ne se passe (il remet le localhost)
PS: vraiment stylé le changement temps réel discret de couleur du fond ;)
# Réseaux sociaux et données privées
Posté par tuxicoman (site web personnel) . Évalué à 3. Dernière modification le 14 septembre 2014 à 23:41.
Imaginons que je veuille partager une photo de moi à poil avec mon amie (pour faire référence à l'affaire #fappening)
Je devrai faire confiance à:
- l'admin du serveur XMPP de mon compte
- l'admin du pod Movim de mon compte
- l'admin du pod Movim de mon amie
- l'admin du serveur XMPP de mon amie
En plus de faire confiance que tout ce beau monde chiffre proprement toutes les connections.
Même si je suis l'admin de mon propre serveur XMPP et pod Movim, mes amis peuvent choisir des pods et serveur moins enclins à garder les données privées (imaginons que Facebook propose un jour un pod Movim)
Pensez vous que l'avenir soit au déchiffrement sur le terminal utilisateur?
Ou c'est trop compliqué à gérer car l'intelligence coté serveur est essentielle au fonctionnement du bouzin?
Ou on s'en fout, nous sommes des geeks et nous sommes les admins?
Ou la confiance dans les intermédiaires n'est pas un problème?
[^] # Re: Réseaux sociaux et données privées
Posté par edhelas (site web personnel) . Évalué à 4.
Libre à toi de faire ce que tu veux ;)
Oui il va falloir faire confiance à toute la chaine c'est sûr, mais, tout comme quand tu publie un truc sur Facebook, il faut aussi faire confiance à :
- Ton fournisseur d'accès Internet
- À celui qui gère l'infrastructure jusqu'à l'autre pays
- Au fournisseur d'accès de l'autre serveurs
- …
En fait ce qu'il faut voir ici c'est que Movim ne vas pas aider à te protéger toi (tout comme on ne va pas t'empêcher de publier une photo de ta mite). Ici c'est plutôt un effet d'échelle, il sera beaucoup plus difficile de surveiller "tout" le réseau vu que les informations seront réparties sur des centaines de nœuds.
Le chiffrement de bout en bout oui c'est prévu pour la prochaine version (via OTR), mais on ne va pas pouvoir tout chiffrer. À vrais dire ce truc ne va affecter que ce qui concerne les discussions par "chat" (ce qui est déjà une bonne chose en soit).
Chiffrer le reste est beaucoup plus compliqué vu qu'il faudra mettre en place des clefs partagés ou des autorisations spéciales pour les paires avec qui on voudra partager nos précieuses informations.
Bah comme je le disais ici, Movim ne va pas t'empêcher de te mettre à poil devant ta webcam. Je reste convaincu que même si nous travaillons sur les meilleures solutions techniques du monde la meilleure façon de protéger l'utilisateur passe par l'éducation et l'information.
La confiance des intermédiaires est toujours un problème, surtout dans un réseau aussi répartit et varié. ;)
[^] # Re: Réseaux sociaux et données privées
Posté par tuxicoman (site web personnel) . Évalué à 1.
Comment se passe la communication entre le site web (Movim) et le serveur XMPP? J'ai cru comprendre qu'un serveur BOSH était nécessaire entre les 2. Est celui-ci a connaissance du contenu transité? Est ce que la connexion est chiffrée?
[^] # Re: Réseaux sociaux et données privées
Posté par voxmundix . Évalué à 2.
Tu peux encore rajouter le DDNS dans la liste pour ceux qui ont une IP dynamique.
Enfaite, retroshare a l'air d'avoir le système le plus robuste actuellement, mais il n'est pas adapté aux smartphones, bouffe trop sur pc, pas interopérable et n'a pas une interface tape a l’œil.
Movim semble intéressant pour la partie publique et retroshare pour la partie privée.
[^] # Re: Réseaux sociaux et données privées
Posté par Argon . Évalué à 4.
Le problème c'est qu'il va falloir que tu fasses confiance à ton ami avec son mot de passe : 123456 et c'est peut-être ça la plus grosse faille de sécurité ;)
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Réseaux sociaux et données privées
Posté par claudex . Évalué à 4.
Il me semble que c'est du HTTPS pour Facebook, du coup, pas besoin de faire confiance aux différents FAI.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Réseaux sociaux et données privées
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
En effet, il est tout à fait impossible que ton FAI re-route les requêtes DNS vers de méchants serveurs DNS.
[^] # Re: Réseaux sociaux et données privées
Posté par Larry Cow . Évalué à 3.
Si tes CAs ne mentent pas, ça devrait se voir.
[^] # Re: Réseaux sociaux et données privées
Posté par tuxicoman (site web personnel) . Évalué à 1.
même si tes DNS mentent, si tu obliges le passage par SSL pour accéder aux données, ce ne devrait pas être un problème.
[^] # Re: Réseaux sociaux et données privées
Posté par tuxicoman (site web personnel) . Évalué à 1.
A moins d'avoir un faux certificat "Facebook.com" signé par Verisign… Mais là ca va vraiment loin.
[^] # Re: Réseaux sociaux et données privées
Posté par Maclag . Évalué à 5.
-Ton amie elle-même, parce que la plupart des gens sont peu au fait de la sécurité et des bonnes pratiques. Même ceux qui en connaissent les principes peuvent facilement se faire piéger par ignorance.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.