Goffi a écrit 1556 commentaires

C'est quand même possible de savoir si le serveur supporte ce que l'on désire (comme expliqué ici). Reste à faire ça joli dans l'interface: tu prends une liste de serveurs publiques, tu enlèves ou grises ceux qui n'ont pas ce que tu veux, et tu mets des icônes selon les fonctionnalités intéressantes, un peu dans l'esprit de ça: https://www.jabberes.org/servers/ .

Tu peux même proposer par défaut une liste restreinte de serveurs bien testés, et proposer à ceux qui le souhaitent d'en choisir un autre. C'est pas les solutions qui manquent, le plus difficile, mais pas insurmontable, c'est de rendre ça facile et intuitif dans l'interface.

Salut

Aujourd’hui j’utilise Telegram parce qu’il existe un client Android et un client GNU/Linux qui sont très bons, notamment grâce à la synchronisation des conversations. J’attends avec impatience d’avoir la même chose en décentralisé et chiffré de bout en bout! Pour le moment Jabber n’est pas vraiment utilisable pour mon usage…

La synchronisation de salon est déjà possible avec MAM. Le chiffrement de bout en bout sur salon toujours pas par contre. Ça sera probablement un des sujet du summit à venir.

Petite question, même si elle est sans doute un peu hors-sujet: une fonctionnalité très à la mode en ce moment, les autocollants (au moins dans Telegram, Line, Facebook), est fort sympathique. Il s’agit de collections d’images que l’on peut insérer en un clic dans la discussion, un peu comme des smileys mais plus grand. Y’a aussi des clients qui permettent d’enregistrer ses propres gifs pour pouvoir les ressortir plus tard

Comme a dit Edhelas, c'est possible d'afficher des images via XHTML-IM.
Mais pour être honnête, c'est pas le genre de fonctionnalités que j'ai très envie d'implémenter (les autocollants, pas les images).

J'ai fait (regardé) pas mal de confs l'année dernière, et du coup j'ai loupé du monde oui. Si je ne suis pas au lounge le mieux c'est encore de me chopper à la fin d'une de mes 2 confs, ou de me laisser un numéro de téléphone (ou une adresse courriel).

Le dimanche je risque de partir tôt en milieu d'aprem.

Salut,

moi oui, j'y ferai même 2 conférences (c'est indiqué dans la dépêche ;) ).

La publication était vraiment imminente, la XEP est parue aujourd'hui: https://xmpp.org/extensions/xep-0371.html .

En clair, ça signifie que les communications TCP (pour UDP il y avait déjà une XEP avant) pourront plus facilement traverser les NAT, ce qui va profiter en premier lieu au transfert de fichiers.

Salut,

framasoft a une équipe de traduction utilisant le framapad, je pense qu'un tel projet les intéresserait beaucoup, tu peux peut-être les contacter ? Avec Publication commune sur Framablog/DLFP ça serait top :)

Salut,

Sauf funeste erreur de ma part, ça n'a rien à voir. Le PFS est une propriété cryptographique, qui ne dépend pas (et heureusement) de la capacité à "stocker" un message. Après, la page Wikipedia d'OTR rappelle que GTalk disposait d'une option "off-the-records" qui ne faisait qu'annuler (au moins officiellement) l'archivage.

La formulation est sans doute raccourcie, mais c'est bien ce que je voulais dire (et ça n'est bien sûr par une confusion avec l'OTR de GTalk, je n'ai même jamais utilisé ce dernier). Bien entendu une fois que le message est déchiffré, tu peux en faire ce que tu veux, mais le principe de le confidentialité persistante, du moins telle qu'implémentée dans OTR, fait que tu as une clef temporaire, jetable, et qu'il faut être en ligne en même temps pour échanger le message, du coup c'est à cause de PFS que tu ne peux pas utiliser OTR hors ligne. Après je ne suis pas expert en chiffrement, il est possible que je me trompe.

D'ailleurs dans le brouillon de la nouvelle XEP OpenPGP, ils mentionnent même l'absence de confidentialité persistante (PFS) comme un moyen de chiffrer ses archives MAM.

Encore sous réserve de bon fonctionnement de mes neurones, c'est à peu près exactement l'inverse : les petits trous du "hole punching" ne sont qu'une des techniques utilisées par l'ICE. En gros, l'ICE c'est "je tente de passer en direct… ah non zut ça passe pas, bah je vais essayer divers contournements de NAT alors …. ah ben non plus, vous auriez un relai TURN sivouplé?".

Une autre XEP que je n'ai pas encore implémenté, donc que je ne maîtrise pas. Il faudrait à ce moment changer comme suit:

s/ICE est une méthode pour faire du « TCP hole punching », une méthode pour traverser les NAT/ICE est une méthode pour faire de la traversée de NAT/

Si un modo passe par là…

Merci pour la correction.

Je suis curieux de savoir ce que vous attendez d'un tel logiciel, parce que dans la liste des fonctionnalités que je vois ici, y'en a beaucoup qu'on recoupe.

Ça m'intéresse parce que maintenant qu'on a fait l'essentiel des couches basses, c'est beaucoup sur l'interface qu'il y a du travail.

Bref, quels sont les fonctionnalités essentielles selon toi (ou d'autres) d'un « forum nouvelle génération » ? Et qu'est-ce qui le différencie d'un forum « ancienne génération » à la phpBB ?

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 ?