Goffi a écrit 1523 commentaires

C'est vrai, même si techniquement c'est possible avec MUC + MAM (quand tu te reconnectes, tu peux récupérer l'historique), et je pense que les clients à la Conversations veulent partir dans cette direction.

Je ne suis pas tout à fait convaincu par ça, vu que je pense que le blogage (on dit toujours microblogage parce que la XEP-0277 parle de « microblogging », mais c'est du blogage en fait) fait déjà le job et en mieux : gestion des commentaires, titres, tags, etc. J'ai même un peu peur qu'il y ait volonté d'utiliser le chat de groupe pour faire un « microblogage du pauvre ».

La direction dans laquelle nous on aimerait partir, c'est utiliser le blog comme base, et fournir différentes « vues » à ceux qui le souhaitent, à grands coups de passerelles si nécessaire : comme une liste de diffusion, comme une forum, comme un blog, etc. On a déjà tout ce qu'il faut pour le faire aujourd'hui, sauf le temps disponible (ou les mains disponibles).

Salut,

les exemples donnés dans la XEP sont conversation@mix.example.com ou encore coven@mix.shakespeare.example, où mix.shakespeare.example est un domaine MIX. Très similaire à MUC donc.

Par contre dans MUC les ressources correspondaient aux nicks (par exemple sat@chat.jabberfr.org/goffi pour m'envoyer un message privé sur notre salon), avec MIX ça n'est plus le cas.

de rien :)

P.-S.: désolé pour les typos et autres parenthèses oubliées

Vu que ça n'est pas précisé, je suppose que c'est centralisé ? Ça utilise un protocole standard ? Est-ce à ranger du côté de Elgg ?

Un lien vers une discussion sur le sujet dans les commentaires suite à l'annonce de l'arrêt de Mozilla Persona: https://linuxfr.org/users/tiwaz/journaux/persona-c-est-bientot-la-fin#comment-1638484

On y trouve en particulier le retour d'expérience de Jehan.

Et passer dix ans à discuter de ce qu'elle doit contenir,

Les discussions sont souvent longues oui, parce que le but est de créer des standards qui vont êtres solides et tenir sur la durée. XMPP est un protocole qui est utilisé par beaucoup de logiciels et d'environnements différents, avec souvent des objectifs différents.
C'est plus facile quand on ne doit pas standardiser, qu'on n'a qu'un logiciel, et qu'il suffit d'avoir la même version du logiciel en face pour qu'un truc fonctionne. Ici il faut trouver la solution suffisamment générique et facile à implémenter pour qu'elle convienne à tout le monde.

et finalement avoir deux serveurs qui ne l'implémenteront que partiellement, et sur des fonctions qui ne se recouvrent pas.

Dans ce cas précis, je ne suis pas sûr qu'il y a ait besoin de quoi que ce soit côté serveur XMPP.

Et sinon pour la variété d'extensions, il y a disco pour gérer tout ça. Si tu veux qu'un truc marche sur tous les serveurs, tu peux l'écrire sous forme de composant.
Les développeurs de serveurs implémentent ce qui les intéressent. Si tu as besoin d'un truc qui n'existe pas encore, rien ne t'empêche de l'ajouter sur celui que tu utilises. Pour Prosody par exemple, les greffons communautaires se comptent par centaines, c'est très actif. Il est rare de ne pas trouver ce qu'il te faut quand une XEP est populaire.

Je pensais par rapport aux autres. Entre les projets XMPP (Movim, Jappix et SàT), Diaspora, Gnu Social (qui est je pense le plus ancien du lot, surtout qu'il a mergé avec status.net), et peut-être même Lorea, je pense que Friendica et a fortiori Red Matrix/Hubzilla sont les derniers arrivés.

Si quelqu'un passe au Fosdem, faites moi signe (goffi @ goffi . org).

D’autant plus que je ne vois pas l’intérêt de faire un tel foin de WWW-Authenticate dans cette XEP. C’est uniquement pour que l’utilisateur puisse communiquer son JID au serveur web ; la XEP aurait largement pu dire « pas mon problème, faites comme vous voulez : formulaire classique, WWW-Authenticate ou télépathie ». De ce que je vois, rien ne m’empêche techniquement d’implémenter la XEP en remplaçant le mécanisme WWW-Authenticate par un bête formulaire « entrez votre JID » (ce qui en un sens limite ma critique à la rédaction de la XEP plutôt qu’à la proposition technique en elle-même).

Ce que tu dis a l'air valide en effet. La XEP porte sur des requêtes HTTP, et l'exemple parle de « files.shakespeare.lit » (donc a priori récupérer des fichiers via HTTP), je pense que c'est ce qui a justifié l'utilisation de WWW-Authenticate par rapport à un formulaire ou autre.
La personnalisation peut être un point gênant qui peut justifier l'écriture d'une nouvelle XEP, c'est à réfléchir. C'est intéressant aussi de pouvoir l'utiliser pour toutes les requêtes (l'exemple des fichiers ne serait pas trivial à faire avec un formulaire, mais ce que tu dis semble a priori une bonne solution : « faites comme vous voulez il me faut juste un jid »).

Autre point qui m'embête, la XEP parle d'un élément « confirm » dans un namespace dédié, ce qui veut dire qu'un client qui ne comprend pas la XEP ne pourra pas l'utiliser, alors qu'on aurait pu faire un mécanisme à base de messages textes dans ce cas.

Ce sont des détails qui peuvent être gênants, il faudrait que je me penche sur le problème voire travailler sur une nouvelle XEP, mais pour le moment j'ai d'autres priorités.

Je précise que je l'ai survolée aussi, ce n'est pas une XEP que j'ai implémentée (pour le moment), donc mes réponses sont à prendre avec des pincettes.

• WWW-Authenticate ? Aucune chance ; les éditeurs de sites veulent garder le contrôle sur l’interface de connexion (ne serait-ce que pour offrir des trucs genre une cache à cocher « retenir mon mot de passe », ou un captcha)

Le but c'est justement de ne plus avoir de mot de passe à retenir. Si c'est pour rester identifié, ça doit pouvoir s'automatiser assez facilement une fois que le site web a été accepté.

Le captcha tu peux toujours le demander après (ou avant) l'identification. La XEP dit juste « cette requête HTTP a été associée à ce jid », mais si tu veux en plus être sûr que le jid appartient bien à un humain, rien ne t'empêche d'ajouter des tests.

• ça demande une gestion côté navigateur, ça peut pas être fait en pur JS. Le plugin firefox n’a pas l’air maintenu (et même pas accessible)

Je n'ai pas bien compris ce point, de quel plugin firefox tu parles ? La gestion est côté serveur de ce que j'ai compris, même si le client HTTP intervient, c'est via des comportements standards.

• ça veut dire que mon client xmpp doit tourner au moment où je fais la requête HTTP. Si je suis chez un pote et que je veux accéder à un truc en utilisant son PC, je dois installer un client XMPP dessus ? ça n’a pas l’air très pratique…

Oui tu dois avoir un client XMPP ouvert, mais tu peux utiliser un client web, pas besoin d'installer quoi que ce soit sur la machine de ton pote. C'est la même chose quand tu utilises les solutions propriétaires, il faut bien que le site soit lancé non ? Et en pratique, on a de plus en plus souvent des téléphones avec un client dessus, si c'est le cas tu peux valider l'accès depuis ton téléphone, sans taper ton mot de passe sur une machine que tu ne connais pas.

Ceci dit j'ai donné cette XEP parce que c'est celle qui traite actuellement du problème, mais si elle a des défauts, il est toujours possible d'en faire une nouvelle qui les corrige (Jehan si tu passes par là : qu'a donné ton expérience ?).
Ce que je voulais souligner, c'est que XMPP a tout ce qu'il faut pour faire de la gestion d'identification (ou de partage d'informations via notamment les vcard) de manière décentralisée et simple pour l'utilisateur, et qu'il serait bien de voir ça se développer plutôt que risquer voir des sites où on ne pourra plus se connecter sans Google ou FB.

XMPP le fait, et en décentralisé.

C'est une des choses qu'on essaye de pousser : XMPP gère l'authentification forte, et une XEP explique comment utiliser ça avec un service HTTP (la XEP-0070).

Imaginez pouvoir vous balader partout avec votre jid sans avoir 10000 mots de passe à conserver, pouvoir installer votre serveur très facilement (un Prosody ou un OpenFire sont triviaux à installer), et maîtriser les données que vous voulez rendre accessible.

Jehan bien connu ici avait déjà vu ça il y a plus de 4 ans et fait un plugin pour Wordpress, malheureusement à l'abandon aujourd'hui.

J'ai également proposé cette amélioration sur DLFP, ce qui donnerait peut-être des idées à d'autre sites.

Là peu de risques de voir ça disparaître de sitôt, il faudrait que tous les serveurs et clients XMPP arrêtent le développement.

Si des dév qui travaillent sur des moteurs de blogs, des forums, des systèmes de publication, de microblogage, ou n'importe quel site qui demande une identification me lisent, ça serait super de prendre un week-end pour implémenter ça. Si ça suit, je m'engage à faire l'implémentation dans notre client, et gageons que d'autres clients suivront vite.

Gajim gère la vidéo et la messagerie, c'est a priori le meilleur actuel en client bureau.

Pidgin et Kopete sont 2 clients multi protocoles, et pas particulièrement spécialisés pour XMPP, le problème avec ça c'est que souvent l'implémentation de XMPP est moins bonne que dans un client dédié.

Je crois que Swift est pas mal aussi, et simple à utiliser. Il faut vérifier qu'il gère la vidéo, mais ça vaut le coup de tester…

Niveau serveur si tu ne veux pas héberger le tiens, je te conseille d'en choisir un où tu peux contacter les admins si nécessaire, regarde si tu n'as pas une asso locale qui en dispose. Ça permettra de demander une mise à jour s'il manque un truc, ou de faciliter les choses en cas de changement de serveur.

jabber.fr a changé de certificat, et il est prévu qu'il passe de Ejabberd à Prosody, avec probablement pas mal d'extensions. Il y a d'autre serveur de l'apinc donc certains déjà sous prosody il me semble (demande à Link Mauve sur le salon XMPP xmpp:jabberfr@chat.jabberfr.org?join, c'est l'admin, et d'ailleurs il a besoin d'aide si y'a des gens motivés).

Après à part te donner les listes, c'est difficile à dire aujourd'hui sans utilise soit même le serveur.

Tu peux regarder cette liste aussi: https://www.jabberes.org/servers/ y'a l'uptime et une partie de fonctionnalités indiquée clairement.

Pour le (ou les) clients, ça dépend de ce que tu veux et où tu veux l'utiliser : bureau ? Web ? Téléphone ?
Tu veux vidéo ? Transfert de fichier ? Chiffrement de bout en bout ? Microblogage ?

N'hésite pas à en prendre plusieurs, XMPP est prévu pour fonctionner avec différents logiciels.

C'est un des logiciels que je n'ai pas encore testé, mais il va falloir que j'essaye. Existe-t-il une couche de compatibilité XMPP ? Si oui uniquement pour la messagerie instantanée, ou des choses comme le blogage sont envisagées ?

C'est assez impressionnant de voir le nombre de fonctionnalités annoncé pour un logiciel jeune (mais qui a su se faire une communauté assez important apparemment, nous c'est un point sur lequel on pêche pour le moment), est-ce qu'en pratique c'est fonctionnel, utilisable au quotidien ?

Est-ce qu'il y aura des gens de l'équipe au Fosdem ? On veut essayer de faire une rencontre entre les projets libres de communication, pour voir s'il y a des points où on peut collaborer…

J'ai entendu que pour installer un serveur diaspora le niveau requis était assez haut.

Il me semble que ça a bien évolué, c'est notamment dispo dans Debian sid maintenant.

Mike le fondateur de Hubzilla répète que Hubzilla n'est pas un réseau social.

C'est de toute façon un terme qui ne veut rien dire

Mais c'est vrai que le travail sur le dialogue entre les protocoles est encore à faire la Fédération est encore qu'à ses débuts.

Il y a déjà des protocoles standards pour communiquer.

Demain je rêve d'un module qui intégrera le protocole zot à wordpress peut être avec un plugin. Imaginer que ceux qui auront un compte hubzilla pourrait commenter sans s'authentifier.

C'est (était) déjà possible avec XMPP, Jehan a fait un plugin pour il y a plusieurs années: https://wordpress.org/plugins/xmpp-auth/ (pas mis à jour depuis 4 ans, malheureusement, il ne fonctionne probablement plus).

C'est une des choses qu'on essaye de pousser avec XMPP, et un de nos buts en faisant un moteur de blog décentralisé basé dessus.

La présence des serveurs intermédiaires n'est pas un défaut, bien au contraire, et du P2P c'est juste que serveur et client sont placés au même endroit, cf mon article à ce sujet: http://www.goffi.org/post/2015/11/10/centralis%C3%A9%2C-d%C3%A9centralis%C3%A9%2C-P2P%2C-mais-c-est-quoi-tout-%C3%A7a

Se passer de DNS, réunir client et serveur, ce sont des choses tout à fait envisageables avec des réseaux décentralisés comme XMPP ou Diaspora.

Ça marche très bien avec XMPP, cf https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-3-le-coeur-et-les-extensions-suite

Bien entendu, une fonctionnalités non implémentée ne va pas apparaître par magie, mais le client ou serveur ou autre en face a les moyens de savoir si la fonctionnalités est dispo ou pas, et de s'adapter.

Je ne vois pas le rapport entre être compatible au niveau du protocole est des logiciels identiques.

Kmail, Thunderbird et Mutt sont compatibles à 100 %, pourquoi les nommer différemment ?

Et Jappix aussi, et probablement Buddycloud un jour.

On envisage de faire une passerelle Diaspora en effet, mais ça risque d'attendre un peu (j'espère qu'elle verra le jour en 2016) parce que:

• le protocole de Diaspora n'est pas encore stabilisé, et je ne suis pas sûr que ça suive au niveau doc non plus

• pas encore d'API non plus

Mais il y a la volonté de se rapprocher de part et d'autre (on doit d'ailleurs se retrouver au Fosdem à la fin du mois).

Merci pour cette dépêche, et à tous ceux qui participent à ce site qui reste ma source d'information principale pour ce qui touche au libre et à la technique. J'apprécie beaucoup DLFP pour sa qualité, et par le boulot qui est fait par l'équipe (autant de modération, que pour le code, l'hébergement, et la communauté bien sûr). Linuxfr a su rester un site populaire sans céder aux différentes modes, qui fonctionne sans publicité, qui soutient différentes causes libristes, qui écoute les demandes faites dans le suivi ou les critiques, qui publie son code sous licence libre, etc.

En lisant les dépêches et journaux de l'année, je me demande ce que donnent certains événements avec le recul, par exemple le remplacement de Photoshop par Krita dans une université parisienne : il y a-t-il des retours des étudiants ou professeurs ? Au passage Framablog a récemment publié un entretien avec David Revoy.

Je m'excuse aussi pour les dépêches « Se passer de Google, Facebook et autres big brothers 2.0 », que j'avais commencé, qui ont reçu beaucoup de contributions, mais qui n'ont vu qu'un épisode publié à ce jour. Je manque de temps pour m'en occuper, et je me concentre sur le monde XMPP en ce moment. Je ne sais pas si je vais avoir plus de temps cette année pour ça, même si le sujet m'intéresse, surtout que la campagne Framasoft permet d'appuyer cette série. Si des personnes sont motivées pour prendre la relève…

Bonjour,

quelqu'un peut m'expliquer en quelques lignes ce qu'est Slack et pourquoi c'est à la mode ? C'est un nom que je vois souvent mais je n'ai jamais vu à l'œuvre, et les captures d'écran que je vois ne me semblent pas extraordinaires. Donc qu'est-ce qui est si bien intégré ? Qu'est-ce que ça permet de faire ?

J'en profite pour donner mon avis sur les questions du journal:

• création de compte: il faut choisir un serveur (lequel? pourquoi?)

Ça a déjà été répondu plus haut dans les commentaires. C'est un peu plus compliqué oui, mais c'est une question d'interface d'une part (proposer simplement les serveurs pré-sélectionnés selon des critères comme l'emplacement géographique ou les fonctionnalités, c'est au client à bien gérer ça), et aussi de risque.
Je m'explique : une des extensions XMPP courante permet l'enregistrement automatique par le client sur un serveur, c'est bien ça simplifie la vie. Problème : ça simplifie aussi la vie pour les spammeurs, au point que cette extension est de moins en moins activée, ou carrément que certains serveurs refusent de parler à d'autres qui l'activent (c'est le cas du serveur « officiel » jabber.org qui refuse de parler à jabber.fr parce que ce dernier permet l'enregistrement depuis un client). On n'a pas à ce jour de solution parfaite.

J'aimerais beaucoup voir les associations locales prendre ça en main avec des rencontres physiques/des formations pour les utilisateurs si nécessaire.

• extentionisme, c'est à dire, "c'est pas le coeur du produit, c'est un plugin que ton serveur doit installé". Ah, il n'est pas sur le serveur, alors faut changer… Ex: transfert de fichier, voix, partage d'écran, etc

Alors oui et non. Là c'est XMPP qui est ciblé, et je trouve au contraire que son côté extensible est ce qui fait toute sa force. Les extensions indispensables côté serveur sont rares, et souvent on peut utiliser celle d'un autre serveur.
Ça pêche clairement en ce moment du côté de PubSub (et donc PEP), qui sont à la base de plus en plus de fonctionnalités (comme le blogage), j'espère que ça va s'améliorer avec le temps, et de ce côté je suis d'accord que c'est un problème à l'heure actuelle.
Les exemples que tu cites ne sont par forcément bien choisis vu que ce sont des fonctionnalités liées au client. Le serveur peut toutefois fournir des aides (comme un proxy).

Après si tu veux des choses nouvelles, c'est normal qu'il faille mettre à jour parfois côté serveur. Si tu veux du HTTP2, il faut bien que ton serveur web le gère.

• transfert: procédure complexe pour migrer d'un serveur à un autre.

Tu veux dire sans avoir la main sur les serveurs ? Il y a une question de sécurité, tu ne peux pas réinscrire de force tes contacts à une autre adresse sans leur demander confirmation (quand tu déménages, il faut bien leur donner ta nouvelle adresse postale). Pour ce qui est de l'historique des messages, c'est un cas qui n'est pas encore géré si on n'a pas la main sur le serveur. Quel autre problèmes as-tu pour un changement de serveur ? N'hésite pas à dire ce qui te dérange aux différents développeurs, des fois il suffit de pas grand chose pour améliorer un truc pénible.

Pas encore à ma connaissance mais:

• Hello est basé sur WebRTC, et XMPP/Jingle s'interface bien avec WebRTC (qui est d'ailleurs inspiré de Jingle)

• Tox est documenté (je crois) et il existe des bibliothèques libres pour communiquer avec (au moins pour la messagerie), donc il devrait être assez facile de faire une passerelle

Ceci dit, pour la visioconférence, même si des passerelles sont techniquement possibles, ça n'est pas forcément idéal : c'est une application gourmande en ressources et nécessitant souvent une session P2P, une passerelle est un point de passage limitant cette connexion, et la qualité s'en resentirait forcément.

Pour la messagerie texte par contre, ça ne devrait pas poser de problème (au moins pour Tox, pour Hello je ne sais pas si c'est documenté ou facilement implémentable).

Du coup, doit-on considéré Jabber comme un réseau proposant plusieurs services? Une collection de services? Ou un service aux multiples usages?

Pour moi c'est un ensemble de technologies coordonnées et ré-utilisables. C'est d'ailleurs proche de la philosophie Unix : chaque extension (XEP) fait une seule chose et la fait (ou essaye de la faire) bien.

Comment expliquer cela autour de soi sans faire fuir les gens?

C'est le point le plus difficile. Je ne suis pas sûr qu'il n'est nécessaire d'expliquer à un niveau aussi bas (le protocole) à la plupart des gens, et puis XMPP peut-être utilisé aussi bien par Facebook (plus maintenant je crois) qui ne se privera pas pour analyser tout ce que font et disent les gens que par un logiciel libre comme Gajim qui cherche plutôt à protéger la vie privée.

Aux RMLL on discutait avec Nÿco et Edhelas, qu'il pourrait être intéressant de juste utiliser le logo de XMPP pour montrer une compatibilité entre les logiciels, sans forcément détailler trop la technique qui n'intéressera qu'une frange des utilisateurs.

D'ailleurs ça me fait penser qu'il serait pas mal du tout de faire des variantes du logo, par exemple XMPP/Messagerie Instantanée XMPP/PubSub XMPP/Transfert de fichier XMPP/Visioconférence. Y'a pas des gens doués en dessin/gimp/autre qui auraient des idées ?

Personnellement, je vois ça comme un réseau social fédéré, aux multiples services et applications. Mais est-ce correct?

Oui

C'est clairement XMPP qu'il faut utiliser maintenant, même si personne ne t'en voudra pendant une conversation orale d'utiliser Jabber. Mais j'ai vu des gens demander à ajouter un logiciel dans la liste sur xmpp.org devoir changer le nom dudit logiciel parce qu'il y avait « jabber » dedans (les seuls qui ont le droit d'utiliser « jabber » dans leur nom sont ceux qui l'utilisaient avant le rachat par Cisco et le passage à XMPP si je n'abuse, et Cisco lui-même bien sûr).

Sur Wikipédia ça dépend des gens qui ont écrit l'article, et il doit être intéressant de regarder la page discussion ou l'historique des modifications.

Enfin au final « Jabber » ou « XMPP » on s'en moque un peu, l'important c'est le protocole et les logiciels autour.

C'est envisageable de le faire fonctionner en serveur sur sa propre machine (desktop) ? Niveau charge ce n'est pas trop lourd ?

On n'a pas encore fait beaucoup d'optimisations (ça arrivera quand on sera vers la version grand public, ou en cas de gros soucis de perfs), ni vraiment de profiling, mais a priori c'est pas trop lourd non.

Je voudrais héberger mon réseau social sur ma machine mais pas en permanance. J'ai testé un logiciel qui s'appel Newebe basé sur la même technologie (twisted). J'étais impressionné.

Oui je connais Newebe, l'auteur (Gelnior, qui traîne par ici aussi) est un ami. C'est un bon projet, et en plus il est doué pour l'interface.

Si tu veux utiliser sur bureau sans laisser en permanence, tu seras peut-être plus intéressé par l'interface de bureau et pour Android qu'on va développer suite au succès de la campagne, mais il te faudra tout de même héberger ton serveur XMPP (ou utiliser un public/associatif).

Sinon je ne connais pas twisted mais j'ai vu que l'on pouvait faire beaucoup de chose avec, est ce compliqué d'interfacer d'autre logiciel sur ces protocoles ?

Oui c'est un des buts du projet, et Twisted est très souple. Mais ça demande un peu de temps pour maîtriser.

Je viens de pousser le correctif et mettre la démo à jour, ça devrait être OK désormais (sauf le contenu extérieur qui ne passe pas encore par un proxy, avec images par exemple).

Ce sera dispo pour la 0.6.1