Le flux est sensé être le même, sauf que celui-ci se synchronise quand l'utilisateur se connecte avec son propre compte.
De plus celui-ci doit déclarer quel article venant de XMPP doit être rendu public sur le pod.
Il n'y aura pas d'intégration de flux RSS à Movim car ce n'est pas le but de celui-ci. Movim n'est qu'un client XMPP "social" et orienté web.
De plus Movim n'a pas vocation à recenser les flux des autres pods (comme le fait Diaspora par exemple) mais de puiser toutes ces informations du réseau XMPP, le seul point de synchronisation pour les données du réseau sera XMPP ;)
Pour l'annuaire j'ai construit une petite API qui permet aux administrateurs d'enregistrer leurs serveur sur une liste.
L'API est disponible à cette adresse https://api.movim.eu/ et est implémentée dans l'interface d’administration de Movim depuis la version 0.8 :)
Un petit message pour supporter ce petit projet très sympa avec plein de bonnes idées ! N'hésitez pas à aller faire un tour sur les différents services ;)
Oui on a une implémentation très très instable de WebRTC dans Movim, d'ailleurs je pense la désactiver pendant quelques temps le temps de retravailler dessus et de la stabiliser (je préfère avoir un truc qui marche bien qu'un machin qui est présent dans l'interface et qui pose des problèmes/marche une fois sur 20).
Par contre Movim n'a pas remplacé BOSH par WebRTC mais par WebSockets ;) On avait de très très gros soucis de performance avec BOSH (qui "transporte" une connexion XMPP classique sur des requêtes HTTP) et le fait de passer à WebSocket nous apport beaucoup de bonnes choses :
- Temps de connexion très rapide, j'arrive même en dessous des clients bureaux comme Pidgin ou Gajim… pour un truc en PHP :D
- Persistance des sessions, vous pouvez fermer votre navigateur, passer sous un tunnel (physique, pour les tutures, je parle pas de VPN là :p), la session restera ouverte (car tenue coté serveur)
- Possibilité de "bourriner" la connexion, BOSH nous imposait une limite "d'une demande à la fois"
Pour mon avis sur Firefox Hello, j'en ai déjà parlé un peu plus tôt dans la discussion. Je pense que Mozilla se plante à vouloir réinventer la roue et que pour une fondation qui défend la neutralité et les standards c'est marrant de les voir ne pas respecter aucune des deux prérequis (neutralité ? non ils sont entrain de créer leur propre protocole, donc on sera dépendant d'eux pour les choix de spécification). Ils ont déjà implémenté XMPP en partie dans Thunderbird donc qu'on aille pas me dire qu'ils savent pas faire la même chose pour Firefox.
Et l'argument de Goffi sur le possible fait d'utiliser un "transport" XMPP pour communiquer avec eux n'est pas bon. Un transport travaillera toujours ne mode "dégradé" (que ça soit au niveau des performances, des fonctionnalités…) du fait d'avoir à convertir un protocole en un autre. Les librairies de transport sont bien souvent en retard et n'implémentent jamais toutes les fonctionnalités du protocole à transporter.
Donc Mozilla, s'il te plaît, il n'y a pas que le Web qui a besoin de standard, de décentralisation et de neutralité !
Étant développeur du projet Movim j'attends également énormément des ces XEP. C'est assez frustrant d'avoir à "attendre" la norme pour pouvoir bien faire les choses au lieu de tout faire dans notre coins et perdre la compatibilité avec les autres.
De mon point de vue je vois la messagerie instantanée d'aujourd'hui comme était le Web au début des années 2000 : fragmenté, bourré de "trucs maisons/proprio" et quasiment impossible à unifier. Ici je parle surtout de la flopée de clients de messagerie qu'on a aujourd'hui : WhatsApp, Skype, BBM, iMessage… Et comme le Web a l'époque on avait un standard porté par le W3C qui avait du mal à évoluer à cause de ces différentes pressions (navigateurs utilisant des normes maison, peu de changement, omniprésence de gros acteurs).
Ce qu'on cherche ici à faire (SàT, Movim, Jappix…) c'est de pousser la norme pour offrir aux utilisateurs tout ce qu'ils souhaitent par dessus un protocole standard et universel. Tant qu'on aura pas ce déclic (une masse critique pour être pris au sérieux selon moi) on aura pas la possibilité de pousser cette norme et on restera dans le monde ultra fragmenté qu'est l'IM aujourd'hui.
Mozilla pourrait être, au même niveau qu'avec Firefox pour le Web, l'acteur qui pourrait créer ce déclic. Ils pourraient implémenter correctement XMPP dans Thunderbird, ne pas partir sur des solutions maison pour la messagerie de Firefox, essayer de rapprocher WebRTC et XMPP… mais bon ils ont pas l'air de comprendre que y'a pas que le Web qui a besoin d'utiliser des standards.
D'ailleurs quand je parle de XMPP en tant qu'IM je le limite aussi à tord. XMPP permet aujourd'hui de faire bien plus que de l'IM. Dans Movim par exemple nous voulons montrer qu'on peut l'utiliser en tant que protocole Social et ainsi standardiser des choses aussi basiques que "le flux d'actualité", "des groupes de partage"… XMPP pourrait également à terme remplacer l'email (le structure du réseau est très proche, mais la norme est beaucoup plus moderne et propre que notre bon vieux combo SMTP/POP/IMAP), l'implémentation dans Thunderbird pourrait ici avoir du sens (un bug a été ouvert là dessus d'ailleurs).
Et pour répondre à ta question, oui les processus de standardisation de la XSF sont long et comme disait Goffi nous n'avons pas les mêmes priorités. Donc des fois c'est un peu difficile de montrer vers quoi nous souhaitons faire tendre le protocole.
Par dessus ça on est pas aidé par les autres clients et serveurs XMPP qui pour la plupart ne respectent que peu XMPP (oui oui, mêmes les clients "de référence" libres). Pidgin ne supporte que très peu PEP, Gajim a de fâcheuses tendances à spammer l'utilisateur lorsqu'on utilise Pubsub, la XEP Bookmarks n'est pas utilisée correctement (donc non il n'y a pas de synchronisation entre clients, c'est pourtant pas très compliqué, c'est juste une liste de liens à récupérer et enregister sur le compte du contact…). Coté serveur Goffi l'a bien montré, le support de PEP et Pubsub est bien souvent inexistant, pourtant nous avons réellement besoin de tout ça pour commencer à construire ce que nous souhaitons par dessus.
Donc oui vouloir bien faire les choses en utilisant la norme demande du temps, temps qu'on pourrait passer sur nos projets à construire ce que nous souhaitons.
XMPP est bien plus qu'un protocole de chat. En implémentant correctement des extensions (XEP) XMPP déjà standardisées depuis des années XMPP peut quasiment remplacer nos cher SMTP (voir IMAP sur certains points).
Donc si intégration il y a, utiliser XMPP comme un sérieux protocole de "mail" et l'utiliser dans la vue principale de Thunderbird serait un énorme plus selon mois et offrirait une vraie innovation par rapport à la concurrence.
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.
Imaginons que je veuille partager une photo de moi à poil avec mon amie (pour faire référence à l'affaire #fappening)
Libre à toi de faire ce que tu veux ;)
Je devrai faire confiance à: … En plus de faire confiance que tout ce beau monde chiffre proprement toutes les connections.
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.
Pensez vous que l'avenir soit au déchiffrement sur le terminal utilisateur?
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).
Ou c'est trop compliqué à gérer car l'intelligence coté serveur est essentielle au fonctionnement du bouzin?
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.
Ou on s'en fout, nous sommes des geeks et nous sommes les admins?
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.
Ou la confiance dans les intermédiaires n'est pas un problème?
La confiance des intermédiaires est toujours un problème, surtout dans un réseau aussi répartit et varié. ;)
Posté par edhelas (site web personnel) .
En réponse à la dépêche Movim 0.8.
É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 ;)
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 :)
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).
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 :)
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.
Superbe version avec plein de trucs à tester. Je vois qu'on s'approche de pas mal de fonctionnalités communes entre SàT et Movim ça va être sympa de bosser ensemble là dessus pour voir comment on peut améliorer l'intégration et le standard (je pense particulièrement à Microblog mais pas que…).
On se voit au Summit donc on va avoir un peu de temps de parler de tout ça ;)
je ne connais pas le fonctionnement de XMPP dans le détail donc quand je poste un 'article' ou une photo, où sont-ils stockés ? Il y a un historique me permettant de retrouver/exporter tout ce que j'ai posté ?
Pour l'article il est posté sous la forme Atom directement sur le serveur XMPP (le tiens si c'est sur ton flux, celui que tu as choisit pour un "Groupe"/flux Pubsub public). Dans le cas des photos, vu que les serveurs XMPP ne gèrent pas les données lourdes la photo est envoyé sur un serveur Web (celui où est installé Movim dans ce cas) et un lien est ajouté à l'article en question.
L'historique est sur le serveur XMPP, Movim s'en occupant quand tu te connecte (jusqu'à une certaine limite, je crois que c'est ~40 postes mais cette limite peut être agrandie à l'avenir avec quelques changements dans le code).
vous avez prévu quoi pour le mobile ? J'aime voyager et du temps ou j'étais sur Facebook c'était très pratique de poster des photos "en live" des endroits visités. La possibilité d'en faire autant me paraît indispensable à tout réseau social …
Redimensionne ta fenêtre ;) Movim est responsive-design et s'adapte donc à toutes les résolutions (du smartphone à l'écran full-HD).
Avec XMPP tout est possible…
Pour répondre de façon détaillé je dirais que je ne ferais pas cette "interconnexion" dans Movim. XMPP possède un système appelé "transport" qui permet de faire la liaison au niveau du serveur XMPP. Donc si liaison il y a ça sera par ce moyen car :
- L'implémentation d'autres API est un travail long fastidieux et continuellement changeant (Facebook/Google/Twitter pouvant "casser" des choses de temps à autre).
- Elle sera limitée à Movim, alors que si elle se fait coté serveur tout client XMPP un minimum complet profitera également de ce lien.
- On perd la notion du "un compte pour tout faire"
- Il faut repenser toute la structure de Movim qui est faite pour s'articuler autour de l'unique connexion XMPP
Bref c'est pas au menu, par contre je vais travailler à l'intégration propre de ce module transport pour la prochaine version :)
# Et hop !
Posté par edhelas (site web personnel) . En réponse au journal Codes promo Gandi. Évalué à 3.
A .FR at 50% off Promo code: G15FRH-23F0-40B0-DCAF
A .ME for free Promo code: G15ME-0135-5FB0-CBEE
Voilà pour moi :)
[^] # Re: Le Monde
Posté par edhelas (site web personnel) . En réponse au journal Nan mais stop l'obfuscation du Web. Évalué à 1.
C'est un peu le font-d'écran du jour, comme sur le site de la NASA en fait :D
[^] # Re: oups
Posté par edhelas (site web personnel) . En réponse au message modèle movim pour owncloud ?. Évalué à 1.
Oui mais non.
Le flux est sensé être le même, sauf que celui-ci se synchronise quand l'utilisateur se connecte avec son propre compte.
De plus celui-ci doit déclarer quel article venant de XMPP doit être rendu public sur le pod.
Il n'y aura pas d'intégration de flux RSS à Movim car ce n'est pas le but de celui-ci. Movim n'est qu'un client XMPP "social" et orienté web.
De plus Movim n'a pas vocation à recenser les flux des autres pods (comme le fait Diaspora par exemple) mais de puiser toutes ces informations du réseau XMPP, le seul point de synchronisation pour les données du réseau sera XMPP ;)
# Annuaire
Posté par edhelas (site web personnel) . En réponse au message modèle movim pour owncloud ?. Évalué à 1. Dernière modification le 27 mars 2015 à 13:18.
Pour l'annuaire j'ai construit une petite API qui permet aux administrateurs d'enregistrer leurs serveur sur une liste.
L'API est disponible à cette adresse https://api.movim.eu/ et est implémentée dans l'interface d’administration de Movim depuis la version 0.8 :)
Les différents pods l'utilisent et génèrent une page à partir de ça https://pod.movim.eu/?q=pods.
Je compte travailler dessus ces prochaines semaines pour rendre l'ensemble plus "user friendly".
edhelas
[^] # Re: Chouette projet
Posté par edhelas (site web personnel) . En réponse au journal Devosi & OSI une solution complète Open Source !. Évalué à 3.
Un petit message pour supporter ce petit projet très sympa avec plein de bonnes idées ! N'hésitez pas à aller faire un tour sur les différents services ;)
[^] # Re: Firefox Hello ?
Posté par edhelas (site web personnel) . En réponse au journal De l'autre côté. Évalué à 5.
Quelques petites corrections :)
Oui on a une implémentation très très instable de WebRTC dans Movim, d'ailleurs je pense la désactiver pendant quelques temps le temps de retravailler dessus et de la stabiliser (je préfère avoir un truc qui marche bien qu'un machin qui est présent dans l'interface et qui pose des problèmes/marche une fois sur 20).
Par contre Movim n'a pas remplacé BOSH par WebRTC mais par WebSockets ;) On avait de très très gros soucis de performance avec BOSH (qui "transporte" une connexion XMPP classique sur des requêtes HTTP) et le fait de passer à WebSocket nous apport beaucoup de bonnes choses :
- Temps de connexion très rapide, j'arrive même en dessous des clients bureaux comme Pidgin ou Gajim… pour un truc en PHP :D
- Persistance des sessions, vous pouvez fermer votre navigateur, passer sous un tunnel (physique, pour les tutures, je parle pas de VPN là :p), la session restera ouverte (car tenue coté serveur)
- Possibilité de "bourriner" la connexion, BOSH nous imposait une limite "d'une demande à la fois"
Pour mon avis sur Firefox Hello, j'en ai déjà parlé un peu plus tôt dans la discussion. Je pense que Mozilla se plante à vouloir réinventer la roue et que pour une fondation qui défend la neutralité et les standards c'est marrant de les voir ne pas respecter aucune des deux prérequis (neutralité ? non ils sont entrain de créer leur propre protocole, donc on sera dépendant d'eux pour les choix de spécification). Ils ont déjà implémenté XMPP en partie dans Thunderbird donc qu'on aille pas me dire qu'ils savent pas faire la même chose pour Firefox.
Et l'argument de Goffi sur le possible fait d'utiliser un "transport" XMPP pour communiquer avec eux n'est pas bon. Un transport travaillera toujours ne mode "dégradé" (que ça soit au niveau des performances, des fonctionnalités…) du fait d'avoir à convertir un protocole en un autre. Les librairies de transport sont bien souvent en retard et n'implémentent jamais toutes les fonctionnalités du protocole à transporter.
Donc Mozilla, s'il te plaît, il n'y a pas que le Web qui a besoin de standard, de décentralisation et de neutralité !
[^] # Re: XSF, XEP et XMPP
Posté par edhelas (site web personnel) . En réponse au journal De l'autre côté. Évalué à 6.
Étant développeur du projet Movim j'attends également énormément des ces XEP. C'est assez frustrant d'avoir à "attendre" la norme pour pouvoir bien faire les choses au lieu de tout faire dans notre coins et perdre la compatibilité avec les autres.
De mon point de vue je vois la messagerie instantanée d'aujourd'hui comme était le Web au début des années 2000 : fragmenté, bourré de "trucs maisons/proprio" et quasiment impossible à unifier. Ici je parle surtout de la flopée de clients de messagerie qu'on a aujourd'hui : WhatsApp, Skype, BBM, iMessage… Et comme le Web a l'époque on avait un standard porté par le W3C qui avait du mal à évoluer à cause de ces différentes pressions (navigateurs utilisant des normes maison, peu de changement, omniprésence de gros acteurs).
Ce qu'on cherche ici à faire (SàT, Movim, Jappix…) c'est de pousser la norme pour offrir aux utilisateurs tout ce qu'ils souhaitent par dessus un protocole standard et universel. Tant qu'on aura pas ce déclic (une masse critique pour être pris au sérieux selon moi) on aura pas la possibilité de pousser cette norme et on restera dans le monde ultra fragmenté qu'est l'IM aujourd'hui.
Mozilla pourrait être, au même niveau qu'avec Firefox pour le Web, l'acteur qui pourrait créer ce déclic. Ils pourraient implémenter correctement XMPP dans Thunderbird, ne pas partir sur des solutions maison pour la messagerie de Firefox, essayer de rapprocher WebRTC et XMPP… mais bon ils ont pas l'air de comprendre que y'a pas que le Web qui a besoin d'utiliser des standards.
D'ailleurs quand je parle de XMPP en tant qu'IM je le limite aussi à tord. XMPP permet aujourd'hui de faire bien plus que de l'IM. Dans Movim par exemple nous voulons montrer qu'on peut l'utiliser en tant que protocole Social et ainsi standardiser des choses aussi basiques que "le flux d'actualité", "des groupes de partage"… XMPP pourrait également à terme remplacer l'email (le structure du réseau est très proche, mais la norme est beaucoup plus moderne et propre que notre bon vieux combo SMTP/POP/IMAP), l'implémentation dans Thunderbird pourrait ici avoir du sens (un bug a été ouvert là dessus d'ailleurs).
Et pour répondre à ta question, oui les processus de standardisation de la XSF sont long et comme disait Goffi nous n'avons pas les mêmes priorités. Donc des fois c'est un peu difficile de montrer vers quoi nous souhaitons faire tendre le protocole.
Par dessus ça on est pas aidé par les autres clients et serveurs XMPP qui pour la plupart ne respectent que peu XMPP (oui oui, mêmes les clients "de référence" libres). Pidgin ne supporte que très peu PEP, Gajim a de fâcheuses tendances à spammer l'utilisateur lorsqu'on utilise Pubsub, la XEP Bookmarks n'est pas utilisée correctement (donc non il n'y a pas de synchronisation entre clients, c'est pourtant pas très compliqué, c'est juste une liste de liens à récupérer et enregister sur le compte du contact…). Coté serveur Goffi l'a bien montré, le support de PEP et Pubsub est bien souvent inexistant, pourtant nous avons réellement besoin de tout ça pour commencer à construire ce que nous souhaitons par dessus.
Donc oui vouloir bien faire les choses en utilisant la norme demande du temps, temps qu'on pourrait passer sur nos projets à construire ce que nous souhaitons.
[^] # Re: Messagerie instant tanné
Posté par edhelas (site web personnel) . En réponse au journal Du nouveau pour Thunderbird !. Évalué à 9.
XMPP est bien plus qu'un protocole de chat. En implémentant correctement des extensions (XEP) XMPP déjà standardisées depuis des années XMPP peut quasiment remplacer nos cher SMTP (voir IMAP sur certains points).
Donc si intégration il y a, utiliser XMPP comme un sérieux protocole de "mail" et l'utiliser dans la vue principale de Thunderbird serait un énorme plus selon mois et offrirait une vraie innovation par rapport à la concurrence.
Le bug en question https://bugzilla.mozilla.org/show_bug.cgi?id=385758 ;)
# Transformée Mojette
Posté par edhelas (site web personnel) . En réponse au journal QRaidCODE, stocker des données sécurisée sur qrcodes. Évalué à 4.
Pour faire un peu de pub tu devrais aussi être intéressé par la Transformée Mojette (http://fr.wikipedia.org/wiki/Transform%C3%A9e_Mojette). C'est super simple à comprendre ;)
[^] # Re: 129 contacts
Posté par edhelas (site web personnel) . En réponse à la dépêche Gajim 0.16 sort de terre. Évalué à 4.
J'en ai 224 sur ma propre liste :) C'est pas si difficile de trouver du monde avec un JID… surtout chez les libristes.
[^] # Re: Jingle?
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Réseaux sociaux et données privées
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: sqlite
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Conservation de ses données en cas de changement de POD
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Jingle?
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Mmh
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Droits
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Conservation de ses données en cas de changement de POD
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: Super mais....
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. Évalué à 1.
Oui je vais essayer de corriger ça ;)
[^] # Re: Conservation de ses données en cas de changement de POD
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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: sqlite
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim 0.8. É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.
# Super !
Posté par edhelas (site web personnel) . En réponse à la dépêche Salut à Toi, version 0.5. Évalué à 7.
Coucou Goffi :)
Superbe version avec plein de trucs à tester. Je vois qu'on s'approche de pas mal de fonctionnalités communes entre SàT et Movim ça va être sympa de bosser ensemble là dessus pour voir comment on peut améliorer l'intégration et le standard (je pense particulièrement à Microblog mais pas que…).
On se voit au Summit donc on va avoir un peu de temps de parler de tout ça ;)
edhelas
# Hopla !
Posté par edhelas (site web personnel) . En réponse à la dépêche Logiciel libre à la braderie de Lille 2014. Évalué à 5.
Je retourne ce weekend voir un cousin sur Lille, on a prévu de faire la braderie, ça sera l'occasion de passer vous voir :)
[^] # Re: C'est très joli
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 1.
Pour l'article il est posté sous la forme Atom directement sur le serveur XMPP (le tiens si c'est sur ton flux, celui que tu as choisit pour un "Groupe"/flux Pubsub public). Dans le cas des photos, vu que les serveurs XMPP ne gèrent pas les données lourdes la photo est envoyé sur un serveur Web (celui où est installé Movim dans ce cas) et un lien est ajouté à l'article en question.
L'historique est sur le serveur XMPP, Movim s'en occupant quand tu te connecte (jusqu'à une certaine limite, je crois que c'est ~40 postes mais cette limite peut être agrandie à l'avenir avec quelques changements dans le code).
Redimensionne ta fenêtre ;) Movim est responsive-design et s'adapte donc à toutes les résolutions (du smartphone à l'écran full-HD).
[^] # Re: C'est un super projet
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 1.
Avec XMPP tout est possible…
Pour répondre de façon détaillé je dirais que je ne ferais pas cette "interconnexion" dans Movim. XMPP possède un système appelé "transport" qui permet de faire la liaison au niveau du serveur XMPP. Donc si liaison il y a ça sera par ce moyen car :
- L'implémentation d'autres API est un travail long fastidieux et continuellement changeant (Facebook/Google/Twitter pouvant "casser" des choses de temps à autre).
- Elle sera limitée à Movim, alors que si elle se fait coté serveur tout client XMPP un minimum complet profitera également de ce lien.
- On perd la notion du "un compte pour tout faire"
- Il faut repenser toute la structure de Movim qui est faite pour s'articuler autour de l'unique connexion XMPP
Bref c'est pas au menu, par contre je vais travailler à l'intégration propre de ce module transport pour la prochaine version :)