Goffi a écrit 1523 commentaires

En séparant protocole et transport, on permets des optimisations selon le type d'accès: plusieurs connexions avec un serveur sur la fibre, une seule depuis un smartphone en 3G derrière un NAT…

Jingle permet de donner des priorités aux interfaces, ainsi tu peux favoriser une connexion Wifi par rapport à de la 3G (qui peut être payante ou limitée). Ceci ne serait pas possible avec une seule connexion.

Est-ce qu'un support des pièces jointes est prévu? Si je ne me trompe pas, le transfert de fichier présenté ici nécessite que le destinataire accepte le fichier et donc qu'il soit connecté.

Avec la XEP-0096, il y a un schéma d'URI qui est spécifié (dans la section 6.2), qui permet d'envoyer ou demander un fichier. Par contre il faut que l'entité soit connectée.

Avec Jingle, tu as un système pour demander un fichier explicitement, mais pas encore d'URI.

Alors il faut là encore que l'entité soit connectée, mais pour du transfert hors ligne, il suffit que l'entité en question soit ton serveur (exactement comme pour le web ou le courrier électronique). Un système d'URI est d'autant plus puissant que tu peux choisir de mettre des fichiers sur ton serveur (par exemple un album photo), ou d'envoyer directement en P2P si nécessaire/préférable.

Il y a aussi eu une XEP récente, HTTP upload (la XEP-0363) qui est très simple: elle consiste à spécifier l'envoi de 2 liens HTTP(S): 1 pour l'upload, 1 pour le download.
Je préfère personnellement utiliser Jingle qui est beaucoup plus puissant, mais il faut reconnaître que cette option a la simplicité pour elle, et elle peut-être adapté à un service externe.

Pour résumer donc: pour l'envoi de type pièce jointe il y a des URI, mais ça n'est pas encore spécifié pour le transfert de fichier via Jingle, ou HTTP Upload. Pour que ça soit dispo hors ligne, il suffit que ton autre pair soit un serveur.

Il manque éventuellement une XEP pour dire « ces URI sont des pièces jointes », mais c'est trivial à écrire ça.

Si un tel mécanisme existe pour le transfert de fichier, alors il n'y a virtuellement plus de différence entre l'utilisation d'XMPP et du mail.

XMPP est un excellent candidat pour remplacer le courriel, comme j'en parlais déjà en janvier 2011. D'autant plus qu'avec les passerelles, cela peut se faire de manière relativement transparente.

Encore merci pour tes articles de qualité et le temps que tu passes à vulgariser XMPP, SàT ainsi que tout l'écosystème autour.

Merci. Il y a une grosse activité sur XMPP qui peut donner quelque chose (on pourrait même parler d'une nouvelle vague), faut pas qu'on loupe le virage…

ouch
s/celle si/celle-ci/

Je précise pas toujours les typos que je vois en relisant, mais celle-ci faut pas exagérer :)

Salut,

oui les connexions sont chiffrées entre client et serveur et entre serveurs, c'est même obligatoire depuis l'année dernière (cf cette annonce et les précédentes).

Qu'en est-il du traffic qui transporte le binaire du fichier?

Dans le cas présenté dans cet article, le chiffrement n'est pas prévu. Aussi ton fichier passera en clair. Par contre en IBB (avec la XEP-0047), tu utilises le flux XML déjà en place, donc tu profiteras du chiffrement de celui-ci.

Avec Jingle par contre, le chiffrement est explicitement prévu, j'expliquerai comment dans le prochain article. Mais en gros tu peux demander une « pré-condition » de sécurité, c'est à dire une exigence pour le flux qui peut être du chiffrement de bout en bout. Là peu importe si tu passes par un proxy ou pas, c'est chiffré au départ et déchiffré à l'arrivée.

Par contre, il n'y a pas encore de méthode officielle pour les fichiers, pour la visioconférence il y a ZRTP (XEP-0262), mais je n'ai pas encore touché à ce domaine, donc je ne vais pas trop m'avancer dessus.

Il y a eu très récemment une proposition de XEP pour OMEMO/Axolotl, et une autre pour l'utiliser pour le transfert de fichiers. C'est une nouvelle méthode de chiffrement qui cherche à corriger les défauts d'OTR (qui est un gros bricolage avec XMPP). La XEP pour l'utiliser avec Jingle m'a paru mal employer ce dernier, j'ai remonté ça sur le chat et on va probablement en discuter sur la liste de diffusion. Mais en tout cas ça bouge et je pense qu'on va voir des solutions à moyenne échéance.

Un autre point à voir, en dehors des fichiers, est que Jingle est aussi intéressant pour de la messagerie chiffrée: en ayant une communication P2P tu évites le serveur, et donc un potentiel homme au milieu.

Enfin bref, le chiffrement évolue beaucoup en ce moment sur XMPP, je songe à faire un article dessus, peut-être après Jingle.

…uuencode/uudecode ça doit pouvoir le faire non, éventuellement avec en splittant les fichiers ?

uuencode pourrait être utilisé, mais base64 est standardisé (je ne pense pas que ça soit le cas pour uuencode, mais peut-être que je me trompe), et a priori plus portable. Bref, ça n'apporterait pas grand chose.

D'ailleurs y'a t-il une limite de taille de message via xmpp ?

Pas définie dans la RFC, par contre il est explicitement indiqué que l'administrateur devrait pouvoir configurer une taille maximum (pour éviter les attaques par déni de service principalement), mais celle si doit être supérieure à 10000 octets. C'est expliqué dans la RFC 6120 § 13.12 point 4.

Merci :)

Je dis ça par rapport à SàT: ici je parle de XMPP c'est général, utilisé par de nombreux logiciels, et tout à fait dans le cadre de DLFP, du coup ça me semblait logique de publier ici.

Pour SàT on fait déjà des dépêches de temps en temps, si je fais disons 1 article par semaine pour ne parler que du logiciel sur lequel on bosse, ça me semble un peu lourd, même si j'ai beaucoup de choses à dire :).

Est-ce qu'un modo peut corriger ça:
s/et d'essayer d'établie une connexion directe/et tenter une connexion directe/

Merci !

Je trouve l'idée très bonne : c'est bien de chercher des pistes de financement pour les logiciels libres, et celle là est très éthique (gratuit pour les gens vraiment sans ressources, un don pour ceux qui peuvent, recyclage du matériel trop vieux, récupération de celui encore en état).

Le financement des logiciels est le nerf de la guerre. On manque de plate-formes pour ce genre d'initiatives.

C'est d'ailleurs pourquoi les vrai hackers ne mangent que de la pizza contrairement aux informaticiens qui eux préfèrent la quiche lorraine.

je crois qu'on dit une « ouiche lorraine »

comme toujours un très bon journal, et très honnête, bravo !

Tu as fait une autre contribution pour nous: suite à une de tes confs aux JDLL y'a quelques années (2 ou 3 ans) tu es venu à notre stand et nous a conseillé sur quelques modifs pour notre interface web (Libervia), ce qui nous a été bien utile, merci encore :).

L'esperanto dans le code c'est une idée qui m'a traversé l'esprit aussi plus d'une fois, mais c'est un sujet délicat, je serais très intéressé par ton expérience éventuelle.

Pour Lua j'avais commencé avec un excellent commentaire de stackoverflow qui a été supprimé depuis, mais qu'on peut retrouver ici ou là ou sur archive.org. Ça m'a permis de rapidement pouvoir m'attaquer à des modules pour Prosody (on peut ensuite utiliser directement la doc officielle ou demander de l'aide sur le salon du projet).

Je l'ai plutôt mal placé dans mon texte, ça n'est évidemment pas une raison de notre choix, le logiciel n'est pas libre et on le regrette. Mais je ne connais pas de plate-forme en place similaire libre. La seule solution que je vois pour avoir du libre, c'est ce qu'on a fait au début de l'été: le faire nous-même (et encore, la plate-forme de paiement n'est pas libre elle).

C'est le côté ESS, le contact qu'on a eu, l'écosystème (comprendre les projets dessus), la commission moins élevée, et la possibilité d'éviter la plate-forme de paiement qui nous ont convaincu.

Ceci mis au point, je vais quand même expliquer pourquoi on a choisi Arizuka: nous ne sommes pas nécessairement contre Ulule ou Kickstarter, on a évalué les différentes plates-formes, ce qu'on aimait, ce qu'on n'aimait pas, les coûts, etc.

C'est à la fête de l'huma que quelqu'un m'a dit d'aller voir le stand d'Arizuka que je ne connaissais pas du tout, ce que j'ai fait. Ce site se concentre sur l'économie sociale et solidaire ou apparenté, même si leur logiciel n'est pas libre ils sont plutôt favorables au libre, et on a eu un bon contact tout simplement. D'ailleurs pendant qu'on a préparé la campagne nous avons été conseillés - je pense - utilement. Les autres projets que nous y avons vus nous paraissaient dans un bon esprit, et la commission ne semblait pas excessive (comparée aux autres plate-formes). Accessoirement on pouvait ne pas utiliser un système de paiement que nous voulions éviter.

Voilà, c'est un choix, bon ou mauvais c'est à voir, mais il a ses raisons.

Intelligent ça, de faire un commentaire agressif que l'équipe va lire… Re-prendre du temps pour répondre, ré-expliquer les choix faits, et se désoler (encore une fois) parce qu'une remarque facile est dite volontairement d'une manière blessante alors qu'elle aurait pu être un début de discussion, etc, etc…
La politesse et le respect c'est trop has-been, hein.

j'attends toujours le retour d'expérience de Pyjamas!

Ah j'avais parlé de ça ? Ça ne me dis rien, il faut pas hésiter à me le rappeler dans ces cas ;).

Pyjamas marchait vraiment pas mal (quelques incompatibilités, mais qu'on a appris à contourner), mais le projet est clairement mort suite au lamentable détournement que j'avais expliqué ici, et nos tentatives de le ramener à la vie (et dans Debian) ont échoué.
Nous sommes en train de suivre Brython qui semble la solution de remplacement la plus prometteuse (et c'est sur DLFP qu'on nous en parlé en premier, merci): c'est un interprète donc du vrai Python ce qui devrait régler pas mal de soucis, et la communauté est active et semble accueillante. Ma seule inquiétude à ce sujet est au niveau des performances, mais on ne sera fixés qu'une fois qu'on aura commencé à faire le port (ce qu'on envisage en 2016).

La doc oui ça nous manque, même sur le plan technique (on y travaille), je pense avancer dessus après la prochaine sortie. C'est surtout dû au fait que jusqu'ici on décourageait l'utilisation sérieuse parce qu'on n'avait pas encore une version suffisamment stable, la version qui vient va changer la donne (pas parfaitement stable, mais un grand bond pour le blogage).

Je pense faire quelques articles sur mon blog sur des exemples pratiques. Ça fait plusieurs fois que je vois des gens parler de cas d'utilisation qu'on rempli complètement (par exemple publier sur son blog depuis vim ou autre dans la syntaxe de son choix).

Salut,

on a lancé une campagne d'adhésion au début de l'été (fin juin), et on a estimé qu'il nous fallait 60 000 € pour avoir 2 salaires pendant 1 an (cf cette dépêche).

C'était un essai, et nous ne sommes pas assez connus/utilisés pour fonctionner de cette façon, mais ça nous a permis tout de même d'avoir des premiers adhérents, et d'avoir un peu de sous pour l'association (ce qui nous a bien aidé, notamment pour couvrir notre déplacement à la Froscon).

Cette fois on a décidé de jouer plus dans les règles en faisant une campagne plus typique, mais on a tout de même choisi une plate-forme qui semblait nous convenir, et nous avons écouté leurs conseils pour s'organiser (texte de présentation court, vidéo de 2 min, etc).

La première campagne est en pause et c'est un accident si tu es tombé sur le compteur, il va être enlevé.

Bonne chance, et faites un max d'articles de présentation des fonctionnalités pour les nuls, car c'est ça qui donne envie ou pas, qui fait comprendre l'outil, car même pour les geeks c'est pas évident de cerner ce que propose SàT (même si vous vous êtes améliorez et c'est pas trop mal actuellement :) ).

Merci. J'ai prévu de faire une série d'articles (peut-être plus sur mon blog, je ne veux pas spammer DLFP non plus) pour expliquer le côté technique mais aussi notre organisation et philosophie parce que ce sont des points très importants. Effectivement la communication c'est pas notre point le plus fort…

On va aussi sortir une nouvelle (très) grosse version bientôt (2 semaines si tout va bien), et il y aura entre autres une image Docker qui facilitera l'installation/l'essai.

Et il faut qu'on réussisse la campagne accessoirement ;)

Le problème est aussi que nous n'avons pas de téléphone avec cet OS sous la main, et les contraintes de temps (nous avons énormément de choses à faire comme tu peux l'imaginer). Mais si on a l'occasion (peut-être qu'avec un émulateur ça suffit ?), pourquoi pas.

Oui ça n'est pas un problème, et on fournira le paquet APK séparément de toute façon.

Honte à moi, j'ai oublié de remercier les relecteurs et correcteurs ! Je me rattrape donc: merci à Nÿco, palm123, souliane, Ontologia, ZeroHeure, Nils Ratusznik. ainsi qu'à Xavier Claude pour la modération.

Tu viens de trouver la formule pour estimer le développement de GNU Hurd

J'ai de plus en plus de mal avec les financements participatifs concernant du développement logiciel. Je n'ai presque que des expériences qui n'aboutissent pas ou alors complètement hors délais (mailpie, lavabit, lolix, etc.). La seule exception que j'ai en tête, c'est gcompris.

C'est extrêmement difficile d'évaluer un temps de développement, surtout quand on est tout seul et qu'on (re)part de rien. En plus sur les campagnes de financement il vaut mieux demander pas trop et donner des délais pas trop éloignés. Y'en a plus d'un qui se sont cassés les dents. Les temps de dév explosent vite parce qu'on pensait utiliser telle ou telle bibliothèque mais on se rend compte qu'il faut l'adapter, ou qu'elle va pas du tout (et c'est pas toujours identifiable avant de développer), ou parce qu'un truc très actif au moment de commencer est mort en cours de route (ça c'est du vécu), parce que tel problème est plus difficile à résoudre qu'on ne l'avait imaginé, etc.

Un des premiers conseils qu'on m'a donné quand j'ai commencé à travailler était pour estimer le temps de développement de quelque chose : « estime le temps qu'il te faut en comptant large, et multiplie ça au moins par 2 ». Je pense ne pas être le seul à avoir eu ce genre de conseil, et avec l'expérience il est tout à fait approprié.

Dans le cas particulier de Lolix, je ne sais pas trop où ça en est, mais on peut difficilement râler vu le boulot qu'il y a eu avant la campagne, pendant des années, et vu que ça a permis à nombre d'en nous de trouver un travail à un moment ou un autre.

Ce qui semble plus te gêner est de le faire sous forme ludique à la manière d'un jeu, non ?

Oui, c'est un point qui me gêne, et de manière générale j'ai l'impression que c'est une chose qu'on voit de plus en plus souvent. J'ai rien contre le divertissement bien sûr, mais si ça devient le but (ou le moyen) de tout ça me pose problème.

Mais encore une fois c'est un ressenti, et ce n'est qu'un des points que j'ai mentionné, et pas le plus important.

Non l'indice de sécurité je pense que c'est une bonne idée aussi (je le dis dans mon premier commentaire d'ailleurs), et elle pourrait même être reprise ailleurs.

C'est son utilisation sous forme de jeu qui me gêne, et c'est ce que j'en avais compris à la conf d'il y a 2 ans: comme s'il était nécessaire de rendre la chose ludique pour qu'elle soit comprise et utilisée.

En voyant cette conf et ce qu'il se disait à l'époque, je voyais ça comme un gros jeu ou il faut avoir le plus de points (et de mémoire le mot « gamification » avait d'ailleurs été utilisé dans la conf). Mais comme j'ai dit c'est flou, donc difficile à juger.

Je te défie de me démontrer que j'ai dit ça.

considérer qu'un utilisateur doit faire un effort intellectuel et qu'il ne faut pas enrober, et qu'il faut qu'il en chier pour mériter.

Tu considères que faire un effort intellectuel c'est en chier. Une personne incapable d'allumer son cerveau, c'est la définition d'un con.

Comme il faut un effort intellectuel pour comprendre que les gens ne souhaitent pas entrer dans ton éducation forcée, et comme il faut faire un effort intellectuel pour ne pas transformer "non souhait d'apprendre quand ce n'est pas utile" en "con".

Qui t'as dit qu'il y avait un non souhait d'apprendre (sources ?) ? Et d'où ça n'est pas utile ?

Comme toi tu peux comprendre plein de chose mais ne le fait pas (je le sais, car c'est techniquement impossible de tout comprendre). […] J'imagine que soit tu ne prends jamais l'avion, soit tu sais comment ça fonctionne, à la pièce près (ce que même les gens concevant les avions ne savent pas, car ils sont spécialisés).

Ça c'était facile à voir venir avec tes gros sabots. Donc:

1) je n'ai jamais dit que j'étais contre la simplification, c'est la mise en jeu systématique que je critique

2) je n'ai jamais dit non plus qu'il fallait tout comprendre tout le fonctionnement interne. Mais bon comme d'hab tu prends la partie de la phrase qui t'intéresses, tu l'entends comme ça t'arrange, et après tu enrobe ça d'attaques directes.

3) je ne connais pas tous les détails du fonctionnement de ma voiture, mais je sais comment et pourquoi il faut mettre de l'huile et de l'eau, et ce que c'est que faire une vidange. Si je vois un garagiste me faire une vidange pour 1000 €, je sais qu'il se fout de moi. Ici c'est pareil, un utilisateur doit savoir qu'un message passe en clair la plupart du temps, je ne lui demande pas de savoir ce que c'est que SMTP ou IMAP. Et le chiffrement est une notion que j'estime importante à comprendre, là encore je ne dis pas qu'il faut connaître les formules mathématique, mais savoir que ça sert à fermer l'enveloppe c'est utile oui. Et je ne pense pas que la mise en jeu soit la bonne façon d'apprendre. Peut-être que je me trompe, c'est un ressenti, mais j'attends toujours des arguments pour en discuter.

4) je sais que tu fais ça parce que ça t'amuses et que tu ne cherches qu'à susciter de la réaction (et surtout pas à discuter), mais la mise en jeu n'était qu'une partie anecdotique du message qui dit pourquoi je suis dubitatif avec CaliOpen pour le moment.

Il peut. Mais il n'a pas le temps de tout comprendre.

Ce serait bien d'arrêter de parler à la place des autres. Et je vais te donner un scoop: je suis un utilisateur. Et c'est rigolo, je ne me reconnais pas du tout dans ton discours.

Bref, on voit juste des gens passionnés par un domaine et qui pensent que tous les autres devraient connaitre leur domaine, alors qu'ils font exactement ce qu'ils critiquent pour d'autres domaines (car c'est impossible de faire comme tu dis pour tous les domaines).

Que tu fasses exprès ou pas d'être à côté de la plaque c'est une chose, mais ça serait bien que t'évites de parler à ma place. D'une je n'ai pas critiqué l'utilisateur (qui n'est pas un « il », mais un « nous ») mais la mise en jeu par les concepteurs (et j'ai dit que je regardais de travers), et de deux je n'applique pas ça qu'à l'informatique. J'entends certains gens dire que le cinéma n'est que pour se divertir et se vider la tête, et je ne pense pas comme ça. Et je n'ai jamais dit non plus que tous les autres devaient connaître le domaine ; pour reprendre tes mots: « Je te défie de me démontrer que j'ai dit ça. ».

ben désolé, mais les utilisateurs ont vraiment d'autres choses à faire, surtout quand ils savent que les développeur peuvent faire des choses plus simples.

Tu devrais faire de la télé-politique tu sais, tu as déjà l'arrogance et la façon de parler à la place des autres (« les français veulent ci », « les français pensent ça »). Bon il faut encore travailler un peu le style par contre.

Tu considères que l'homme est au service de la machine, d'autres considèrent que la machine est au service de l'homme.

Non justement, je considère que l'homme est capable de comprendre son outil, et que c'est nécessaire s'il ne veut pas être à son service. À ne plus rien comprendre ou savoir faire soi même, on en perd le contrôle: du courriel envoyé en clair sans le savoir à la voiture et son moteur caché qui se fait contrôler à distance.

Mais ça il faut faire un effort intellectuel pour le comprendre.

les gens voulant que ça soit différent n'ayant pas de considération pour les utilsateurs (bon, la, il y a aussi framasoft qui aurait compris.

Oui bien sûr, pas manichéen pour un sou avec ça ! Donc soit on prend l'utilisateur pour un con, soit on n'a pas de considération pour lui, superbe.