avant de tordre le protocole pour en faire du blog, du micro-blog ou autre,
On ne tort rien, lis les XEPs, tu verras qu'il n'y a rien d'alambiqué.
il serait sympa de le voir devenir un protocole de chat de qualité (ce qui est la fonction première du protocole).
Et c'est le cas il me semble. Il y a des contraintes technologiques qui sont arrivés en chemin avec les appareils mobiles, il y a eu une petite phase d'adaptation qui semble logique.
mais dans la vraie vie il ne marche pas.
C'est faux
Techniquement le principe des extensions est un poids pour l'utilisation (il faut avoir les bonnes versions de client et de serveurs, qui soient configurés correctement, il y a plusieurs façon de faire la même chose, tu as des implémentations qui font leur propre trucs en dehors du standard par exemple le temps que le standard évolue).
Non c'est un énorme avantage. C'est encore une mauvaise compréhension du fonctionnement : les extensions permettent aux dévs de se mettre d'accord sur la façon de faire les choses, et d'éviter justement que chacun fasse une solution dans son coin. Il y a parfois plusieurs extensions expérimentales qui font la même chose oui, car quand une solution se révèle en pratique non valable, on en propose une nouvelle qui prend en compte l'expérience, pour au final arriver à une qui deviendra le standard. C'est comme ça qu'on est arrivés à l'excellent Jingle après plusieurs tentatives qui posaient toujours problème.
J'avais fait une réponse longue hier, mais suite à une fausse manip je l'ai perdue bêtement :(
Du coup je vais résumer:
C'est un bon étalon! Dans un autre post, tu dis toi-même que la masse des utilisateurs passe d'un silo fermé à un autre silo fermé: qu'est-ce qui les fait migrer? Qu'est-ce qui fait qu'un silo s'impose?
La remarque est faite aussi dans ton poste plus haut, je réponds ici pour les 2
ICQ apportait un truc (principalement liste de contact/présence individuelles, sinon ça existait déjà depuis longtemps sur IRC). En dehors de ça, c'est beaucoup par position dominante, méthode pas super éthique, ou budget pub
MSN s'est imposé par Windows
FB Messenger et Gtalk par les positions respective de FB et Google
What's App en balançant l'annuaire perso des utilisateurs à leurs serveurs, sans l'accord des intéressés évidemment
je ne connais pas toutes les histoires des trucs actuels, mais je mise plus sur un succès dû à une grosse puissance marketing qu'à des fonctionnalités, même si je veux bien qu'il y ait parfois des fonctionnalités intéressantes
Il y a quelques projets qui doivent probablement leur succès à de vrais atout techniques, je pense à Skype notamment (au moins au début).
-Existe-t-il un client que je peux conseiller qui implémente tout ça, la vidéo, les groupes, la publication de fichiers, le tout de façon simple? Est-ce que tu as un remplaçant immédiat à proposer pour FB ou G+ avec le même niveau d'intégration?
Non, je suis d'accord que ça pêche au niveau client (et on est quelques un à essayer d'améliorer ça). Mais il y a tout de même de beaux projets, pour la vidéo il y a Jitsi par exemple. Un des intérêts de XMPP c'est qu'on est pas obligés d'avoir tout dans un même logiciel : on peut avoir un logiciel spécialisé vidéo, un autre synchro de fichiers, un 3ème messagerie de groupe, et le tout fonctionne ensemble naturellement.
La plupart des clients ont copié le modèle ICQ, c'est peut-être là le soucis principal.
Quand Jingle a enfin été publié fièrement, c'est un peu comme si tu annonçait l'invention d'un smartphone: pendant que tu te félicites, le monde regarde en disant "ah vous n'êtes arrivés que là?!"
Il y a une mésentente sur jingle (cf. là) : ça n'est pas juste un système de vidéo conférence, c'est une gestion souple de session P2P qui peut servir autant à de la vidéo qu'à faire un système de synchro de fichiers ou à un jeu en réseau. Je ne développais pas encore sur XMPP quand on a commencé à parler de Jingle, et je suis bien content de pouvoir m'en servir aujourd'hui. Comme dit plus tôt, ça a inspiré webRTC, c'est que c'était pas si en retard que tu le penses (d'ailleurs je ne crois pas qu'il y ait beaucoup d'équivalents à l'heure actuelle).
Trop de choix tue le choix. Expliquer que tu peux accéder à tout en utilisant 4 clients différents, et tu fais fuir ton auditoire. Dis-leur "installe cette app et ça roule", là tu as de meilleures chances. Ce n'est pas juste un argument marketing, c'est le bénéfice de la simplicité.
En le présentant comme ça oui. Mais en disant que tu te connectes une fois, et qu'ensuite tu peux partager des musiques dans Amarok, collaborer dans un fichier texte avec LibreOffice, communiquer sur ton logiciel de chat, faire de la vidéo avec Jitsi, etc, ça semble plus naturel. Tout est déjà possible ou presque en l'état (Abiword et Inkscape on déjà permis de faire ça - je ne sais pas si c'est toujours le cas -, tandis que mes exemples avec Amarok et LibreOffice sont des vues d'esprit).
Dans le monde proprio c'est même pire au final : regarde le nombre de client différents (et incompatibles) pour faire de la messagerie. Pour fonctionner, il faut que quelqu'un dise « on utilise tel truc, tel truc et tel truc ».
Dans une bulle fermée (la mode est de dire « silo » de nos jours), l'intérêt du réseau est clairement directement lié au nombre d'utilisateurs, vu que tu ne peux parler qu'avec eux.
Ce qu'on essaye de faire, c'est justement de faire tomber ce genre de schéma pour que tu puisses discuter avec des gens même si t'as un réseau de 10 personnes (ou 1 !), comme le courrier électronique. On a du mal depuis des années parce que la plupart des gens vont de bulles fermées en bulles fermées (c'était une des raisons d'être des passerelles), mais avec ceux qui utilisent des standards (comme IRC), ça marche sans problème.
Dans tout ce que cite Nÿco, quelles sont les fonctionnalités présentes dans XMPP que n'ont pas déjà les autres, et pire: qu'ils ont eu bien avant XMPP?
La question est posée à l'envers, Nÿco parle des autres technos, donc de fonctionnalités déjà implémentées, et il y en a plusieurs ou XMPP était soit le premier soit les as eu relativement tôt (correction du dernier message, backlog, multi-appareils, etc). Je ne sais pas si c'est vraiment un bon étalon de toute façon.
Encore une fois, je lis surtout une liste des choses sur lesquelles XMPP tente de rattraper son retard. Pour que ça marche, XMPP devrait être au contraire, à la pointe, à l'innovation, là où les autres ne sont pas encore!
Je pense que c'est le cas. Au niveau messagerie instantanée, MIX est un pas en avant incontestable, nous sommes en train de réinventer le blog, jingle est une très bonne couche au point que ça a inspiré webRTC. Je ne vois aucun retard irrattrapable, et je vois pas mal de chemins excitants à l'heure actuelle.
Réponse: on s'en fout tant que les standards permettent de passer d'un outil à l'autre
Tu es en plein dans l'intérêt principal de XMPP
XMPP a désespérément besoin d'UN champion qui serait l'implémentation de référence et le choix par défaut pour les utilisateurs lambda.
Ça n'est pas un problème et c'est même une bonne chose qu'il y ait plein d'outils, ce qu'il faut c'est surtout qu'ils fonctionnent bien entre eux, et que les histoires d'intégrations dont on parle ici comme « nouveau » ne soit qu'un fait tout a fait naturel, et pas un argument marketing.
On ne peut pas "vendre" un protocole, on peut vendre un produit utilisable au quotidien.
En dehors des termes « vendre » et « produit » que je n'aime pas du tout, je suis tout à fait d'accord que c'est les clients finaux et non le protocole qu'il faut mettre en avant auprès du public non technique.
Est-ce que parfois il ne vaudrait pas mieux faire du jetable?
Ça dépend de ce que tu veux faire. Si ton but c'est de grossir au maximum, faire un buzz pour avoir du monde et vendre dès que possible, oui le jetable est intéressant, et même probablement la meilleure option.
J'entends parler de microblogging et de machins sociaux dans xmpp depuis des années et la mode est en train de passer…
Ben le but (du moins le miens), c'est pas suivre les modes, c'est de faire un outil déjà pour nous, et également pour les autres si ça les intéresse. Un blog au final c'est un moyen de publier régulièrement (ou pas) de longs articles a priori travaillés, je pense qu'il y a aura toujours besoin de ça ou alors c'est que le net est voué à se réduire à des vidéos de chats qui se cassent la gueule et à des messages courts sur l'instant (je caricature à peine). Après la forme peut changer : les forums, les blogs, les listes de diffusion voire même Usenet ça se ressemble énormément (un blog c'est plus ou moins un forum centré sur un thème ou une personne), mais le fond est toujours similaire et c'est intéressant d'avoir une technologie qui a des bases solides pour ça.
On parle de blog aujourd'hui parce que c'était un but (atteint) et qu'on a du faire des couches pour ça. Maintenant on peut utiliser les mêmes couches pour faire par exemple un outil de rapport de bogues, un système d'organisation d'événements ou une galerie photo avec des commentaires.
On n'a pas l'impression d'un projet mature qui construit sur des bases solides, mais plutôt d'un truc qui se renouvelle en permanence sans jamais avancer réellement et donc, en est toujours au début.
Qui se renouvelle en permanence oui, mais je trouve que c'est plutôt un avantage. Par contre sans réellement avancer je te trouve bien sévère, je t'invite à lire la série que j'ai écrite sur l'installation et l'utilisation d'un blog XMPP : ceci n'était pas possible il y a encore 1 an.
Pour le chat, beaucoup de critiques qu'on voyait il y a 2 ans ont été réglées depuis (Push, synchronisation entre appareils par exemple). Il y a la vieille marotte du chiffrement de bout en bout qui avance aussi (OX - OpenPGP -, OMEMO, standardisation de l'utilisation d'OTR), mais c'est un sujet très complexe et c'est difficile de trouver une solution parfaite.
Sans même parler du complexe et lourd dans le choix des bons couples clients/serveurs.
Normalement il ne devrait pas y avoir à choisir un couple clients/serveurs, tu devrais pouvoir choisir indépendamment l'un et l'autre. Je vois surtout 2 problèmes ici : les serveurs publiques « historiques » qui n'évoluent pas trop, et du coup sont en retard sur les fonctionnalités, et le blogage qui demande des fonctionnalités bien particulières qui mettent du temps à arriver, mais ça ne concerne pour le moment que Movim et SàT (et on s'adapte s'il n'y a pas ce qu'il faut en face). Mais oui c'est pas parfait.
La présence permanente était réglé depuis bien longtemps par tout un tas de gens avec un irssi dans un screen sur un serveur connecté en permanence.
Ça marche pour un public technique (et ça demande à avoir un serveur en permanence, c'est quand même sacrément lourd et consommateur), mais je vois mal demander à l'association des joueurs de pétanque du midi de faire ça.
Le temps que tout le comité se mette d'accord sur les extensions, la bataille est finie depuis bien longtemps. C'est certainement le plus gros problème qui ruine tout: à vouloir faire vraiment bien, tout arrive beaucoup trop tard.
Si on veut faire du vite et jetable oui, mais justement le but ici est de faire un truc qui tient sur la durée, et dans ce qui est cité par Nÿco, à quelques détails folkloriques près, y'a tout ce qu'il faut pour faire les fonctionnalités indiquées. C'est surtout au niveau client qu'il faut que ça avance, et c'est difficile d'aller aussi vite sur des trucs sur le temps libre qu'une boîte qui a des dizaines de développeurs.
Par contre c'est vrai que ça bloque parfois sur l'évolution des standards : je suis en train en ce moment même d'essayer de pousser à la standardisation des mentions, ça avance mais je me sens franchement seul.
Les extensions c'est super, mais ça veut aussi dire que c'est en permanence la foire pour savoir lesquelles sont implémentées sur quels clients et serveurs.
Il manque peut-être un site qui utilise ces infos pour aider un utilisateur à choisir, il y a des tentatives mais pas encore super intuitives pour un utilisateur final.
Il y a finalement peu de ressources et elles sont très dispersées. Je sais: le Libre c'est le choix, mais si c'était autant dispersé en bureautique on serait encore sur StarOffice.
Il y a le mastodonte LibreOffice qui est le plus visible, mais les ressources sont quand même pas mal dispersées dans ce domaine, entre caligra, abiword, openoffice, les trucs en ligne, etc.
Il y a aussi une émission par des membres de l'april qui était sur radio ici et maintenant aux dernières nouvelles (j'ai plus le nom ni l'horaire en tête, Luc, Manu ou Bookynette si vous passez par là pour compléter), et je ne sais pas s'il y en encore quelque chose sur les radio Larzac ou Dogmazic.
Puis les archives de Symbiose aussi http://symbiose.bonnes-ondes.fr/ avec pas mal de gens d'ici qui sont y sont passés (j'y ai moi même été invité pour une émission sur SàT il y a quelques années).
Avant il y avait Do you hack me sur radio libertaire, mais c'est fini (Drapher étant chez Reflets maintenant cf plus haut), les archives sont là : http://drapher.freeshell.org/?x=y:11;m:07
J'en ai probablement oublié…
P.-S.: il manque SeenThis aussi en très bonne source, pas centré sur le libre mais y'en a de temps en temps.
À supposer que ce soit bien chiffré de bout en bout sans possibilité de déchiffrement dans le serveur, il y a encore de nombreuses possibilités d'analyses:
déjà le client peut faire une analyse sur le téléphone : tu peux envoyer ton message chiffré, mais ton client peut savoir que tu as dis marseille, voyage et août, et avertir le serveur qu'il faut envoyer des pubs sur les boules de pétanque et le Pastis
les métadonnées, comme dit plus haut
le chiffrement n'empêche pas d'envoyer des pubs
et c'est pas Whatapp qui envoit la liste complète des contacts aux serveur ? Niveau vie privée on a vu mieux
d'ailleurs je pense que même sans savoir à qui ont écrit (ce qu'ils savent), savoir avec qui on est en relation est une information extrêment intéressante
comme dit plus haut les bots en effet peuvent aider aussi, surtout que monsieur Z a annoncé qu'il mettait des billes dedans
Bon ce ne sont que des hypothéses, et c'est tout de même une (très) bonne chose que le chiffrement de bout en bout devienne un arguement de poids. Maintenant faudrait faire de même avec standardisation, décentralisation, et surtout code libre.
Oui la reprise de transfert est prévue de base (avec l'ancienne méthode également d'ailleurs). C'est tout à fait adapté, et même pensé pour le transfert de gros fichiers.
il est possible de fournir la somme de contrôle (« hash ») quand on le souhaite, et ainsi la calculer au fur et à mesure
Ah ça c'est super, c'est comme rsync.
Le hash y'a même une XEP dédiée maintenant (la XEP-0300), l'intérêt d'avoir fait ça à part, c'est de pouvoir s'adapter aux méthodes modernes en cas de failles découvertes et de nouvelles recommandations.
Je sais qu'il y a au moins un début d'implémentation pour SliXMPP qui a été conçu pour rester au maximum compatible avec SleekXMPP, donc ça devrait marcher pour les 2. Je fais passer la question à ceux qui s'en occupent pour voir s'ils peuvent compléter.
Sinon le manque d'implémentation il peut y avoir plusieurs raisons. Déjà c'est pas trivial à implémenter, la souplesse du protocole implique qu'il faut bien penser le code pour pouvoir s'adapter à tous les cas, c'est un gros morceau.
Au niveau du transfert de fichiers, c'est pas encore stable, ça rebute certains développeurs de clients, ou alors ils ne voient pas l'intérêt parce qu'ils ont déjà stream initiation (l'ancienne méthode).
Pour la visioconférence, ça peut bloquer parce qu'on se dit qu'il y a beaucoup à faire : Jingle est une première couche déjà pas simple, mais après y'a toutes les questions de gestion de formats vidéos, de débit, de performances, etc. C'est un autre domaine que la messagerie texte de base.
C'est vraiment dommage qu'il n'y ait pas plus d'implémentations en effet, quand on voit tout ce que Jingle permet de faire, j'espère que la vague de nouveauté actuelle va motiver du monde (à bon entendeur…).
Pyjamas est mort (cf. ce commentaire). La solution la plus prometteuse pour Python dans un navigateur à l'heure actuelle semble être Brython, et là aucune idée si wasm peut apporter quelque chose ou est envisagé…
Ça parle de plugin Firefox qui est peut-être sorti depuis. Bref, c'est super de voir un tel outil arriver, j'aimerais beaucoup l'intégrer à SàT d'ailleurs à terme.
En fait Blender a plusieurs modules, et celui dont je parle, le « Video Sequence Editor », peut être utilisé entièrement en dehors de la partie modélisation. Ça fait un peu peur quand on voit la première fois, mais au final tu importes les vidéos, les déplaces où tu veux, applique tes effets etc très facilement. Quand tu connais déjà les raccourcis de Blender c'est sûr que ça aide bien. Ça lit un grand nombre de format, c'est stable et puissant.
Il y aussi le « node editor » pour faire du compositing ou le « movie clip editor » pour faire du tracking et par exemple stabiliser une vidéo, mais ça c'est déjà compliqué à prendre en main (enfin pas tant que ça non plus).
Tout ça XMPP le fait déjà également (il est parfaitement possible de passer par Tor — faut pas mettre les majuscules, sinon y'a les gars de nos oignons qui nous enguelent ;) — ça fait même un moment qu'on parle d'une version spécialisée de SàT qui fait ça directement).
Ce qui avait l'air intéressant sur Ricochet quand j'avais regardé (mais pas testé), c'est qu'il ajoute du bruit pour rendre plus difficile l'analyse du trafic. Sûrement utile dans les cas très sensibles, mais ça me semble à double tranchant sur l'utilisation des ressources processeur/réseau (encore une fois pas testé).
Pour ma part, je vois un inconvénient principal : on devient dépendant du serveur qui maintient notre JID. Que ce soit le nôtre ou pas. Typiquement, j'ai un compte sur jabber.fr, que je n'utilise plus, parce que les certificats SSL n'ont pas été renouvelés. La migration vers un autre serveur est trop coûteuse pour que j'en voit l'intérêt.
C'est surtout du nom de domaine que tu dépends, si tu veux pouvoir bouger facilement, en prendre un et le faire suivre ton serveur est une option. Mais la migration entre les comptes est un truc à travailler en effet.
jabber.fr manque de bras, il n'y a plus qu'un admin actif à ma connaissance, et vu la place du serveur (souvent le premier sur lequel on tombe quand on est francophone), un coup de main serait sans doute très apprécié.
Comparé a IRC, peu importe le serveur sur lequel je me connecte, ça marche toujours aussi bien.
XMPP est capable de fonctionner de la même façon, avec les connexions « anonymes » (anonymes parce que pas de JID fixe, aucun rapport avec l'anonymat à la TOR). Et là aussi c'est d'autres admins qui gèrent les certificats ou état du serveur (et c'est même pire parce que les salons sont très liés aux serveurs).
Alors certes, IRC n'offre pas le même service, mais finalement ça me convient mieux.
IRC fait sont boulot depuis plusieurs dizaines d'années, si ça te convient c'est très bien, rien à redire dessus.
XMPP bien plus que de la messagerie, comme je le répète régulièrement, en ce moment on le montre avec son utilisation pour du blogage.
Ben en fait c'est déjà plus ou moins ce qu'il passe qu'on on utilise XMPP à travers TOR. Un nom de domaine reste adapté, c'est juste qu'il est lié à un autre système que l'actuel. À l'heure actuelle tu peux même utiliser une IP directement si tu veux.
XMPP n'est pas forcément lié à TCP, il y a tout un tas de possibilités envisageables.
Pour les autres problèmes, je ne vais pas supputer, du 100% pair à pair n'est clairement pas ma priorité pour le moment, il y a d'autres problèmes à régler avant, et comme je l'ai dit plus haut un serveur intermédiaire a de nombreux avantages et je pense qu'à l'heure actuelle c'est préférable. Dans l'idéal, il serait possible dans le futur de choisir 100% P2P ou avec serveur intermédiaire, mais bon on n'en est pas là.
Dans le premier cas, il reste un "centre" qui échappe à l'utilisateur. Dans le second, le poids de la mise en place et de l'entretien de ce "centre" lui incombe. Aucun de ces horizons ne me semble désirable au point de ne pas investiguer celui des services distribués, pour justement, entre autre, envisager leurs limitations. C'est de la prospective.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Je vois Tox, ring.cx et ricochet comme outsiders. Si tu as le temps, je serais ravi - et probablement pas que moi - d'avoir ton avis sur ces derniers.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).
déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
Une solution simple consiste à partager le répertoire également avec une machine C qui reste allumée entre temps
En gros tu mets un serveur en place…
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
Avec Syncthing: pas de nom d'utilisateur, pas de mot de passe, tout passe par des clés, des hashs, et des QR codes très pratiques.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)
[^] # Re: XMPP en une phrase
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 4. Dernière modification le 24 avril 2016 à 11:45.
On ne tort rien, lis les XEPs, tu verras qu'il n'y a rien d'alambiqué.
Et c'est le cas il me semble. Il y a des contraintes technologiques qui sont arrivés en chemin avec les appareils mobiles, il y a eu une petite phase d'adaptation qui semble logique.
C'est faux
Non c'est un énorme avantage. C'est encore une mauvaise compréhension du fonctionnement : les extensions permettent aux dévs de se mettre d'accord sur la façon de faire les choses, et d'éviter justement que chacun fasse une solution dans son coin. Il y a parfois plusieurs extensions expérimentales qui font la même chose oui, car quand une solution se révèle en pratique non valable, on en propose une nouvelle qui prend en compte l'expérience, pour au final arriver à une qui deviendra le standard. C'est comme ça qu'on est arrivés à l'excellent Jingle après plusieurs tentatives qui posaient toujours problème.
[^] # Re: Faiblesses de XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 4.
J'avais fait une réponse longue hier, mais suite à une fausse manip je l'ai perdue bêtement :(
Du coup je vais résumer:
La remarque est faite aussi dans ton poste plus haut, je réponds ici pour les 2
ICQ apportait un truc (principalement liste de contact/présence individuelles, sinon ça existait déjà depuis longtemps sur IRC). En dehors de ça, c'est beaucoup par position dominante, méthode pas super éthique, ou budget pub
MSN s'est imposé par Windows
FB Messenger et Gtalk par les positions respective de FB et Google
What's App en balançant l'annuaire perso des utilisateurs à leurs serveurs, sans l'accord des intéressés évidemment
je ne connais pas toutes les histoires des trucs actuels, mais je mise plus sur un succès dû à une grosse puissance marketing qu'à des fonctionnalités, même si je veux bien qu'il y ait parfois des fonctionnalités intéressantes
Il y a quelques projets qui doivent probablement leur succès à de vrais atout techniques, je pense à Skype notamment (au moins au début).
Non, je suis d'accord que ça pêche au niveau client (et on est quelques un à essayer d'améliorer ça). Mais il y a tout de même de beaux projets, pour la vidéo il y a Jitsi par exemple. Un des intérêts de XMPP c'est qu'on est pas obligés d'avoir tout dans un même logiciel : on peut avoir un logiciel spécialisé vidéo, un autre synchro de fichiers, un 3ème messagerie de groupe, et le tout fonctionne ensemble naturellement.
La plupart des clients ont copié le modèle ICQ, c'est peut-être là le soucis principal.
Il y a une mésentente sur jingle (cf. là) : ça n'est pas juste un système de vidéo conférence, c'est une gestion souple de session P2P qui peut servir autant à de la vidéo qu'à faire un système de synchro de fichiers ou à un jeu en réseau. Je ne développais pas encore sur XMPP quand on a commencé à parler de Jingle, et je suis bien content de pouvoir m'en servir aujourd'hui. Comme dit plus tôt, ça a inspiré webRTC, c'est que c'était pas si en retard que tu le penses (d'ailleurs je ne crois pas qu'il y ait beaucoup d'équivalents à l'heure actuelle).
En le présentant comme ça oui. Mais en disant que tu te connectes une fois, et qu'ensuite tu peux partager des musiques dans Amarok, collaborer dans un fichier texte avec LibreOffice, communiquer sur ton logiciel de chat, faire de la vidéo avec Jitsi, etc, ça semble plus naturel. Tout est déjà possible ou presque en l'état (Abiword et Inkscape on déjà permis de faire ça - je ne sais pas si c'est toujours le cas -, tandis que mes exemples avec Amarok et LibreOffice sont des vues d'esprit).
Dans le monde proprio c'est même pire au final : regarde le nombre de client différents (et incompatibles) pour faire de la messagerie. Pour fonctionner, il faut que quelqu'un dise « on utilise tel truc, tel truc et tel truc ».
[^] # Re: Faiblesses de XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 6.
Dans une bulle fermée (la mode est de dire « silo » de nos jours), l'intérêt du réseau est clairement directement lié au nombre d'utilisateurs, vu que tu ne peux parler qu'avec eux.
Ce qu'on essaye de faire, c'est justement de faire tomber ce genre de schéma pour que tu puisses discuter avec des gens même si t'as un réseau de 10 personnes (ou 1 !), comme le courrier électronique. On a du mal depuis des années parce que la plupart des gens vont de bulles fermées en bulles fermées (c'était une des raisons d'être des passerelles), mais avec ceux qui utilisent des standards (comme IRC), ça marche sans problème.
[^] # Re: XMPP en une phrase
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 5.
Tu devrais jeter un œil à Poezio, vraiment. Tu le lances, pas de comptes a créer (mais tu peux si tu veux), et ça fonctionne.
ça marche aussi chez nous ;) ou avec un lien xmpp: xmpp:sat@chat.jabberfr.org?join.
[^] # Re: Faiblesses de XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 5.
La question est posée à l'envers, Nÿco parle des autres technos, donc de fonctionnalités déjà implémentées, et il y en a plusieurs ou XMPP était soit le premier soit les as eu relativement tôt (correction du dernier message, backlog, multi-appareils, etc). Je ne sais pas si c'est vraiment un bon étalon de toute façon.
Je pense que c'est le cas. Au niveau messagerie instantanée, MIX est un pas en avant incontestable, nous sommes en train de réinventer le blog, jingle est une très bonne couche au point que ça a inspiré webRTC. Je ne vois aucun retard irrattrapable, et je vois pas mal de chemins excitants à l'heure actuelle.
Tu es en plein dans l'intérêt principal de XMPP
Ça n'est pas un problème et c'est même une bonne chose qu'il y ait plein d'outils, ce qu'il faut c'est surtout qu'ils fonctionnent bien entre eux, et que les histoires d'intégrations dont on parle ici comme « nouveau » ne soit qu'un fait tout a fait naturel, et pas un argument marketing.
En dehors des termes « vendre » et « produit » que je n'aime pas du tout, je suis tout à fait d'accord que c'est les clients finaux et non le protocole qu'il faut mettre en avant auprès du public non technique.
[^] # Re: Faiblesses de XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 8.
Ça dépend de ce que tu veux faire. Si ton but c'est de grossir au maximum, faire un buzz pour avoir du monde et vendre dès que possible, oui le jetable est intéressant, et même probablement la meilleure option.
Ben le but (du moins le miens), c'est pas suivre les modes, c'est de faire un outil déjà pour nous, et également pour les autres si ça les intéresse. Un blog au final c'est un moyen de publier régulièrement (ou pas) de longs articles a priori travaillés, je pense qu'il y a aura toujours besoin de ça ou alors c'est que le net est voué à se réduire à des vidéos de chats qui se cassent la gueule et à des messages courts sur l'instant (je caricature à peine). Après la forme peut changer : les forums, les blogs, les listes de diffusion voire même Usenet ça se ressemble énormément (un blog c'est plus ou moins un forum centré sur un thème ou une personne), mais le fond est toujours similaire et c'est intéressant d'avoir une technologie qui a des bases solides pour ça.
On parle de blog aujourd'hui parce que c'était un but (atteint) et qu'on a du faire des couches pour ça. Maintenant on peut utiliser les mêmes couches pour faire par exemple un outil de rapport de bogues, un système d'organisation d'événements ou une galerie photo avec des commentaires.
[^] # Re: XMPP en une phrase
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 9.
Qui se renouvelle en permanence oui, mais je trouve que c'est plutôt un avantage. Par contre sans réellement avancer je te trouve bien sévère, je t'invite à lire la série que j'ai écrite sur l'installation et l'utilisation d'un blog XMPP : ceci n'était pas possible il y a encore 1 an.
Pour le chat, beaucoup de critiques qu'on voyait il y a 2 ans ont été réglées depuis (Push, synchronisation entre appareils par exemple). Il y a la vieille marotte du chiffrement de bout en bout qui avance aussi (OX - OpenPGP -, OMEMO, standardisation de l'utilisation d'OTR), mais c'est un sujet très complexe et c'est difficile de trouver une solution parfaite.
Normalement il ne devrait pas y avoir à choisir un couple clients/serveurs, tu devrais pouvoir choisir indépendamment l'un et l'autre. Je vois surtout 2 problèmes ici : les serveurs publiques « historiques » qui n'évoluent pas trop, et du coup sont en retard sur les fonctionnalités, et le blogage qui demande des fonctionnalités bien particulières qui mettent du temps à arriver, mais ça ne concerne pour le moment que Movim et SàT (et on s'adapte s'il n'y a pas ce qu'il faut en face). Mais oui c'est pas parfait.
Ça marche pour un public technique (et ça demande à avoir un serveur en permanence, c'est quand même sacrément lourd et consommateur), mais je vois mal demander à l'association des joueurs de pétanque du midi de faire ça.
[^] # Re: Faiblesses de XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les trois générations de messagerie instantanée. Évalué à 7. Dernière modification le 23 avril 2016 à 10:32.
Si on veut faire du vite et jetable oui, mais justement le but ici est de faire un truc qui tient sur la durée, et dans ce qui est cité par Nÿco, à quelques détails folkloriques près, y'a tout ce qu'il faut pour faire les fonctionnalités indiquées. C'est surtout au niveau client qu'il faut que ça avance, et c'est difficile d'aller aussi vite sur des trucs sur le temps libre qu'une boîte qui a des dizaines de développeurs.
Par contre c'est vrai que ça bloque parfois sur l'évolution des standards : je suis en train en ce moment même d'essayer de pousser à la standardisation des mentions, ça avance mais je me sens franchement seul.
http://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-3-le-coeur-et-les-extensions-suite
Il manque peut-être un site qui utilise ces infos pour aider un utilisateur à choisir, il y a des tentatives mais pas encore super intuitives pour un utilisateur final.
Il y a le mastodonte LibreOffice qui est le plus visible, mais les ressources sont quand même pas mal dispersées dans ce domaine, entre caligra, abiword, openoffice, les trucs en ligne, etc.
# Bonne idée
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mes ressources francophones autour du Libre. Évalué à 3. Dernière modification le 21 avril 2016 à 09:58.
Bonne idée ça ! On peut ajouter les radios, au moins l'écho des Gnous sur radio campus Lille (http://ludovic.grossard.fr/feed/podcast/lecho-des-gnous) et la toute jeune et prometteuse libr@toi (https://libre-a-toi.org/).
Il y a aussi une émission par des membres de l'april qui était sur radio ici et maintenant aux dernières nouvelles (j'ai plus le nom ni l'horaire en tête, Luc, Manu ou Bookynette si vous passez par là pour compléter), et je ne sais pas s'il y en encore quelque chose sur les radio Larzac ou Dogmazic.
Y'a Reflets qui fait des radios de temps en temps (https://reflets.info/category/radioreflets/).
Puis les archives de Symbiose aussi http://symbiose.bonnes-ondes.fr/ avec pas mal de gens d'ici qui sont y sont passés (j'y ai moi même été invité pour une émission sur SàT il y a quelques années).
Avant il y avait Do you hack me sur radio libertaire, mais c'est fini (Drapher étant chez Reflets maintenant cf plus haut), les archives sont là : http://drapher.freeshell.org/?x=y:11;m:07
J'en ai probablement oublié…
P.-S.: il manque SeenThis aussi en très bonne source, pas centré sur le libre mais y'en a de temps en temps.
[^] # Re: euh...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal JARR v1. Évalué à 5.
Y'a plus qu'à implémenter l'accès via XMPP (cf. ici)
# tant qu'on y est
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Écouter la radio. Évalué à 5.
je file mon vieux script, qui se contente de lancer la station (radio [nom_station]):
et dans ~/radios y'a des listes de lecture avec les noms des radios
Pendant que j'y suis pour sauvegarder le prochain bulletin france info :
# modèle économique
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal WhatsApp active le chiffrement de bout en bout. Évalué à 4.
À supposer que ce soit bien chiffré de bout en bout sans possibilité de déchiffrement dans le serveur, il y a encore de nombreuses possibilités d'analyses:
déjà le client peut faire une analyse sur le téléphone : tu peux envoyer ton message chiffré, mais ton client peut savoir que tu as dis marseille, voyage et août, et avertir le serveur qu'il faut envoyer des pubs sur les boules de pétanque et le Pastis
les métadonnées, comme dit plus haut
le chiffrement n'empêche pas d'envoyer des pubs
et c'est pas Whatapp qui envoit la liste complète des contacts aux serveur ? Niveau vie privée on a vu mieux
d'ailleurs je pense que même sans savoir à qui ont écrit (ce qu'ils savent), savoir avec qui on est en relation est une information extrêment intéressante
comme dit plus haut les bots en effet peuvent aider aussi, surtout que monsieur Z a annoncé qu'il mettait des billes dedans
Bon ce ne sont que des hypothéses, et c'est tout de même une (très) bonne chose que le chiffrement de bout en bout devienne un arguement de poids. Maintenant faudrait faire de même avec standardisation, décentralisation, et surtout code libre.
[^] # Re: Implémentations python
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite). Évalué à 2.
Ah et j'oubliais, il y a bien sûr Gajim qui a une implé, et qui est en Python.
[^] # Re: Gros fichiers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite). Évalué à 3.
Oui la reprise de transfert est prévue de base (avec l'ancienne méthode également d'ailleurs). C'est tout à fait adapté, et même pensé pour le transfert de gros fichiers.
Le hash y'a même une XEP dédiée maintenant (la XEP-0300), l'intérêt d'avoir fait ça à part, c'est de pouvoir s'adapter aux méthodes modernes en cas de failles découvertes et de nouvelles recommandations.
[^] # Re: Implémentations python
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite). Évalué à 2.
Je sais qu'il y a au moins un début d'implémentation pour SliXMPP qui a été conçu pour rester au maximum compatible avec SleekXMPP, donc ça devrait marcher pour les 2. Je fais passer la question à ceux qui s'en occupent pour voir s'ils peuvent compléter.
Sinon le manque d'implémentation il peut y avoir plusieurs raisons. Déjà c'est pas trivial à implémenter, la souplesse du protocole implique qu'il faut bien penser le code pour pouvoir s'adapter à tous les cas, c'est un gros morceau.
Au niveau du transfert de fichiers, c'est pas encore stable, ça rebute certains développeurs de clients, ou alors ils ne voient pas l'intérêt parce qu'ils ont déjà stream initiation (l'ancienne méthode).
Pour la visioconférence, ça peut bloquer parce qu'on se dit qu'il y a beaucoup à faire : Jingle est une première couche déjà pas simple, mais après y'a toutes les questions de gestion de formats vidéos, de débit, de performances, etc. C'est un autre domaine que la messagerie texte de base.
C'est vraiment dommage qu'il n'y ait pas plus d'implémentations en effet, quand on voit tout ce que Jingle permet de faire, j'espère que la vague de nouveauté actuelle va motiver du monde (à bon entendeur…).
[^] # Re: Normal !
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Bash dans Windows. Évalué à 4.
En tout cas c'est un point sur lequel on ne pourra plus basher Zindoz.
[^] # Re: WebAssembly
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Firefox 45 ESR et autres actualités mozilliennes. Évalué à 5.
Pyjamas est mort (cf. ce commentaire). La solution la plus prometteuse pour Python dans un navigateur à l'heure actuelle semble être Brython, et là aucune idée si wasm peut apporter quelque chose ou est envisagé…
[^] # Re: Si seulement !
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Pour mes problèmes d'orthographe.... Évalué à 5.
Pour Vim je ne sais pas si c'est déjà possible, mais en tout cas l'auteur explique son avancement ici: http://dicollecte.org/thread.php?prj=fr&t=471 (le dernier message date du début du mois, plutôt encourageant), et je suis tombé sur ça aussi pour l'utiliser en ligne de commande : https://blog.sciunto.org/posts/grammalecte_avancement/
Ça parle de plugin Firefox qui est peut-être sorti depuis. Bref, c'est super de voir un tel outil arriver, j'aimerais beaucoup l'intégrer à SàT d'ailleurs à terme.
[^] # Re: Autour de GNOME : Pitivi 0.96 is coming
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Parution de GNOME 3.20 Delhi. Évalué à 7.
En fait Blender a plusieurs modules, et celui dont je parle, le « Video Sequence Editor », peut être utilisé entièrement en dehors de la partie modélisation. Ça fait un peu peur quand on voit la première fois, mais au final tu importes les vidéos, les déplaces où tu veux, applique tes effets etc très facilement. Quand tu connais déjà les raccourcis de Blender c'est sûr que ça aide bien. Ça lit un grand nombre de format, c'est stable et puissant.
Pour donner une idée, c'est avec lui qu'on a monté notre vidéo de campagne : http://ftp.goffi.org/media/video/libervia_arizuka_50%25_hard_sub_fr.webm la prise de son était séparée et c'était trivial de la synchroniser avec.
Il y aussi le « node editor » pour faire du compositing ou le « movie clip editor » pour faire du tracking et par exemple stabiliser une vidéo, mais ça c'est déjà compliqué à prendre en main (enfin pas tant que ça non plus).
[^] # Re: Autour de GNOME : Pitivi 0.96 is coming
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Parution de GNOME 3.20 Delhi. Évalué à 6.
Tu as essayé Blender ? La partie montage vidéo est excellente (comme l'ensemble du logiciel), et très intuitive.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 3.
Tout ça XMPP le fait déjà également (il est parfaitement possible de passer par Tor — faut pas mettre les majuscules, sinon y'a les gars de nos oignons qui nous enguelent ;) — ça fait même un moment qu'on parle d'une version spécialisée de SàT qui fait ça directement).
Ce qui avait l'air intéressant sur Ricochet quand j'avais regardé (mais pas testé), c'est qu'il ajoute du bruit pour rendre plus difficile l'analyse du trafic. Sûrement utile dans les cas très sensibles, mais ça me semble à double tranchant sur l'utilisation des ressources processeur/réseau (encore une fois pas testé).
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 3.
C'est surtout du nom de domaine que tu dépends, si tu veux pouvoir bouger facilement, en prendre un et le faire suivre ton serveur est une option. Mais la migration entre les comptes est un truc à travailler en effet.
jabber.fr manque de bras, il n'y a plus qu'un admin actif à ma connaissance, et vu la place du serveur (souvent le premier sur lequel on tombe quand on est francophone), un coup de main serait sans doute très apprécié.
XMPP est capable de fonctionner de la même façon, avec les connexions « anonymes » (anonymes parce que pas de JID fixe, aucun rapport avec l'anonymat à la TOR). Et là aussi c'est d'autres admins qui gèrent les certificats ou état du serveur (et c'est même pire parce que les salons sont très liés aux serveurs).
IRC fait sont boulot depuis plusieurs dizaines d'années, si ça te convient c'est très bien, rien à redire dessus.
XMPP bien plus que de la messagerie, comme je le répète régulièrement, en ce moment on le montre avec son utilisation pour du blogage.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 2.
Ben en fait c'est déjà plus ou moins ce qu'il passe qu'on on utilise XMPP à travers TOR. Un nom de domaine reste adapté, c'est juste qu'il est lié à un autre système que l'actuel. À l'heure actuelle tu peux même utiliser une IP directement si tu veux.
XMPP n'est pas forcément lié à TCP, il y a tout un tas de possibilités envisageables.
Pour les autres problèmes, je ne vais pas supputer, du 100% pair à pair n'est clairement pas ma priorité pour le moment, il y a d'autres problèmes à régler avant, et comme je l'ai dit plus haut un serveur intermédiaire a de nombreux avantages et je pense qu'à l'heure actuelle c'est préférable. Dans l'idéal, il serait possible dans le futur de choisir 100% P2P ou avec serveur intermédiaire, mais bon on n'en est pas là.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 5.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).
# Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 9. Dernière modification le 24 mars 2016 à 11:37.
Salut,
déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
En gros tu mets un serveur en place…
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)