petite question pour le markdown: est-il possible de désactiver les liens automatiques ? Par exemple le lien server@example.net est cliquable alors qu'il ne faudrait pas…
Aussi désolé pour la capture de Movim est de mauvaise qualité: comme je n'avais pas d'instance sous la main, j'ai récupéré la capture dans la présentation de PSES.
Il y a quelques discussions sur standard@, notamment sur la possibilité de supprimer les salons semi-anonymes.
Donc MUC2 l'idée principale c'est d'utiliser PubSub, et d'avoir quelque chose de plus souple. Il y a aura une compatibilité MUC1 (assurée probablement par le serveur). Des choses qui devraient être possibles sont les salons sans présence, ou permettre de se connecter depuis plusieurs ressources (par exemple ordinateur de bureau et téléphone portable) à un même surnom (nick) dans un salon.
L'intérêt d'avoir des salons sans présence c'est d'une part d'alléger le trafic, et d'autre part de pouvoir mieux gérer les micro déconnexions qui n'étaient pas un problème à l'époque de MUC1, mais qui le deviennent aujourd'hui avec les appareils mobiles (si j'ai bien compris).
Lister et indexer les salons publics c'est possible, mais le problème c'est qu'il peut il y avoir des salons un peu partout et qu'il faut trouver les serveurs. Il faudrait pouvoir avoir un annuaire distribué, et ça serait aussi très utile pour trouver des personnes. En attendant tu as des moteurs qui regroupent les résultats de plusieurs serveurs, par exemple http://search.wensley.org.uk/ .
Tenir un salon sans avoir à l'héberger c'est déjà possible, tu peux demander à avoir un salon persistant et être le créateur, selon le serveur MUC utilisé. Ou alors je n'ai pas compris ce que tu entends par là.
Je vois également que tu vas t'intéresser de plus près au côté non-messagerie, qui est effectivement extrêmement important à remonter tant il est sous-exploité, j'ai hâte !
Salut, merci pour le commentaire :). La série a plus de succès que ce à quoi je m'attendais, on m'en a parlé plusieurs fois aux RMLL, et effectivement ça fait monter l'intérêt pour XMPP (ce qui était un peu le but). On m'a par exemple demandé si c'était utilisable pour la contrôler un robot (oui), ou pour faire de la surveillance de machine - ou « monitoring » pour ceux qui préfèrent - (oui aussi), d'ailleurs on m'a parlé de jimbo que je ne connaissais pas: http://www.darkcoding.net/software/jimbo/ .
Sinon oui je songe à faire des tutos par la suite, un bot est effectivement simple à faire, mais ça peut être l'occasion de présenter différentes façon de faire. Enfin on verra bien, c'est un peu en fonction de l'humeur au moment d'écrire.
alors le contraindre à devoir ouvrir des comptes à droite et à gauche pour soumettre un rapport de bug ou une pull request…
Parce qu'héberger sur gittruc, c'est pas le contraindre à ouvrir un compte là bas ? Et à accepter les conditions d'utilisation qui vont avec, au passage.
Oui ça ça marche sur un serveur centralisé, mais la synchronisation des horloges n'est pas triviale en décentralisé, même à supposer que tout le monde utilise NTP.
L'id est nécessaire pour identifier le message, ensuite à l'affichage tu représentes ça comme tu veux: norloge, chiffre, couleur, etc.
J'ai fait un deal avec devnewton sur le sujet: je me pencherai sur la question et une fois implémentées il adhérera à l'association :)
En pratique j'ai commencé à regarder, et il y a les threads dans XMPP qui permettent de suivre une conversation, mais il n'est pas possible de spécifier plusieurs parents, ce qui est nécessaire pour un équivalent des norloges. L'autre soucis est que les ids des messages ne sont pas obligatoires, il faut pouvoir identifier un message sans id (ou alors réserver la fonctionnalité aux seuls messages qui ont un id). Enfin rien d'insurmontable, mais il faudra probablement une XEP pour que ça soit propre.
La fonctionnalité est intéressante, et ça serait particulièrement utile que ça fonctionne avec plusieurs salons à la fois, dans une même fenêtre. On a un petit refactoring à faire sur la gestion des message dans SàT, et je pense qu'ensuite une version expérimentale serait assez facile à faire.
P.-S.: j'aurais parié qu'il y aurait une question sur le sujet :)
À mon sens ça ne change pas grand chose: la fédération était coupée (contrairement à gtalk), avec de la messagerie basique (enfin je ne sais pas où ça en était à la fin), et uniquement de le messagerie. Le seul intérêt était de pouvoir utiliser un client tiers et ainsi éventuellement chiffrer ses communications (à supposer que la personne en face fait la même chose).
Même si pour Google ça ne me gêne pas plus, au moins ils avaient la fédération, et ont fait des contributions majeures (enfin surtout une: jingle).
Utiliser XMPP pour que tout le monde ou presque se retrouve chez le même hébergeur, sans chiffrement ou fédération, sans contrôle sur les données, ça n'a pas grand intérêt.
Le seul point noir que je vois, c'est que ça risque de donner l'impression que XMPP est à l'abandon, ce qui est totalement faux (il suffit de voir l'activité sur les listes de diffusions ou les dépôts des logiciels XMPP).
plusieurs jids pour une personne tu veux dire ? Si c'est ça, effectivement tu peux utiliser des passerelles XMPP <-> XMPP pour regrouper les comptes, ou alors utiliser un client multi-comptes comme gajim, psi ou SàT (j'ai un compte jabber.fr et libervia.org par exemple).
désolé pour la réponse tardive, étant aux RMLL, je me connecte peu.
la XEP-0015 a été rejetée, je suppose pour des raisons de sécurité (il faudrait chercher les discussions de l'époque sur les archives pour être sûr). Tu ne peux pas changer de serveur automatiquement, cela pose des problèmes d'une part pour valider ton identité (comment s'assurer que c'est bien la même personne qui a fait le transfert ? Bon il y a probablement des solutions comme avoir un accès à l'ancien et au nouveau compte, ou une identification GPG, mais il y a le risque qu'une clef a été compromise par exemple, il faudrait y réfléchir sérieusement pour voir les problèmes), et d'autre part un réabonnement automatique n'est pas forcément une bonne chose (je n'aimerais pas qu'un contact sur jabber.fr déménage et que je me retrouve à écrire sur facebook.com sans m'en rende compte).
Il y a plusieurs XEPs utilisables: si tu as la main sur le serveur (encore une fois: autohébergez vous ou approchez vous d'une association locale !), tu as un format standardisé pour transférer les comptes (XEP-0227), et pour échanger des éléments sur roster, tu as la XEP-0114. Sans passer par les XEPs, un clients peut proposer de faire un réabonnement massif de tous tes contacts (c'est une chose qu'on va probablement proposer tôt ou tard avec SàT).
Là tout de suite je ne vois pas d'autre solution, peut-être qu'il y en aura un jour, mais comme on ne change pas de serveurs tous les 4 matins, ça ne me semble pas une priorité. Il serait intéressant de pouvoir au moins transférer l'historique (pour l'historique côté serveur, dans le XEP-0313, l'upload d'archive n'a volontairement pas été implémenté, pour éviter de trop compliquer la XEP), et indiquer qu'une adresse n'est plus valide (le plus simple étant probablement d'envoyer un message automatique pour dire qu'on a changé d'adresse, et pas besoin de XEP pour ça).
désolé je réponds tard, mais je suis à Beauvais pour les RMLL depuis samedi, et du coup je me connecte peu.
un moyen de recevoir les messages sur plusieurs postes en même temps, façon chat de Facebook ;
Je ne sais pas ce que tu entends par là (je n'ai jamais vraiment utilisé facebook, et j'ai supprimé le compte que j'avais depuis longtemps), mais tu as plusieurs façons de faire:
si c'est par « plusieurs postes » tu entends des clients à différents endroits (par exemple téléphone, ordi fixe, ordi portable) pour le même compte, tu as Message Carbons (XEP-0280) qui permet ça, c'est de plus en plus implémenté
si c'est plusieurs personnes en même temps, c'est de la discussion de groupe (MUC, XEP-0045), je vais expliquer ça dans le prochain article mais je suppose que tu connais déjà le principe (en gros comme IRC)
si c'est un message de type « normal » (celui qui ressemble au courriel), alors tu as la XEP-0033 (Extended Stanza Addressing) qui permet d'envoyer à plusieurs personnes en même temps.
si c'est pour des messages type microblogage, c'est PubSub qui gère ça, j'expliquerai dans un futur article, et je vais faire une conf de 20 min sur le sujet demain pour les RMLL.
un moyen de chiffrer les conversations et de les recevoir sur plusieurs postes en même temps, comme évoqué dans mon point précédent.
Alors là c'est un problème par contre parce qu'il n'y a pas encore de bonne solution pour le chiffrement de bout en bout. Enfin OTR est utilisé (mais pas encore standardisé avec XMPP), et couplé à message carbons tu le recevras sur plusieurs machines connectées avec le même compte. Si par contre tu entends ça comme une discussion de groupe, il n'y a pas encore de solution établie, c'est un vieux problème avec XMPP et il y a eu plusieurs tentatives mais rien qui n'a vraiment percé. Il était question de s'enfermer 2 jours avant le prochain Fosdem pour régler ça.
Je serais vraiment heureux de trouver des explications sur ces 2 points dans les articles futurs, soit pour nous dire dire pourquoi ce n'est pas possible, soit pour nous dire comment le faire (ou comment contourner le problème).
Tu devrais déjà avoir les pistes avec ce que je viens d'écrire, sinon indique moi ce que tu entends exactement par « recevoir les messages sur plusieurs postes en même temps ».
En tout cas merci pour cette série d'articles, ça manquait vraiment je pense.
je suis content de voir que ça plaît, plusieurs personnes sont venues m'en parler pendant les RMLL :). N'hésitez pas à me dire si vous voulez voir des sujets particuliers traités (bon bien sûr il y a des domaines que je connais mieux que d'autres).
Nous avons déjà implémenté la XEP-0065 (socks 5, proxy65 c'est juste une implémentation - que nous utilisons d'ailleurs -), mais nous l'utilisons avec la méthode « historique » (la XEP-0096) qui est aussi la plus implémentée, mais qui a plusieurs soucis, en particulier elle traverse mal les NAT et firewalls.
Jingle permet aussi d'utiliser socks 5, mais la méthode de négociation est bien meilleure et permet d'établir une connexion dans pratiquement tous les cas, c'est la méthode recommandée aujourd'hui et c'est pour ça qu'il faut qu'on l'implémente.
Petite parenthèse: tu n'es pas obligé de passer par le serveur avec socks5, le proxy serveur n'est utilisé que si la connexion directe ne peut être établie.
oui jingle c'est pratiquement qu'une question de client, le serveur peut aider à établir une connexion ceci dit, et servir de relais si la connexion directe n'est pas possible. Enfin je ne suis pas spécialiste, n'ayant pas encore implémenté jingle on ne s'est pas trop penchés sur la question (mais on va le faire je pense assez vite pour le transfert de fichiers). Le mieux à faire est de demander directement sur le salon de Prosody: prosody@conference.prosody.im.
Jappix et Movim lui préféraient Metronome uniquement parce que Metronome sauve les données PEP/PubSub hors ligne. J'ai vu plusieurs fois le développeur principal de Prosody (à chaque rencontre XMPP, ou au Fosdem), et lui ai posé la question. En gros la philosophie de Prosody c'était de tout garder simple, tout fichier, et pas de SGBD. Le dev de Metronome a fait une implémentation simple (de ce qu'on m'a dit, je n'ai pas été vérifier) mais qui fonctionne.
Là chez Prosody je crois qu'ils sont en train de voir pour faire un système relativement générique pour pouvoir utiliser différentes bases de données, enfin je suis ça de très loin puisque on utilise une autre méthode avec notre propre composant Pubsub. Mais je peux te dire qu'ils sont très compétents techniquement, et je fais toute confiance en l'équipe de Prosody.
Le gars sur Metronome semble être seul, mais très dynamique. Côté prosody y'a une communauté bien en place, très dynamique aussi et accueillante: j'ai pu résoudre les problèmes que j'ai eu très rapidement avec leur aide sur le salon.
Bref, l'un ou l'autre c'est une question de goût et de ressenti personnel. Pour ce qui est des composants nécessaires pour Jappix et Movim, il pourront profiter de ce qu'on a fait avec les XEPs et les modules qui vont bien, ainsi que le service pubsub qu'on a, donc ils seront tout à fait utilisables avec Prosody sous peu (cf http://linuxfr.org/users/goffi/journaux/xmpp-et-micro-blogage-la-donne-a-change ).
Si Ejabberd te convient, c'est un bon choix. Prosody ça vaut vraiment le coup d'œil, Lua est simple à comprendre, et surtout très rapide. Et il y a beaucoup de modules communautaires (en plus des déjà nombreux modules officiels) pour utiliser avec à peu près n'importe quoi: https://prosody.im/doc/modules et https://code.google.com/p/prosody-modules/w/list .
salut, difficile de répondre à ça vu que ça part assez vite en guerre de religion. En général mon critère de choix quand plusieurs logiciels semblent équivalent, c'est d'être dans un langage que je connais ou facile à apprendre, pour pouvoir corriger en cas de soucis, mais c'est parce que je suis développeur que j'ai ce réflexe ;).
jabberd est le serveur le plus ancien, je ne l'ai moi même jamais utilisé et je ne sais même pas s'il est encore développé.
ejabberd est une version en Erlang, et un des serveurs les plus complets et les mieux suivis actuellement, une référence. Par contre de mémoire les logs ne sont pas super pratiques à lire, enfin il faut l'habitude quoi. Depuis peu on peut l'étendre avec Elixir, en plus de L'Erlang de base.
J'avais utilisé OpenFire qui était très facile à installer, c'est du Java.
Sinon nous on utilise principalement Prosody: léger, très facile à installer, c'est du lua qui s'apprend très vite pour qui sait déjà programmer, et la communauté est très active. C'est celui que je recommanderais, surtout que c'est à l'heure actuelle le seul qui a des modules pour les XEP-0355 et XEP-0356 qu'on va utiliser pour SàT (cf http://linuxfr.org/users/goffi/journaux/xmpp-et-micro-blogage-la-donne-a-change), même si d'autres serveurs vont très probablement suivre (chez Ejabberd par exemple on est en contact avec un dév).
Mais quand on doit le présenter à quelqu’un, on ne peut le présenter que comme un protocole de messagerie, en mentionnant qu’il y a des projets en cours pour de la visio-conférence ou du microblogging tout simplement parce que dans les faits c’est loin d’être au point et quand ça l’est, ce sont les logiciels qui ne suivent pas. Tel serveur supporte ça, tel client supporte ça…
Pour la visio-conférence, ça devrait être au point au moins chez Jitsi (même si j'ai moi même eu des soucis, comme avec la quasi totalité des logiciels que j'essaye pour ça, XMPP ou pas), si ça n'est pas le cas il faut remonter les problèmes. Pour le microblogage on avance à grands pas.
Le problème majeur, est de bien choisir un serveur, ou, comme je le disais dans un commentaire sur un des articles précédents, de l'installer soi-même ou de demander à une assoce locale afin de pouvoir contacter facilement les admins et demander d'installer ce qu'il nous manque.
Pour les clients, il ne faut pas forcément en chercher un qui fait tout. Certains clients (comme le notre) cherchent à implémenter le maximum de fonctionnalités, mais XMPP est prévu pour utiliser plusieurs clients en même temps, et il est tout à faire logique d'avoir un peu de fonctionnalités un peu partout: par exemple un salon de discussion pour un jeu, ou un client qui ne fait que la vidéo, avoir du transfert de fichier intégré au bureau, etc. Donc si tu utilises un client, rien ne t'empêche d'en utiliser un autre pour une autre utilisation.
Pourquoi ne pas instaurer des versions d’XMPP ?
ça c'est effectivement une bonne idée, et y'a des débuts de réponse avec la XEP-0302 qui indique les XEPs à implémenter pour avoir un client moderne (enfin moderne en 2012 :-/), et https://xmpp.org/about-xmpp/technology-overview/ qui donne des XEPs à implémenter pour différents cas (on m'a donné le lien sur le salon XSF).
Je suis un utilisateur d’XMPP, j’aime ce protocole, mais je suis déçu de ne pas pouvoir en utiliser toute la puissance.
moi aussi, et c'est une des raisons qui m'a fait commencer SàT ;).
En anglais probablement, avant XMPP je ne connaissais pas le terme en tout cas. Un des problèmes c'est qu'on (et je m'inclus dedans) a tendance à l'utiliser même en français.
il m'est aussi arrivé de coder en voyageant (principalement en australie), bon j'avais un van c'était un peu plus simple, mais sinon c'est dans les bibliothèque avec un pc portable léger le meilleur endroit: t'as du courant, des fois internet, une table et parfois du silence (y'en a qui aiment avoir de la musique pour bosser, moi il me faut du silence)…
Oui je ne sais pas pourquoi ils ont parlé de « roster » mais je trouve aussi que amène de la confusion. Il s'agit effectivement juste d'une liste de contacts.
Je pense que c'est aux clients à simplifier ça aussi: ce sont des choses internes qui n'ont pas besoin d'être nommées ou représentées de la même façon pour l'utilisateur final. La première fois que j'ai utilisé Psi, au début des années 2000, j'ai été un peu perdu en voyant la découverte des services (dont je vais parler dans la prochain article): ça n'a pas besoin d'être aussi visible. De même on n'a pas besoin d'utiliser le terme « roster » au niveau du client, surtout en français (ou toute autre langue que l'anglais) où ça ne veut rien dire !
je parlais du principe en général, pas du cas particulier d'Ardour. Un ordinateur on peut aussi l'avoir eu gratuitement (don par exemple), ou s'en servir dans une bibliothèque/une association/je ne sais quoi.
Je ne critique pas du tout ce que fait Ardour, ou GCompris qui fai(sai?)t la même chose avec Windows, je dis juste que le modèle n'est pas parfait, et qu'il ne me semblerait pas judicieux de le généraliser. En dehors de la somme, tout le monde n'a pas une carte de crédit non plus. Après sur Android il y a des cas de logiciels payants sur le dépôt google, et gratuit sur F-Droid, c'est pas forcément une mauvaise idée (là y'a plus d'histoire de compilation, c'est un dépôt libre à installer).
Un logiciel qui espionne ce que tu utilises, je suis pas hyper fan non plus. Et puis le temps d'utilisation n'est pas forcément lié aux besoins de dév, ou à l'utilité: photorecord/testdisk m'ont déjà sacrément aidé, et pourtant c'est pas le genre de truc que t'utilises souvent (enfin il vaut mieux).
Des discussions c'est surtout la constante du "il nous faut des sous" qui sort.
Je pense qu'il faudrait déjà un site qui regroupe les logiciels libres et leurs besoins, ce qui a déjà été donné jusqu'ici, ce qu'il manque, à quoi servent le logiciel et les sous, etc. Un truc géré de façon indépendante. La question serait de savoir dans quel ordre présenter les logiciels: par popularité serait probablement une erreur (les petits n'auraient jamais de sous). Au hasard ? Ceux qui ont reçu le moins en premier ?
Donc la personne qui n'a ni les moyens, ni les compétences techniques, doit détailler sa situation pour avoir un binaire ?
Compiler depuis les sources il faut bien comprendre que c'est loin d'être à la portée de toue le monde (ne serait-ce qu'en temps à y investir pour savoir comment faire).
Bref, cette solution n'est pas parfaite.
Il y a un vrai problème pour le financement des projets libres c'est pas nouveau, et même pour les médias alternatifs en général. À PSES j'ai eu l'occasion de discuter avec pas mal de monde, c'est vraiment une constante.
# question de mise en forme
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 6 - les commandes à distance. Évalué à 4. Dernière modification le 27 juillet 2015 à 13:56.
petite question pour le markdown: est-il possible de désactiver les liens automatiques ? Par exemple le lien
server@example.netest cliquable alors qu'il ne faudrait pas…Aussi désolé pour la capture de Movim est de mauvaise qualité: comme je n'avais pas d'instance sous la main, j'ai récupéré la capture dans la présentation de PSES.
# Pas si bon esprit que ça
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal J'aime bien l'esprit. Évalué à 10.
Pour mémoire eux c'est aussi ça: https://linuxfr.org/users/blink38/journaux/ma-vie-moi-qui-allait-publier-mon-code-en-gpl
Ils sont pas vraiment copains avec les gens qui font de l'automatisation.
[^] # Re: MUC 2
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 5 - les discussions de groupe (suite) et les transports. Évalué à 2.
Il y a quelques discussions sur standard@, notamment sur la possibilité de supprimer les salons semi-anonymes.
Donc MUC2 l'idée principale c'est d'utiliser PubSub, et d'avoir quelque chose de plus souple. Il y a aura une compatibilité MUC1 (assurée probablement par le serveur). Des choses qui devraient être possibles sont les salons sans présence, ou permettre de se connecter depuis plusieurs ressources (par exemple ordinateur de bureau et téléphone portable) à un même surnom (nick) dans un salon.
L'intérêt d'avoir des salons sans présence c'est d'une part d'alléger le trafic, et d'autre part de pouvoir mieux gérer les micro déconnexions qui n'étaient pas un problème à l'époque de MUC1, mais qui le deviennent aujourd'hui avec les appareils mobiles (si j'ai bien compris).
Lister et indexer les salons publics c'est possible, mais le problème c'est qu'il peut il y avoir des salons un peu partout et qu'il faut trouver les serveurs. Il faudrait pouvoir avoir un annuaire distribué, et ça serait aussi très utile pour trouver des personnes. En attendant tu as des moteurs qui regroupent les résultats de plusieurs serveurs, par exemple http://search.wensley.org.uk/ .
Tenir un salon sans avoir à l'héberger c'est déjà possible, tu peux demander à avoir un salon persistant et être le créateur, selon le serveur MUC utilisé. Ou alors je n'ai pas compris ce que tu entends par là.
Oui dès le prochain article. Tu peux déjà regarder ce qu'on fait avec SàT, en particulier la vidéo sur la télécommande (dont je parlerai dans le prochain article), ou celle avec l'envoi de la bande annonce de Sintel: http://salut-a-toi.org/media.html et http://salut-a-toi.org/specifications.html#exp
[^] # Re: Merci de parler de XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 5 - les discussions de groupe (suite) et les transports. Évalué à 5.
Salut, merci pour le commentaire :). La série a plus de succès que ce à quoi je m'attendais, on m'en a parlé plusieurs fois aux RMLL, et effectivement ça fait monter l'intérêt pour XMPP (ce qui était un peu le but). On m'a par exemple demandé si c'était utilisable pour la contrôler un robot (oui), ou pour faire de la surveillance de machine - ou « monitoring » pour ceux qui préfèrent - (oui aussi), d'ailleurs on m'a parlé de jimbo que je ne connaissais pas: http://www.darkcoding.net/software/jimbo/ .
Sinon oui je songe à faire des tutos par la suite, un bot est effectivement simple à faire, mais ça peut être l'occasion de présenter différentes façon de faire. Enfin on verra bien, c'est un peu en fonction de l'humeur au moment d'écrire.
[^] # Re: forges
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal SourceForge dans les choux. Évalué à 10.
Parce qu'héberger sur gittruc, c'est pas le contraindre à ouvrir un compte là bas ? Et à accepter les conditions d'utilisation qui vont avec, au passage.
[^] # Re: un concurrent des tribunes web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 4 - les discussions de groupes. Évalué à 8.
Ohhhhh, mais que vois-je arriver justement aujourd'hui: https://xmpp.org/extensions/xep-0359.html (Unique and Stable Stanza IDs)
\o/
[^] # Re: un concurrent des tribunes web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 4 - les discussions de groupes. Évalué à 3.
Oui ça ça marche sur un serveur centralisé, mais la synchronisation des horloges n'est pas triviale en décentralisé, même à supposer que tout le monde utilise NTP.
L'id est nécessaire pour identifier le message, ensuite à l'affichage tu représentes ça comme tu veux: norloge, chiffre, couleur, etc.
[^] # Re: un concurrent des tribunes web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 4 - les discussions de groupes. Évalué à 4.
J'ai fait un deal avec devnewton sur le sujet: je me pencherai sur la question et une fois implémentées il adhérera à l'association :)
En pratique j'ai commencé à regarder, et il y a les threads dans XMPP qui permettent de suivre une conversation, mais il n'est pas possible de spécifier plusieurs parents, ce qui est nécessaire pour un équivalent des norloges. L'autre soucis est que les ids des messages ne sont pas obligatoires, il faut pouvoir identifier un message sans id (ou alors réserver la fonctionnalité aux seuls messages qui ont un id). Enfin rien d'insurmontable, mais il faudra probablement une XEP pour que ça soit propre.
La fonctionnalité est intéressante, et ça serait particulièrement utile que ça fonctionne avec plusieurs salons à la fois, dans une même fenêtre. On a un petit refactoring à faire sur la gestion des message dans SàT, et je pense qu'ensuite une version expérimentale serait assez facile à faire.
P.-S.: j'aurais parié qu'il y aurait une question sur le sujet :)
# Pas vraiment un problème
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Facebook sauce XMPP est mort. Évalué à 6.
À mon sens ça ne change pas grand chose: la fédération était coupée (contrairement à gtalk), avec de la messagerie basique (enfin je ne sais pas où ça en était à la fin), et uniquement de le messagerie. Le seul intérêt était de pouvoir utiliser un client tiers et ainsi éventuellement chiffrer ses communications (à supposer que la personne en face fait la même chose).
Même si pour Google ça ne me gêne pas plus, au moins ils avaient la fédération, et ont fait des contributions majeures (enfin surtout une: jingle).
Utiliser XMPP pour que tout le monde ou presque se retrouve chez le même hébergeur, sans chiffrement ou fédération, sans contrôle sur les données, ça n'a pas grand intérêt.
Le seul point noir que je vois, c'est que ça risque de donner l'impression que XMPP est à l'abandon, ce qui est totalement faux (il suffit de voir l'activité sur les listes de diffusions ou les dépôts des logiciels XMPP).
[^] # Re: Migration de compte
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 2.
plusieurs jids pour une personne tu veux dire ? Si c'est ça, effectivement tu peux utiliser des passerelles XMPP <-> XMPP pour regrouper les comptes, ou alors utiliser un client multi-comptes comme gajim, psi ou SàT (j'ai un compte jabber.fr et libervia.org par exemple).
[^] # Re: Migration de compte
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 3.
désolé pour la réponse tardive, étant aux RMLL, je me connecte peu.
la XEP-0015 a été rejetée, je suppose pour des raisons de sécurité (il faudrait chercher les discussions de l'époque sur les archives pour être sûr). Tu ne peux pas changer de serveur automatiquement, cela pose des problèmes d'une part pour valider ton identité (comment s'assurer que c'est bien la même personne qui a fait le transfert ? Bon il y a probablement des solutions comme avoir un accès à l'ancien et au nouveau compte, ou une identification GPG, mais il y a le risque qu'une clef a été compromise par exemple, il faudrait y réfléchir sérieusement pour voir les problèmes), et d'autre part un réabonnement automatique n'est pas forcément une bonne chose (je n'aimerais pas qu'un contact sur jabber.fr déménage et que je me retrouve à écrire sur facebook.com sans m'en rende compte).
Il y a plusieurs XEPs utilisables: si tu as la main sur le serveur (encore une fois: autohébergez vous ou approchez vous d'une association locale !), tu as un format standardisé pour transférer les comptes (XEP-0227), et pour échanger des éléments sur roster, tu as la XEP-0114. Sans passer par les XEPs, un clients peut proposer de faire un réabonnement massif de tous tes contacts (c'est une chose qu'on va probablement proposer tôt ou tard avec SàT).
Là tout de suite je ne vois pas d'autre solution, peut-être qu'il y en aura un jour, mais comme on ne change pas de serveurs tous les 4 matins, ça ne me semble pas une priorité. Il serait intéressant de pouvoir au moins transférer l'historique (pour l'historique côté serveur, dans le XEP-0313, l'upload d'archive n'a volontairement pas été implémenté, pour éviter de trop compliquer la XEP), et indiquer qu'une adresse n'est plus valide (le plus simple étant probablement d'envoyer un message automatique pour dire qu'on a changé d'adresse, et pas besoin de XEP pour ça).
[^] # Re: Chiffrement et multi-poste
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal parlons XMPP - épisode 2 - le cœur et les extensions. Évalué à 4. Dernière modification le 08 juillet 2015 à 08:31.
désolé je réponds tard, mais je suis à Beauvais pour les RMLL depuis samedi, et du coup je me connecte peu.
Je ne sais pas ce que tu entends par là (je n'ai jamais vraiment utilisé facebook, et j'ai supprimé le compte que j'avais depuis longtemps), mais tu as plusieurs façons de faire:
si c'est par « plusieurs postes » tu entends des clients à différents endroits (par exemple téléphone, ordi fixe, ordi portable) pour le même compte, tu as Message Carbons (XEP-0280) qui permet ça, c'est de plus en plus implémenté
si c'est plusieurs personnes en même temps, c'est de la discussion de groupe (MUC, XEP-0045), je vais expliquer ça dans le prochain article mais je suppose que tu connais déjà le principe (en gros comme IRC)
si c'est un message de type « normal » (celui qui ressemble au courriel), alors tu as la XEP-0033 (Extended Stanza Addressing) qui permet d'envoyer à plusieurs personnes en même temps.
si c'est pour des messages type microblogage, c'est PubSub qui gère ça, j'expliquerai dans un futur article, et je vais faire une conf de 20 min sur le sujet demain pour les RMLL.
Alors là c'est un problème par contre parce qu'il n'y a pas encore de bonne solution pour le chiffrement de bout en bout. Enfin OTR est utilisé (mais pas encore standardisé avec XMPP), et couplé à message carbons tu le recevras sur plusieurs machines connectées avec le même compte. Si par contre tu entends ça comme une discussion de groupe, il n'y a pas encore de solution établie, c'est un vieux problème avec XMPP et il y a eu plusieurs tentatives mais rien qui n'a vraiment percé. Il était question de s'enfermer 2 jours avant le prochain Fosdem pour régler ça.
Tu devrais déjà avoir les pistes avec ce que je viens d'écrire, sinon indique moi ce que tu entends exactement par « recevoir les messages sur plusieurs postes en même temps ».
je suis content de voir que ça plaît, plusieurs personnes sont venues m'en parler pendant les RMLL :). N'hésitez pas à me dire si vous voulez voir des sujets particuliers traités (bon bien sûr il y a des domaines que je connais mieux que d'autres).
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 4. Dernière modification le 02 juillet 2015 à 14:05.
Nous avons déjà implémenté la XEP-0065 (socks 5, proxy65 c'est juste une implémentation - que nous utilisons d'ailleurs -), mais nous l'utilisons avec la méthode « historique » (la XEP-0096) qui est aussi la plus implémentée, mais qui a plusieurs soucis, en particulier elle traverse mal les NAT et firewalls.
Jingle permet aussi d'utiliser socks 5, mais la méthode de négociation est bien meilleure et permet d'établir une connexion dans pratiquement tous les cas, c'est la méthode recommandée aujourd'hui et c'est pour ça qu'il faut qu'on l'implémente.
Petite parenthèse: tu n'es pas obligé de passer par le serveur avec socks5, le proxy serveur n'est utilisé que si la connexion directe ne peut être établie.
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 3. Dernière modification le 02 juillet 2015 à 12:40.
oui jingle c'est pratiquement qu'une question de client, le serveur peut aider à établir une connexion ceci dit, et servir de relais si la connexion directe n'est pas possible. Enfin je ne suis pas spécialiste, n'ayant pas encore implémenté jingle on ne s'est pas trop penchés sur la question (mais on va le faire je pense assez vite pour le transfert de fichiers). Le mieux à faire est de demander directement sur le salon de Prosody: prosody@conference.prosody.im.
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 5.
Jappix et Movim lui préféraient Metronome uniquement parce que Metronome sauve les données PEP/PubSub hors ligne. J'ai vu plusieurs fois le développeur principal de Prosody (à chaque rencontre XMPP, ou au Fosdem), et lui ai posé la question. En gros la philosophie de Prosody c'était de tout garder simple, tout fichier, et pas de SGBD. Le dev de Metronome a fait une implémentation simple (de ce qu'on m'a dit, je n'ai pas été vérifier) mais qui fonctionne.
Là chez Prosody je crois qu'ils sont en train de voir pour faire un système relativement générique pour pouvoir utiliser différentes bases de données, enfin je suis ça de très loin puisque on utilise une autre méthode avec notre propre composant Pubsub. Mais je peux te dire qu'ils sont très compétents techniquement, et je fais toute confiance en l'équipe de Prosody.
Le gars sur Metronome semble être seul, mais très dynamique. Côté prosody y'a une communauté bien en place, très dynamique aussi et accueillante: j'ai pu résoudre les problèmes que j'ai eu très rapidement avec leur aide sur le salon.
Bref, l'un ou l'autre c'est une question de goût et de ressenti personnel. Pour ce qui est des composants nécessaires pour Jappix et Movim, il pourront profiter de ce qu'on a fait avec les XEPs et les modules qui vont bien, ainsi que le service pubsub qu'on a, donc ils seront tout à fait utilisables avec Prosody sous peu (cf http://linuxfr.org/users/goffi/journaux/xmpp-et-micro-blogage-la-donne-a-change ).
# baladodiffusion
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Émissions "Symbiose" de l'APRIL sur "Ici et Maintenant". Évalué à 2.
Salut,
j'ai pas pu écouter un direct, une baladodiffusion est déjà disponible ?
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 5.
Si Ejabberd te convient, c'est un bon choix. Prosody ça vaut vraiment le coup d'œil, Lua est simple à comprendre, et surtout très rapide. Et il y a beaucoup de modules communautaires (en plus des déjà nombreux modules officiels) pour utiliser avec à peu près n'importe quoi: https://prosody.im/doc/modules et https://code.google.com/p/prosody-modules/w/list .
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 4.
salut, difficile de répondre à ça vu que ça part assez vite en guerre de religion. En général mon critère de choix quand plusieurs logiciels semblent équivalent, c'est d'être dans un langage que je connais ou facile à apprendre, pour pouvoir corriger en cas de soucis, mais c'est parce que je suis développeur que j'ai ce réflexe ;).
jabberd est le serveur le plus ancien, je ne l'ai moi même jamais utilisé et je ne sais même pas s'il est encore développé.
ejabberd est une version en Erlang, et un des serveurs les plus complets et les mieux suivis actuellement, une référence. Par contre de mémoire les logs ne sont pas super pratiques à lire, enfin il faut l'habitude quoi. Depuis peu on peut l'étendre avec Elixir, en plus de L'Erlang de base.
J'avais utilisé OpenFire qui était très facile à installer, c'est du Java.
Sinon nous on utilise principalement Prosody: léger, très facile à installer, c'est du lua qui s'apprend très vite pour qui sait déjà programmer, et la communauté est très active. C'est celui que je recommanderais, surtout que c'est à l'heure actuelle le seul qui a des modules pour les XEP-0355 et XEP-0356 qu'on va utiliser pour SàT (cf http://linuxfr.org/users/goffi/journaux/xmpp-et-micro-blogage-la-donne-a-change), même si d'autres serveurs vont très probablement suivre (chez Ejabberd par exemple on est en contact avec un dév).
[^] # Re: Merci et une question
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 7.
Pour la visio-conférence, ça devrait être au point au moins chez Jitsi (même si j'ai moi même eu des soucis, comme avec la quasi totalité des logiciels que j'essaye pour ça, XMPP ou pas), si ça n'est pas le cas il faut remonter les problèmes. Pour le microblogage on avance à grands pas.
Le problème majeur, est de bien choisir un serveur, ou, comme je le disais dans un commentaire sur un des articles précédents, de l'installer soi-même ou de demander à une assoce locale afin de pouvoir contacter facilement les admins et demander d'installer ce qu'il nous manque.
Pour les clients, il ne faut pas forcément en chercher un qui fait tout. Certains clients (comme le notre) cherchent à implémenter le maximum de fonctionnalités, mais XMPP est prévu pour utiliser plusieurs clients en même temps, et il est tout à faire logique d'avoir un peu de fonctionnalités un peu partout: par exemple un salon de discussion pour un jeu, ou un client qui ne fait que la vidéo, avoir du transfert de fichier intégré au bureau, etc. Donc si tu utilises un client, rien ne t'empêche d'en utiliser un autre pour une autre utilisation.
ça c'est effectivement une bonne idée, et y'a des débuts de réponse avec la XEP-0302 qui indique les XEPs à implémenter pour avoir un client moderne (enfin moderne en 2012 :-/), et https://xmpp.org/about-xmpp/technology-overview/ qui donne des XEPs à implémenter pour différents cas (on m'a donné le lien sur le salon XSF).
moi aussi, et c'est une des raisons qui m'a fait commencer SàT ;).
[^] # Re: comme quoi Linux n'est pas prêt
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal parlons XMPP - épisode 2 - le cœur et les extensions. Évalué à 2.
En anglais probablement, avant XMPP je ne connaissais pas le terme en tout cas. Un des problèmes c'est qu'on (et je m'inclus dedans) a tendance à l'utiliser même en français.
[^] # Re: Vagabondage
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Salut,
il m'est aussi arrivé de coder en voyageant (principalement en australie), bon j'avais un van c'était un peu plus simple, mais sinon c'est dans les bibliothèque avec un pc portable léger le meilleur endroit: t'as du courant, des fois internet, une table et parfois du silence (y'en a qui aiment avoir de la musique pour bosser, moi il me faut du silence)…
[^] # Re: comme quoi Linux n'est pas prêt
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal parlons XMPP - épisode 2 - le cœur et les extensions. Évalué à 3.
Oui je ne sais pas pourquoi ils ont parlé de « roster » mais je trouve aussi que amène de la confusion. Il s'agit effectivement juste d'une liste de contacts.
Je pense que c'est aux clients à simplifier ça aussi: ce sont des choses internes qui n'ont pas besoin d'être nommées ou représentées de la même façon pour l'utilisateur final. La première fois que j'ai utilisé Psi, au début des années 2000, j'ai été un peu perdu en voyant la découverte des services (dont je vais parler dans la prochain article): ça n'a pas besoin d'être aussi visible. De même on n'a pas besoin d'utiliser le terme « roster » au niveau du client, surtout en français (ou toute autre langue que l'anglais) où ça ne veut rien dire !
[^] # Re: Financement
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie d'Ardour 4. Évalué à 2.
je parlais du principe en général, pas du cas particulier d'Ardour. Un ordinateur on peut aussi l'avoir eu gratuitement (don par exemple), ou s'en servir dans une bibliothèque/une association/je ne sais quoi.
Je ne critique pas du tout ce que fait Ardour, ou GCompris qui fai(sai?)t la même chose avec Windows, je dis juste que le modèle n'est pas parfait, et qu'il ne me semblerait pas judicieux de le généraliser. En dehors de la somme, tout le monde n'a pas une carte de crédit non plus. Après sur Android il y a des cas de logiciels payants sur le dépôt google, et gratuit sur F-Droid, c'est pas forcément une mauvaise idée (là y'a plus d'histoire de compilation, c'est un dépôt libre à installer).
[^] # Re: Financement
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie d'Ardour 4. Évalué à 2.
Un logiciel qui espionne ce que tu utilises, je suis pas hyper fan non plus. Et puis le temps d'utilisation n'est pas forcément lié aux besoins de dév, ou à l'utilité: photorecord/testdisk m'ont déjà sacrément aidé, et pourtant c'est pas le genre de truc que t'utilises souvent (enfin il vaut mieux).
Des discussions c'est surtout la constante du "il nous faut des sous" qui sort.
Je pense qu'il faudrait déjà un site qui regroupe les logiciels libres et leurs besoins, ce qui a déjà été donné jusqu'ici, ce qu'il manque, à quoi servent le logiciel et les sous, etc. Un truc géré de façon indépendante. La question serait de savoir dans quel ordre présenter les logiciels: par popularité serait probablement une erreur (les petits n'auraient jamais de sous). Au hasard ? Ceux qui ont reçu le moins en premier ?
[^] # Re: Financement
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie d'Ardour 4. Évalué à 2.
Donc la personne qui n'a ni les moyens, ni les compétences techniques, doit détailler sa situation pour avoir un binaire ?
Compiler depuis les sources il faut bien comprendre que c'est loin d'être à la portée de toue le monde (ne serait-ce qu'en temps à y investir pour savoir comment faire).
Bref, cette solution n'est pas parfaite.
Il y a un vrai problème pour le financement des projets libres c'est pas nouveau, et même pour les médias alternatifs en général. À PSES j'ai eu l'occasion de discuter avec pas mal de monde, c'est vraiment une constante.