Goffi a écrit 1537 commentaires

Si tu as les sources du « service » comme tu dis, tu peux le reproduire chez toi (ou ailleurs) à l'identique, si tu n'as pas les sources tu ne peux pas, du moins pas trivialement (tu peux toujours essayer de reproduire).

Avoir tes données sur une machines que tu ne maîtrise pas est un autre problème, qui dépend beaucoup de la confiance que tu as en la personne ou l'organisme qui maîtrise la machine.

Tu peux certainement récupérer tes données brutes sur Github, mais ça ne veut pas dire que tu pourras les réutiliser facilement, parce que si tu n'as pas le logiciel qui va avec tu vas devoir adapter (si c'est dans un format standard ça peut déjà grandement faciliter la tâche). Et Github ça n'est pas que git (qui lui est libre et décentralisé), c'est le système de revue, de bugs etc.

À ça s'ajoute que github exploite ou peut exploiter tes données (je ne connais pas le modèle exacte de github, mais ça ne m'étonnerait pas qu'il utilise les données pour des offres d'emplois par exemple, après on aime ou pas c'est une autre question).

Il y a tout un tas d'autre problèmes liés à la centralisation et à l'uniformisation, bref c'est un débat tout à fait pertinent.

À titre perso, je suis particulièrement gêné que la XSF soit passé à github, car ça arrive de plus en plus souvent que des commentaires se fassent là bas au lieux d'être sur la liste de diffusion dédiée. Mais bon on s'éloigne de la problématique du logiciel propriétaire que tu citait.

C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?

En relisant ton commentaire je me dis qu'il faut préciser que c'est fait pour des raisons de sécurité, un serveur X permet aux applications d'accéder aux autres, mettre Xpra au milieu permet de les isoler.

salut,

je dois pas être réveillé, je ne vois pas de différence, où est la faute ? Iceweasel est barré dans la N.D.T. en référence à ce journal.

Comme je l'ai compris, les conteneurs avec les applications ont juste une socket et le serveur Xpra est dans un conteneur à part (le client est lui dans un autre conteneur).

À l'usage, j'ai vu un Firefox tourner et on peut difficilement dire qu'il est dans un conteneur, c'est très fluide. Sur la page d'explications l'auteur indique que même pour les vidéos plein écran ça marche bien.

Le système est pensé pour pouvoir changer de serveur facilement, aussi quand Wayland sera dispo, il devrait être facile de faire la transition.

Oué alors en fait, comme ça a été indiqué, j'ai fait circuler le lien il y a une semaine, notamment sur Diaspora, pour demander que tous ceux présents participent, pour qu'on fasse une grosse dépêche Fosdem.

après plusieurs jours, personne ou presque n'a participé, et ceux qui l'ont fait ont parlé uniquement de XMPP, du coup on a renommé une première fois pour dire que c'était un retour sur la partie XMPP.

À ce moment y'a eu 2 mini paragraphes sur des trucs qui n'ont rien à voir avec XMPP et qu'on n'a pas voulu supprimer, du coup on a re-renommé et on a mis la note pour dire que c'était principalement centré sur XMPP et qu'on pouvait toujours compléter en commentaires. C'était ça, ou virer des contributions (dont la tienne), ou attendre 6 mois pour avoir un truc potable et plus générique.

Bref, c'est centré sur XMPP parce que c'est ce qu'on vu les (rares) contributeurs à ce compte rendu. Tes impressions tu peux aussi les mettre dans une nouvelle dépêche si tu veux rien ne t'en empêche.

Pendant longtemps ce fut le seul serveur XMPP à implémenter correctement le protocole.

c'est pas tout à fait vrai. Ejabberd (et donc probablement MongooseIM) et Openfire ont un excellent support de PubSub depuis longtemps (et je ne sais pas ce qu'il en est de Tigase que je n'ai jamais essayé), et Prosody le supporte mais ne gère pas pour le moment le stockage hors ligne (à ma connaissance). À la base Prosody se veut très KISS, et enregistre tout en fichiers, ce qui pose des problèmes pour PubSub (c.f. mes 2 journaux où j'explique ça : Retour de Berlin et De l'autre côté). Ça a évolué (il y a une API pour utiliser une BDD), mais je ne crois pas que c'est utilisé pour PEP à l'heure qu'il est.

De notre côté nous avons développé notre propre service PubSub, et on le fait tourner avec Prosody. Vu que c'est un serveur taillé sur mesure, il a presque (*) tout ce dont nous avons besoin (et donc Movim aussi).

(*) je dis presque parce qu'on n'a pas encore implémenté la gestion des présences nécessaire pour faire un vrai PEP

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…