Goffi a écrit 1556 commentaires

Dans un pays anglophone, on lui répondrait de suite que c'est nom commun, pas protégeable pour le coup.

T'es sûr de ton coup ? Parce qu'il y a quand même un bon paquet de boîtes pas si petites qui ont des noms que je qualifierai de plutôt communs de fruits, de parties de maisons qui permettent de faire passer la lumière, de guerrières de la mythologie, de trombinoscope, et j'en passe.

Budget Insight contribue souvent mais avec un retard de plusieurs semaines, probablement pour garder un avantage concurrentiel)

Et ils l'utilisent en production pendant ce temps donc ? Ça ne me semble pas très compatible avec l'AGPL cette histoire.

s/actuelle/actuel/

(tiens j'ai inversé l'URL et le texte clair dans mon précédent message)
J'ai déjà été en contact avec un dév de Diaspora qui a contribué à ActivityPub (Jason), mais je pense que les 2 protocoles sont partis pour vivre leur vie séparément (je vois mal comment on peut faire pour collaborer à ce point, les technos sont assez différentes).

Il est surtout important de faire des passerelles, les différents réseaux libres doivent pouvoir communiquer ensemble. Si j'avais de quoi dégager du temps je serais déjà dessus, mais avec mon rythme actuelle, il va falloir attendre un peu.

Là je t'avoue que je n'en sais pas grand chose. Au niveau XMPP ça se passe entre l'IETF pour les RFCs de base (et des choses bas niveau comme https://tools.ietf.org/html/rfc7395) et la XSF qui a autorité sur les extensions (les fameuses XEPs). Je ne connais pas les liens exacts entre W3C et IETF.

Ce qui m'intéresse c'est d'avoir un standard libre et relativement bien fait, et j'espère que ça ne se tire pas dans les pattes volontairement (avoir la main sur un standard donne un pouvoir, c'est pour ça qu'il faut faire très attention à ce qu'on utilise).

ActivityPub ré-invente la roue en refaisant ce que fait déjà XMPP depuis longtemps, et c'est fort dommage, du coup on se retrouve avec un standard de plus alors qu'on aurait pu unir nos efforts.

Cette remarque faite, j'ai jeté un œil au protocole, et je pense qu'il serait assez facile de faire une passerelle XMPP, et du coup les sites communiqueraient ensemble au prix de ressources supplémentaires (faire des passerelles a un coût par rapport à une communication native, même si a priori je ne pense pas que ça serait énorme dans ce cas). Aussi si plusieurs sites suivent ActivityPub, ça simplifierait le travail (un seul protocole supplémentaire à gérer).

En tout cas j'aimerais faire une passerelle ActivityPub, mais il faudrait pour cela que la version ait suffisamment de succès pour que j'ai de l'aide sur le développement.

Dernière petite note: je trouve vraiment dommage d'inclure les notions de « like » et « followers » dans la base du protocole, c'est vraiment se calquer sur ce qui a été imposé par les réseaux propriétaires.

Libervia inclus un serveur HTTP, donc ça serait intéressant de prendre ça en compte à ce niveau aussi, mais c'est à voir bien plus tard.

Oui côté serveur XMPP et service Pubsub ça serait très intéressant aussi. Il y a déjà eu un peu de travail dessus dans le passé au niveau des salons de discussions (avec distributed MUC et federated MUC). Disons que ça n'est pas la priorité à l'heure actuelle, mais ça pourrait en devenir une dans le futur, surtout si on arrive à transformer l'essai avec le version à venir et qu'on a un peu d'aide (pour mémoire: je suis le seul développeur actif pour le moment).

oui, mon blog, c'est à dire l'interface web de SàT. Tu peux voir le code sur repos.goffi.org (en particulier la partie pages servers et les modèles correspondant.

Est-ce qu'il y a une notion de redondance, haute-disponibilité ? Si un site ("service"?) tombe que se passe t-il?

Pas pour le moment, le framework en est à son début, on verra en fonction des besoins/demandes/ressources disponibles. Il ne se destine, pour le moment du moins, pas à des sites qui ont besoin de haute disponibilité : il y a besoin de maturité, tests en production, etc. avant ça.

J'aimerais bien intégrer ces notions à XMPP même pour commencer, en particulier à Pubsub.

Spectrum2 permet d'utiliser libpurple et ses greffons, du coup jette un œil à https://developer.pidgin.im/wiki/ThirdPartyPlugins et à http://spectrum.im/documentation/backends/libpurple.html pour voir ce qui peut t'intéresser. Je n'utilise pas moi même, je ne peux pas t'aider plus que ça.

Vraiment super d'utiliser XMPP pour autre chose que de la messagerie instantanée, et de le montrer. Tes articles sont super didactiques en plus. J'ai hâte d'en lire d'autres :)

Goffi, avec tout le respect que j'ai pour toi et crois-moi ou non, en attendant avec impatience de voir sat-pubsub et Libervia sur Yunohost, je dois te répondre que tu te contredis:

il n'y a aucun problème à ne pas être d'accord, j'aime bien discuter ;)

La technologie Web « WebRTC » hérite et s'inspire de ce travail.

J'ai écris cette phrase suite à ce que j'ai lu sur le sujet sur Wikipédia :

L'API webRTC s'appuie sur des standards existants comme STUN, ICE, TURN, DTLS ou encore SRTP, technologies en parties issues du projet libjingle.

mais jingle sert à la gestion du signal (« signaling »), là où webRTC gère la gestion des périphériques, les filtres très difficiles à faire comme l'annulation d'écho et le flux, ils sont complémentaires, cf. la XEP que j'ai mentionné dans mon commentaire.

Gajim et Pidgin, par exemples, ont implémenté Jingle-vv, et ça ne marche pas avec WebRTC!

Jingle peut fonctionner avec WebRTC, mais également sans. On choisi le transport.

Je ne reproche pas que le standard évolue. Ce que je reproche, c'est ça: […]

je comprends que c'est frustrant vue de l'extérieur. Mais 4 ans ce n'est pas énorme du tout pour un standard (regarde côté technos web le temps que ça prend avec les énormes équipes qui sont dessus pour les implémentations), et Jingle est complètement d'actualité et je ne vois aucune raison que ça change dans un futur proche. Le problème ce sont les clients : la plupart des clients publics actifs sont des projets faits sur le temps libre, pas d'équipe payées, et du coup ça prend du temps. Je pense qu'il est difficilement d'imaginer le boulot que c'est, et chaque client a ses priorités. Ça fait longtemps que j'aimerais bien implémenter le vidéo par exemple, mais j'ai préféré travailler sur d'autre choses avant (même une vidéo en WebRTC one2one je pourrais la faire assez vite, en quelques jours je pense, mais ça serait quelques jours pris sur autre chose). Jitsi lui a mis la vidéo en priorité et a des dévs salariés : là ça tourne.

Il y a aussi beaucoup de client non public, XMPP est très utilisé en entreprise (on ne le soupçonne pas jusqu'à ce qu'on s'en rende compte dans les meetings et salons). Je l'ai déjà vu utiliser pour surveiller du trafic de tramway, pour du monitoring, je sais que c'est utilisé pour des communications satellites ou dans de la haute sécurité, mais ce n'est pas visible du public.

MIX, la prometteuse prochaine génération de salon, "arrive bientôt" depuis déjà 1an.
On prend la même recette qui fait fuir les utilisateurs et on recommence?

À ma connaissance, MIX n'est une priorité pour aucun projet actif actuel. C'est dans les cartons et ça avance à son rythme mais MUC tourne correctement pour le moment. Moi même je pense que ça va être une grosse avancée, mais que ça n'est pas indispensable à l'heure actuelle (Pubsub est nettement plus intéressant à court terme à mon avis).

Donc le standard, ça va être d'en avoir 2??

oui, même plus que 2.

Pour faire un standard, il faut prendre des décisions, même difficiles, même si ça veut dire que certaines choses ne seront pas optimales, même si ça veut dire sacrifier des possibilités.

Ça sera très probablement OMEMO qui sera utilisé par la plupart des clients. C'est au client de prendre les décisions pour simplifier la vie à l'utilisateur en fonction de son cas d'usage, et l'utilisateur n'a pas forcément besoin de savoir qu'il y a plusieurs méthodes. Qu'il y ait d'autres méthodes disponibles ne pose pas de problème si c'est bien géré par le client.

C'est dingue non? Une équipe trouve des ressources et suscite un gros enthousiasme chez un nombre d'utilisateurs non négligeable, se fait réclamer pour une implémentation dans un projet d'OS pour téléphone Libre, en utilisant les technos XMPP alors que les projets XMPP galèrent à trouver des contributeurs et n'ont que très peu de financement.

Ça devrait faire réfléchir, non?

Matrix ils sont issus de la même boîte et ont eu un gros financement permettant d'avoir des salariés à plein temps pendant plusieurs mois, c'est énorme et change complètement la donne. Tu fais la même chose avec n'importe quel protocole correct tu arrives à un résultat similaire. Ils sont très bons en marketing aussi, et ont les moyens (ils ont réussi à avoir un stand au Fosdem la première fois que je les ai vu + conf de 1 h avec alors qu'ils étaient inconnus, et faisaient le show avec un robot radiocommandé), et visiblement les contacts (gageons que l’association avec Purism ne s'est pas faite sur la simple visite du site). Tant mieux pour eux.

Je pense qu'un projet comme Movim, vu l'énergie, la stabilité et le résultat actuel a de quoi décoller, mais il y a aussi un facteur chance et réseau de connaissances. On verra ce que ça va donner.

Pour SàT c'est un cas très particulier, puisqu'on a se coupe volontairement de certaines sources qui pourraient nous aider (Fb, Twitter ou Github par exemple), et qu'on ne veut pas du modèle startup ou d'actionnaires : on a un projet politique.

On a aussi fait certains mauvais choix (on aurait dû faire des versions utilisables plus tôt plutôt que préparer une version « grand public » depuis des années), et on ne sait pas communiquer correctement (je vois régulièrement des projets apparaître qui font ce qu'on fait déjà ou ce qu'on pourrait faire facilement, et qui repartent de zéro, l'exemple actuel c'est les événements qui sont implémentés chez nous et qui vont être refaits de zéro chez Framasoft, et des cas comme ça j'en ai vu passer des tas).

Donc étonnés pas vraiment, et réfléchir on le fait (crois moi c'est souvent difficile moralement et physiquement non seulement pour ceux qui ont choisi de faire ça, mais pour l'entourage également).

Je t'invite à lire le parlons XMPP expliquant Jingle parce que tu n'as visiblement pas du tout compris comment ça fonctionne. WebRTC ne remplace pas Jingle il s'utilise avec, et il n'est certainement obsolète (ah la manie de toujours vouloir tout jeter).

Il n'y a toujours pas non plus de consensus autour du chiffrage bout-à-bout (OX? OMEMO?).

Il n'y a pas à choisir l'un ou l'autre, les 2 ont des propriétés différentes, et les 2 sont à garder.

Purism choisit Matrix/Riot pour le client messagerie/voix/vidéo + chiffrage bout-à-bout, parce que tout ce qu'ils veulent est déjà là.

Tout est tellement déjà là que la voix et la vidéo c'est Jitsi, et donc XMPP et Jingle (ils ont été les chercher dans la poubelle).

sur un réseau local, du broadcast serait sans doute plus approprié pour une diffusion de vidéo, comme dit par ailleurs.

Si tu veux que ça fonctionne à distance, alors oui XMPP pourrait être utilisé, notamment via Jingle (cf. https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-10-copie-de-fichiers-et-jingle-suite), et son chiffrement.

As tu regardé du côté de Jitsi ? Il fait déjà la partage d'écran, il peut servir de base. Je ne sais pas s'il peut être facilement extensible, mais ça vaut le coup d'y jeter un œil. Le Jitsi videobridge est une option pour diffuser la vidéo à plusieurs utilisateurs.

Je pense qu'il y a quand même beaucoup de boulot, même si tu trouves une bonne base. Tout ce qui touche à la vidéo peut prendre facilement du temps, surtout si tu veux bien sécuriser ça. Jette un œil aux bibliothèques disponibles pour voir celles qui gèrent Jingle.

J'aurais pu te conseiller SàT sur lequel je travaille, mais on ne fait pas encore de vidéo et ça ne sera pas la cas avant la prochaine sortie, donc plusieurs mois. Par contre on gère déjà chiffrement, commandes, et Jingle (mais par pour la vidéo encore).

Bon courage !

Il me semblait bien que JabberFr autorisait les nom de domaines perso, mais j'ai demandé confirmation pour être sûr, voilà ce qu'on m'a répondu :

Faut juste nous contacter pour nous communiquer le nom de domaine, et faire pointer un CNAME (ou un SRV, mais du coup le certificat ne sera pas valide parce qu’on utilise Let’s Encrypt).
Et bien sûr, une adresse email de contact.

le(s) compte(s) utilisateur à créer (ça n'utilise pas les comptes UNIX).

jette un œil au modules mod_auth_* sur https://modules.prosody.im/ qui permettent d'avoir des méthodes alternatives pour utiliser des comptes existants (il y a notamment un module PAM, à tester).

Les mots de passe sont en clair par défaut sur Prosody, mais on peut les hasher, c'est expliqué sur leur site : http://prosody.im/doc/plain_or_hashed

Pour OpenPGP j'ai expliqué plus haut (la 0027 est à éviter, mais il y a une version moderne et propre, appelée OX).

Les différents chiffrements ont différentes propriétés, j'ai commencé à écrire un article pour expliquer ça, mais je n'ai pas eu le temps de le finir. En gros OTR ne permet de communiquer qu'avec un seul appareil, OMEMO le permet et gère la confidentialité persistance et OX gère plusieurs appareils sans la confidentialité persistante (mais du coup permet d'avoir les archives sur le serveur). Après c'est le rôle du client de rentre ces notions le plus simple et pratique possible pour l'utilisateur, sans sacrifier la sécurité.

Prosody il vaut mieux utiliser la version à jour. Si tu es sur Debian ou dérivée, tu as un dépôt officiel avec les versions à jour, c'est expliqué sur la doc officielle. C'est très facile à installer.

sont des pré-requis : il faut utiliser OMEMO (PGP est déprécié, et OTR ne permet pas 2., cf mes autres commentaires).

Petite correction, PGP n'est pas déprécié, c'est la XEP historique (c.-à-d. qui a été implémentée au début et qui n'a pas fait l'objet d'un processus normal de standardisation, mais qui décrit un état de fait) qui l'est. La version moderne, propre et sécurisée s'appelle OX, c'est la XEP-0373.

Pour le reste je lis les commentaires, beaucoup de critiques sont justifiées, pas toutes.

Il faut toutefois garder à l'esprit, comme cela a été dit par ailleurs, que la plupart des projets sont développés sur le temps libre, et que chaque fonctionnalité prend un temps fou.

Par exemple dans notre cas (SàT), c'est actuellement un seul développeur actif (moi, avec 1 jour/semaine dédié au projet, et 4 à un boulot salarié qui n'a rien à voir).

Pour donner des exemples : au moment d'implémenter le chiffrement de bout en bout l'état de l'art était OTR, ce qui a désormais changé (il est question bien sûr d'implémenter OMEMO et OX, mais je ne peux pas tout faire en même temps). Une implémentation dans notre cas et dans le cas particulier du chiffrement de bout en bout signifie en fait 2 implémentations : une dans le backend pour les plupart des frontaux, et une en javascript pour le frontal web. De même la vidéo est prévue depuis longtemps, et la base est déjà faite (jingle), mais il y a eu d'autre priorités qui devaient passer avant, surtout qu'il existe déjà des solutions satisfaisantes compatibles (Jitsi).

Movim c'est principalement un seul dév également, Gajim c'est du même ordre, Conversations c'est un seul dév mais à temps plein (il en vit), etc. Matrix de son côté à eu un budget conséquent avec une dizaine de salariés à temps plein (sauf erreur), forcément ça aide à avoir une solution plus léchée.

Un des objectifs de SàT (l'asso) est de développer une activité économique pour que déjà je puisse me salarier, puis si possible embaucher du monde, mais nous voulons faire ça selon nos principes éthiques/politiques et évoluer vers une coopérative à terme (SCOP ou similaire) en autogestion. Si nous y arrivons, ça changera complètement la donne (et ma vie, puisque c'est un investissement sur mon temps qu'il est je pense difficile d'imaginer).

oui même inquiétude (j'ai écris la même chose plus bas avant de voir ton message).

Pour le recyclage j'avais vu il y a 2/3 ans des systèmes qui broyaient le plastique et le recompressait pour ré-utiliser une partie des déchets (je n'ai pas le lien sous la main mais ça doit se retrouver assez facilement), c'est mieux mais pas génial (toujours une perte, plastique recyclé évidemment de moins bonne qualité, et énergie nécessaire pour la transformation).

Est-ce qu'il y a des imprimantes libres qui travaillent en usinant du bois par exemple ? Ou utilisant d'autres matériaux moins nocifs que les plastiques ?

Salut,

j'avais acheté une Smartrap suite à ton journal d'il y a 3 ans, et j'en étais très content (mais ça demande du calibrage). Je m'en étais servi pour refaire une pièce manquante sur un lave vaisselle (avec FreeCAD qui est super, il mériterait une dépêche tuto), plus pour le fun parce que je savais que ça n'allait pas tenir avec la chaleur, mais la pièce fonctionnait (tout comme une vis au final qui elle tient la chaleur).

Là j'ai toujours l'imprimante mais elle est démontée suite à un déménagement, et je n'ai vraiment pas le temps de la remettre en état à l'heure actuelle (puis au final, j'ai pas grand chose d'important à imprimer).

Mais du coup je me demande pourquoi tu en as racheté une ? L'idée n'était pas qu'on puisse réparer et faire évoluer cette imprimante en imprimant les nouvelles pièces ? Quel intérêt d'en prendre une autre ? Imprimer plus d'un coup ? Autre ?

C'est génial pour ce que ça ouvre au niveau créativité ou réparations etc., mais par contre je suis un peu inquiet des conséquences écologiques, il est assez prévisible qu'on va voir exploser des impressions plastiques plus ou moins inutiles qui finiront pour beaucoup à la poubelle.

La XEP-0070 est déjà implémentée dans SàT (et notamment utilisable via Cagou l'interface Android/bureau), on a même pas mal communiqué autour de cette XEP pour la faire connaître.

Mais elle permet uniquement de s'assurer de qui est un contact (on entre son identifiant, et on vérifie que la personne qui se connecte a accès au compte indiqué), pas de publier à la place de la personne. Pour ça, il faut soit que la personne sur un serveur externe ait un client capable d'utiliser la fonctionnalités voulue (ici les tickets), soit qu'il y ait une connexion via un système sans transmission de mot de passe, par exemple via OAuth.

Effectivement c'est peu. Mais ce n'est pas forcément leur seule source de revenus

Liberapay, les cotisations et les (rares) dons sont nos seules sources de revenues, c'est indiqué dans nos assemblées générales (cf. la dernière par exemple).

Pour ce qui est des déplacement (par exemple pour venir au POSS d'où j'écris), l'hébergement, le matériel, etc. C'est de notre poche, et on se fait parfois rembourser par l'association.

Merci !

Il y a bien sûr encore du boulot pour arriver au même niveau de confort que les grosses plateformes, mais c'est déjà utilisable en l'état, et ça peut aller vite si un peu de monde suit.

Les applications vont bien au delà du rapport de bogues, on peut mettre les champs qu'on veut dans les tickets, et les merge-requests sont un exemple d'utilisation.

Il est aussi facile de faire des automatisations (étant basé sur pubsub, chaque nouveau ticket envoie une notification par exemple), et j'aimerais bien ajouter un système d'intégration continue (des tests automatisés) qui nous seraient bien utiles pour le développement de SàT.

J'espère aussi trouver du monde pour avancer sur le développement, si des développeurs python passent par là :)

Bon allez, je vais quand même placer Primitivus, notre frontal TUI (console), puisqu'il s'inspire de Vim et est modal, donc pour tout ce qui touche à la messagerie (soit directement en XMPP, soit via des passerelles).

Pour l'édition j'ai testé le mode Evil, cherchant à me remettre à Emacs alors que je ne l'ai pas utilisé depuis à peu près 10 ans. C'est pas mal, mais on est quand même très loin du confort de vim quand on y est habitué (des trucs tout bêtes comme C-a C-x pour incrémenter/décrémenter ne fonctionnent pas de base – mais je crois que c'est possible avec une extension –, et évidemment des commandes comme :mksession ne sont pas disponibles). Il faudra que je m'y penche un peu plus, mais je n'ai pas trop le temps en ce moment. Mon objectif est principalement d'utiliser le org-mode qui a l'air vraiment super, et éventuellement d'interfacer SàT avec.

Sinon j'ai fait un commentaire dans un journal précédent avec quelques alternatives à Pentadactyl/Vimperator.

pour les pages d'extensions (et certainement about:config) je crois que c'est une limitation des webextensions. Par contre pour le nouvel onglet, vim-vixen indique dans la note de sortie de la 0.5 (sortie il y a quelques jours) qu'il est désormais actif dans about:blank, cf. https://addons.mozilla.org/en-US/firefox/addon/vim-vixen/

Un peu hors sujet mais pas tellement, j'utilise depuis des années Pentadactyl, une extension qui permet d'avoir un comportement à la Vim, en rendant Firefox modal, en supprimant (optionnellement) la barre de navigation et d'outil, et surtout en rendant le navigateur très facile à utiliser au clavier (une fois qu'on a pris les habitude, c'est très très pratique d'ouvrir une page en faisant un simple "o" ou "O" pour ouvrir dans un nouvel onglet).
Bien que le paquet n'était plus mis à jour sur le dépôt d'extensions de Firefox, je continuais à l'utiliser avec des astuces (changement de version maximale à la main) ou des build qu'on trouvait par-ci par-là, mais la fin de XUL annonce la fin définitive de cette extension.

Du coup j'ai cherché des équivalents (pour l'instant je continue d'utiliser sur ESR), et je me suis arrêté sur 3 options, ça peut peut-être intéresser du monde:

• vim-vixen: il me semble le plus prometteur, très réactif (plus que Pentadactyl), il est activement développé et a déjà les raccourcis de base. Il ne me manque que les quick marks (et je ne suis pas le seul) pour que je sois à l'aise.

• tridactyl: qui cherche à refaire Pentadactyl/Vimperator en webextension. Ça n'est pas encore dispo (enfin il y a des builds de test que je n'ai pas essayé), mais c'est très actif. À surveiller de près.

Les webextensions ne permettent pas pour le moment de reproduire toutes les fonctionnalités, la 3ème option que j'ai commencé à tester c'est un navigateur indépendant construit directement pour être utilisable à la Vim.

• qutebrowser qui est basé sur Qt (avec QtWebEngine ou QtWebKit pour le rendu). C'est bien fait et réactif, on est tout de suite à l'aise. Les marque pages sont moins pratiques que les quickmarks de Pentadactyl, mais sinon on s'y retrouve. Par contre le moteur (par défaut) est loin derrière Firefox, au niveau du CSS par exemple, les grilles (grid) ne sont pas gérées correctement.

Voilà, si ça peut servir à d'autres…