Goffi a écrit 1537 commentaires

ah ben il semblerait que ça soit déjà implémenté dans Gajim en fait, du coup c'est bien pour tester.

Il y a du nouveau, Chteufleur vient de nous prévenir sur le salon de SàT qu'il avait fait un composant en Go disponible à cette adresse: https://git.kingpenguin.tk/chteufleur/HTTPAuthentificationOverXMPP .

Je n'ai pas encore regardé en détails, mais ça devrait simplifier énormément l'intégration à DLFP, si j'ai bien compris il n'y a qu'une requête HTTP à faire, le composant se charge de la partie XMPP, et le code retour indique si c'est bon ou pas.

Il veut faire l'implé dans SàT également, et gageons que d'autres projet comme Movim ou Gajim pourraient suivre rapidement.

Sur Wordpress, Jehan avait même fait un système de secours qui demande le code par message simple si la XEP n'est pas gérée par le client, donc fonctionnant avec tous les clients XMPP.

À la conf des dernières RMLL sur Replicant de Paul Kocialkowski (qui passe parfois par ici) il disait que certains téléphones isolent cette partie pour filtrer les informations auxquelles elle avait accès. C'est pas top, mais c'est mieux que rien.

Un entretien avec Gelnior sur le journal du hacker: https://blog.journalduhacker.net/index.php?article41/entretien-avec-frank-rousseau-directeur-technique-de-cozy-cloud . On peut y lire d'où vient Cozy, comment c'est géré, et même l'infrastructure utilisée pour faire tourner tout ça.

il y a un tiret en trop à peut être, ça peut peut-être perturber.

ces remarques sont intéressantes, vous les avez données à l'équipe de dév ? Même s'ils sont probablement déjà au courant, peut-être que l'histoire du filtre n'a jamais posé problème à d'autres utilisateurs par exemple.

regarde les commentaires plus bas ;)

Je n'ai pas trop d'expérience dessus (j'ai implémenté Jingle mais pas encore de visioconférence, et mes connaissance sur WebRTC sont pour le moment superficielles), mais il est possible de lier les 2 (e.g.: XEP-0343), d'ailleurs WebRTC s'inspire de Jingle. Donc il est fort probable que meet jitsi utilise WebRTC et XMPP en même temps (pour XMPP j'ai demandé confirmation sur xsf@, et on m'a dit d'ouvrir ma console javascript… effectivement on voit bien que c'est du XMPP).

Il y a aussi les solutions en mode web (webRTC),

Pour être sûr que j'ai été clair : la version dont je parle ici est entièrement Web, c'est en complément de la version Jitsi bureau (mais Jitsi bureau n'est pas nécessaire). Et je re-précise: pas besoin de compte, il suffit de fournir un lien aux personnes à inviter.

J'ai aussi une adresse en goffi.org avec une utilisation qui se rapproche parfois des salutations dont tu parles.

En tout cas on est ouverts aux suggestions et l'identifiant est un sujet très intéressant.

Ton journal est plein de bonnes idées, j'aime beaucoup la non unicité de l'identifiant, et bien que je connais GNU Net de nom, je ne connaissais pas GNU Name System.

Un journal à garder sous le coude, merci !

Non, ce qui n'était pas (bien) connu c'était les outils décentralisés, et surtout ce que Git était et ce qu'il faisait. Dans la plupart des commentaires la notion de SCM semble tout à fait maîtrisée.

P.-S.: en relisant mon précédent commentaire je pense que tu as mal lu, la question est « est-ce que c'est vraiment un SCM ? » et non pas « qu'est-ce qu'un SCM ? »

Merci pour le liens, c'est assez amusant de lire les commentaires de l'époque avec plus de 10 ans de recul. Certains avaient vu juste. C'est aussi amusant de lire des questions sur « à quoi ça sert », « est-ce que c'est vraiment un SCM ? », des questions tout à fait compréhensible en 2005.

C'est quand même très impressionnant d'avoir eu un truc fonctionnel en 1 semaine.

C'est pas du spam simple c'est du malware bancaire type dridex. Rien de nouveau, sauf pour toi apparemment.

Non, je n'ai pas parlé de documents Word ni de macros.

Tu balances le contenu sur:
* malwr.com
* hybrid-analysis.com
Tu signales via spamcop avec le commentaire qui convient.

Merci pour les liens, je vais jeter un œil.

Je veux dire, là-dedans, comme différences avec IRC, ya juste new. Honnêtement, pourquoi je me mettrai dans un nouveau protocole, juste parce qu'il est "new" ? Sans parler du serveur, dont j'ai clairement pas envie de m'occuper :p

Ah mais moi je suis partisan du « aucune raison de changer un truc qui marche ». Si IRC va pour toi, ne change pas ;)

Expérience mitigée. C'était comme un client IRC mais où tu connais pas les commandes. J'ai tapé help? sans grand succès (ça a ouvert un onglet avec une 404 nginx, et ça a entré "yassinphilip:null" dans le salon :p) apres je suis passé en chat privé avec toi, remember, juste en cliquant sur ton nom (genre on peut pas faire autre chose) mais je n'ai pas compris comment revenir dans le salon. Et bien sur, j'ai pas compris non plus comment créer un salon. Bon, c'est juste un client web, moving on.

Oui c'était juste pour dire que des clients web y'en a partout, muckl c'est pas nécessairement le meilleur (je n'utilise pas donc je n'en sais rien pour être honnête). Il y en a d'autre, ça n'est pas un pb.

"Firefox doesn't know how to open this address, because one of the following protocols (xmpp) isn't associated with any program or is not allowed in this context." pareil qu'IRC, mais encore une fois, IRC ça fait 20 ans qu'on sait quoi faire.

Comme pour IRC, il faut associer un client ;). Et oui c'était pour dire que pareil qu'IRC. Pour mettre les choses au clair : je n'ai absolument rien contre IRC, ça marche bien pour ce que ça fait.

Juste, bon, XMMP/jabber, faut admettre, ça fait un meta-moment qu'on attend de ne serait-ce que voir à voir si c'est bien ça qu'il faut attendre..?

Ben ça prend du temps, ça irait beaucoup plus vite si on était 10 à plein temps, mais là on fait avec les ressource disponible… Enfin là c'est la dernière ligne droite : la prochaine version sera celle « grand public » qu'on annonce depuis longtemps.

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.

Pas d'inscription à un service quelconque, pas (forcément) d'appli à installer, c'est so 2016 ! :)

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.

alors qu'avec un lien webchat ça marche direct :)

ça marche aussi chez nous ;) ou avec un lien xmpp: xmpp:sat@chat.jabberfr.org?join.

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.

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 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.

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.

Y'a plus qu'à implémenter l'accès via XMPP (cf. ici)

je file mon vieux script, qui se contente de lancer la station (radio [nom_station]):

#!/bin/sh
cd ~/radios
if [ $# != 1 ]; then
        echo "syntaxe: radio nom_radio"
        echo "liste:"
        echo "--"
        ls -1
        echo "--"
        echo
        exit 1
fi 
mpv --playlist "$1"

et dans ~/radios y'a des listes de lecture avec les noms des radios

% cat lat
http://vdl.stream-lat.org:8000/voixdulat_mp3

Pendant que j'y suis pour sauvegarder le prochain bulletin france info :

% cat sauve_prochaines_infos 
#!/bin/zsh
STREAM='http://audio.scdn.arkena.com/11006/franceinfo-midfi128.mp3'

sleep $((1800-(`date +%s`%(60*30)))); mplayer -dumpfile ~/dump/dernieres_infos.mp3 -dumpstream "$STREAM" & sleep $((60*15)); pkill -f "dumpfile.*dernieres_infos.mp3"