En effet on a introduit ça dans SàT depuis pas mal d'années et on a développé un serveur PubSub (qui est en gros la base de donnée du blog) qui gère ça (https://repos.goffi.org/sat_pubsub). Ce qu'on a introduit c'est principalement 2 choses:
pouvoir gérer les permissions au niveau d'un item (c.-à-d. d'un billet de blog)
pouvoir utiliser les groupes de la liste de contact (ou roster), comme « famille » ou « amis »
Par défaut (sans nos améliorations) il est tout de même possible de gérer des permissions pour un « nœud » pubsub (c.-à-d. pour un ensemble d'items, de billets, un peu comme un flux Atom ou RSS) à l'aide d'une liste blanche (on autorise au cas par cas qui peut lire le nœud), ce qui peut être vite fastidieux, et je ne crois pas que c'est intégré dans aucune interface de client à l'heure actuelle.
Je n'ai pas encore rédigé de spécification pour notre fonctionnalités d'une part parce qu'au début il fallait tester pour voir si c'était viable (ça l'est), et d'autre part tout simplement parce que je suis débordé. Je suis le seul développeur actif sur SàT aujourd'hui, et j'ai des tonnes de choses sur les bras (sur mon temps libre, j'ai un travail salarié à côté). La priorité c'est de stabiliser et d'avoir une version utilisable et agréable le plus rapidement possible.
Je ne suis absolument pas d'accord avec ça. Le jargon rend la compréhension plus compliquée, et favorise l'exclusion. Même dans le milieu informatique que je connais pourtant bien, je suis régulièrement obligé de chercher la signification de mots ou abréviations (dont certaines peuvent en plus changer de sens selon le contexte). Alors dans l'info je suis d'accord que parfois il est plus compréhensible de garder le mot technique ou anglais (parce que utilisé dans une commande, ou parce qu'il n'y a pas de bon équivalent), mais c'est, de mon expérience, très rare.
En plus de ça, on voit de plus en plus de contresens avec des mots anglais utilisés dans une autre langue (ici le français) alors qu'il veut dire tout autre chose. Par exemple « issue » qui veut dire « problème » en anglais et qui a un tout autre sens en français. Quand on me dit « regarde cette issue » j'ai plus tendance à regarder vers la porte que mon écran d'ordinateur.
Autant je ne suis pas pour être trop à cheval sur les règles d'orthographe et de grammaire (enfin ça dépend du contexte), autant l'utilisation de jargon et/ou systématiquement de mots anglais rend la compréhension plus difficile et élitiste.
Bref utiliser le terme adapté à la langue et l'audience quand il existe, ou expliquer un terme entre parenthèses faute de mieux est une bonne pratique à mon avis.
Quid des formats de données et permissions ? Par exemple si sur un projet je ne veux que les étiquettes "WIP", "v1.2.3" et "DEV" ? Et si je ne veux autoriser que toto et tata à modifier l'état du bug ? Est-ce qu'on peut modifier les commentaires des autres ?
Est-ce que ça aurait du sens d'étendre pour des merge requests ? Git permet bien entendu d'utiliser une branche pour ça, l'intérêt serait de permettre de commenter le code avant de pouvoir réellement merger la branche.
Ça se rapproche de ce que fait Fossil si je ne m'abuse (je n'ai jamais utilisé moi même, mais il me semble qu'il intègre tout directement, tickets, wiki, etc.), c'est vraiment une bonne idée et la possibilité de travailler hors ligne est super (même si on n'utile pas comme système de tickets principal, ça permet de faire tampon quand on est hors ligne).
Bon je pourrais vérifier moi même mais je fais mon fainéant là :), comment ça marche pour créer un importeur/exporteur ? Ça a l'air d'être du JSON, y'a une API pour récupérer directement les opérations assemblées et le ticket final ? Je travaille sur un gestionnaire de tickets et de merge-requests décentralisé (basé sur XMPP), et ça m'intéresserait de pouvoir faire les tickets en local quand internet n'est pas dispo, et de pouvoir synchroniser après coup.
Pour pubsub ça fait des années que nous avons écris une implémentation alternative qui fonctionne avec Prosody (et qui est probablement l'implémentation pubsub libre la plus avancée à l'heure actuelle au niveau des fonctionnalités).
Après encore utile ou pas, c'est à toi de voir, c'est une implémentation alternative, et c'est maintenu (enfin après un long moment sans maintenance, ce qui n'a pas été pas super).
Et pour XMPP qui stocke ma liste de contacts côté serveur, on fait quoi?
on lit ce que j'ai écris plus haut. Ça n'est pas centralisé, ça n'est pas lié à un appareil physique facilement traçable, on peut compartimenter (plusieurs comptes sur des serveurs différents par exemple).
Que le serveur connaisse les contacts est un problème, mais c'est difficilement évitable (nécessaire pour un tas de raisons comme la lutte contre le spam ou la protection des données), et tu as toujours l'option de faire tourner ton propre serveur (ou utiliser celui de quelqu'un(e) en qui t'as vraiment confiance).
Et oui il faut faire confiance, je pense que c'est un point important, il faut savoir faire confiance à un moment où un autre. Mais la responsabilité n'est pas la même quand t'as un certain nombre d'utilisateurs, et quand t'as tous les utilisateurs.
Sauf que l'annuaire ce sont des numéros publiques (et on peut refuser, liste rouge), et que ça ne fait pas le lien systématique entre tous tes contacts et toi. À la base c'est papier et chacun a une copie, avec les services actuels on peut associer à un numéro que tu demandes, mais ça n'est pas tous tes numéros, et ça n'est pas systématique (c.-à-d. pas pour tous tes contacts), et accessoirement ça ne sait pas si tu gardes le numéro ou pas (si tu gardes le numéro, c'est a priori que t'as un contact plus ou moins régulier).
D'autre part, ce n'est pas parce qu'on est habitués à quelque chose que c'est bien. Le téléphone c'était historiquement en clair et facile à écouter, ça ne veut pas dire que parce qu'on a été habitué à ça, pas la peine de chiffrer les communications.
Et il faut aussi comprendre que les possibilités de stockage et surtout d'analyse des données a explosé depuis 20 ans. Une des révélations de Snowdew et que les services gouvernementaux sont capables de remonter dans le temps de plusieurs jours. Ça n'était pas une chose imaginable dans les années 70 ou 80.
Et les gens ne se rendent pas forcément compte que Whatsapp fait une carte des contacts (les permissions demandées sont très probablement survolées et acceptés sans question par la plupart des personnes. Lire les contacts pourrait être légitime, c'est envoyer au serveur qui pose problème).
Donc non, effectivement, les gens, ils ne voient pas le problème avec ça. Ou bien ils sont sur liste rouge et/ou ils ne créent pas de compte Whatsapp.
Je ne suis pas sur Whatsapp, mais ils ont mon numéro associé à mon nom, comme expliqué plus haut.
Non ça n'est pas secret, j'en ai déjà parlé sur le salon de SàT. Je pense qu'il est possible de faire de la découverte de contacts en demandant à tes contacts eux-même de te renseigner, mais en compartimentant.
Je m'explique : imagine que j'ai dans mes contacts ma sœur mais je ne connais pas le jid de ma mère. Mon client fait une demande et voit que ma sœur a autorisé tous les membres du groupe « famille » à s'échanger les contacts, elle a le jid de ma mère associé à son nom, et me renseigne donc. Elle peut également m'envoyer la liste complète des identifiants qu'elle connaît des membres de ma famille. C'est comme si je l'appelais pour demander un numéro de ma famille, mais en automatisant.
En plus de ça, chacun pourrait indiquer dans son client s'il souhaite autoriser ses contacts à échanger son identifiant, éventuellement en affinant (ex. : ma famille oui, mais pas mes collègues).
Les avantages sont nombreux:
c'est décentralisé
ça demande une autorisation explicite, c'est respectueux de la vie privée
c'est compartimenté: je peux autoriser ma famille à partager mon contact, mais pas mes collègues parce que je ne veux pas que mon patron me contacte le week-end
ça n'est pas lié à un appareil physique facilement traçable
Reste à faire en sorte que ça soit facile à utiliser. Y'a du boulot et des réflexions à avoir, mais ça n'est pas insurmontable.
Je parle du consentement de tes contacts. Mon numéro a été envoyé plusieurs fois, en l'associant à mon nom, à WhatsApp par mes proches sans que je n'ai jamais autorisé ça (et j'y suis même opposé). En plus de ça il peuvent faire une carte des mes connaissances alors que je n'ai jamais utilisé ce service.
Il n'est absolument pas impossible de demander le consentement des personnes avant de diffuser un numéro, je ne vois pas ce qui l'empêche (évidemment ça demande un effort, mais j'appelle ça du respect de tes contacts). Alors oui tu peux n'en avoir rien à faire et afficher ça publiquement sur le net ou ailleurs, tu peux aussi le faire avec des photos nues des tes (ex) partenaires si tu pars comme ça, ceci dit je doute de la légalité de la chose (et je suis certain de l'absence d'éthique).
Sans jeter la pierre à Daniel, je suis absolument opposé à ce genre de solution.
Déjà c'est, comme mentionné, centralisé, proprio et payant. De ce que j'ai compris, il faut payer pour associer son jid à un numéro, mais en plus on ne peut utiliser le service que si on est sur ce serveur. Le site affirme que l'annuaire n'est pas stocké, mais aucun moyen de vérifier ou de s'assurer de la sécurité de ce qui est envoyé. De là 2 possibilités: soit le service devient très populaire et il est en situation de monopole, soit non et la plupart des contacts ne seront pas répertoriés, du coup l'intérêt est plus que limité.
Mais mes plus gros problèmes avec ça sont :
l'utilisation d'un identifiant associé à un appareil physique et facilement traçable
l'envoi des contacts avec une association numéro/nom sans leur demander leur consentement, et sans compartimentation
Les gens qui choisissent d'envoyer leur numéro (en supposant qu'ils comprennent bien que c'est ce qu'il se passe), c'est une chose, mais envoyer ceux des contacts sans permission c'est inadmissible (et je ne suis même certain que ça soit légal en Europe avec le RGPD).
Bref, l'intérêt par rapport à Signal est limité (oui ça reste compatible avec le reste du réseau XMPP, mais si ça devient vraiment populaire ce service deviendrait incontournable).
Je pense qu'il y a d'autres façons de faire, plus propres et éthiques, pour la découverte des contacts, et j'ai déjà plusieurs idées en tête. Dès que j'aurai du temps (vu ma liste de choses à faire, pas tout de suite) je vais essayer de travailler un peu sur le sujet.
Un grand merci aussi à l'orga, je ne regrette pas d'être venu (sprint + confs), l'ambiance était excellente, on a bien avancé (merci également à ceux qui sont venu participer au sprint).
J'ai pu rencontrer l'équipe de Kivy qui est également très sympa et ce qui a permis de bien progresser sur quelques points qui me gênaient. Au passage une dépêche collaborative a été commencée, de l'aide pour l'étoffer serait bienvenue !
En plus de l'avancement côté dév, ça a été l'occasion de faire des rencontres intéressantes, des contacts, et de revoir avec plaisir certaines têtes que je connaissais. Bref, je ne regrette vraiment pas d'être venu.
J'ai eu aussi des commentaires judicieux suite à ma conf, notamment l'idée de séparer par paquets les fonctionnalités (par exemple en faisant chat et blog uniquement par défaut, puis un paquet partage de fichiers, un paquet forge logicielle, etc.). J'avais déjà l'intention de faire un système de téléchargement de greffons, mais les regrouper par thème est une très bonne idée. C'est vrai que pendant la conf (et également après mon dernier journal) je me suis rendu compte que le nombre de fonctionnalités a priori différentes perdait les gens.
Je ne comprends pas ton commentaire, tu demandes à quoi sert la décentralisation pour un album photos ?
À la même chose que pour un blog. Entre autres, t'as pas besoin de recréer un compte pour voir les photos de toto@example.net alors que t'es chez titi@invalid.fr, tu peux gérer les permissions facilement, tu peux avoir des photos et/ou commentaires à différents endroits, etc.
Bon ben puisqu'on parle des alternatives je vais en profiter pour dire que c'est aussi possible avec SàT. Ça sera disponible dans la version à venir, et je pense que ton cahier des charges est à peu près respecté : libre, gestion d'accès, invitations via URL et vidéos (mais il n'y a pas de multi-encodage, donc pour du multi-plateformes il faudra un format qui passe partout, une amélioration à envisager). Plaisant et simple c'est effectivement subjectif, mais on est ouverts au suggestions/contributions et il y un moteur de thèmes puissants. En prime, XMPP oblige, c'est décentralisé/fédéré.
Pendant des années, on recevait énormément de critiques très virulentes et mauvaises. Et je dois dire que personnellement ce fut très dur de faire face à la méchanceté de certains. Ce n’est pas étonnant que la dépression guette beaucoup de développeurs de logiciels libres. Il m’est arrivé à plusieurs reprises de ne plus avoir la force de contribuer pendant plusieurs jours (et de me poser des questions sur pourquoi je faisais du Libre) après trop d’insultes reçues.
C'est malheureusement assez courant dans le monde du logiciel libre (et pas que), et ça peut en effet être difficile à encaisser. C'est vraiment triste.
C'est vraiment super ce que vous faites : joindre développement avec production artistique. Vous êtes effectivement proche de Blender dans l'esprit, j'espère que vous allez en inspirer d'autres.
Bon courage, même s'il y a des hauts et des bas, vous allez dans le bon sens, et vous pouvez lancer un nouveau mouvement dans la création artistique et le développement de logiciels.
Super, merci à tous ceux qui travaillent pour maintenir ce site.
2 petites remarques pour l'article sélectionné :
En haut de la page d'accueil, la première dépêche est un contenu sélectionné par l'équipe de modération et qui reste pendant quelques jours en Une du site. Il est ressorti de l'enquête que cette dépêche qui ne change pas souvent pouvait être vue comme une absence de nouveaux contenus sur le site et prêter à confusion. Nous adoptons un nouveau style pour cette dépêche, ce qui devrait permettre de mieux la distinguer des autres contenus.
pourquoi ne pas mettre un bandeau « article sélectionné par la rédaction » ? Ça rendrait les choses plus claires, et serait certainement plus compréhensible pour les personnes qui n'ont pas la mise en page CSS (lecteur braille par exemple)
on s'est demandé une fois sur notre salon si les articles étaient sélectionnés par la rédaction ou par un algorithme, tu réponds à cette question en précisant que c'est la rédaction qui sélectionne. Ce serait une information utile à mettre en petit sous l'article (ou ailleurs)
Apparemment, depuis Vim 8.1.105 il y a une nouvelle option de compilation (+vartabs) qui permet l'implémentation de cette fonctionnalité, à suivre donc.
Ça peut être intéressant d'envisager le développement à base de plugin, afin de faciliter l'ajout d'une fonctionnalité par d'autres devs et de permettre aux administrateurs d'activer ou désactiver ce qui est vraiment approprier dans leur projet.
Oui c'est l'idée à moyen terme. Mais de toute façon c'est principalement pour notre utilisation à l'heure actuelle, et du coup on (enfin je pour le moment) développe ce dont on a besoin. Après ça sera en fonction des demandes, du temps qu'on peut y consacrer, et des contributions.
À mon avis, les 2 fonctionnalités les plus importantes sont la gestion des tickets/bugs, et les requêtes de fusion (gérer ses patchs, faire la revue), et ça c'est déjà en place. Après c'est de l'amélioration petit à petit. Je pense ajouter assez vite un système de tests automatisés, et éventuellement une génération de doc.
Y'a aussi des choses très intéressantes à tout avoir sur XMPP : on peut trivialement faire un système de rapport de bogue intégré directement dans les clients (en cas de plantage par exemple). Et on peut aussi profiter des notifications pubsub, par exemple pour afficher les nouveaux tickets dans le salon MUC.
j'en profite pour indiquer que je suis plus ou moins en train de faire une forge décentralisée basé sur XMPP et indépendante de l'outil de version de contrôle (utilisé avec Mercurial actuellement, mais n'importe lequel peut être intégré, Git inclus bien entendu).
Ceci a été fait en premier lieu pour nos propres besoins, mais c'est fonctionnel, et il ne manque pas grand chose pour avoir une petite forge décentralisée (principalement l'affichage du code : nous n'hébergeons et n'affichons pas le code nous même, c'est le serveur intégré à Mercurial qui le fait actuellement).
Le système est très souple, par exemple le gestionnaire de tickets peut être utilisé avec des champs libres, il peut ainsi servir à faire une liste de choses à faire (TODO), ou une liste de courses.
Le tout est basé sur le pubsub de XMPP, avec son système de permissions (on peut ainsi faire un gestionnaire de tickets privé avec une liste blanche).
Pour un serveur non, c'est clairement orienté appli bureau, mais je fais tourner tous les frontaux avec, dont le serveur web, et ça reste intéressant pour quelqu'un qui veut utiliser l'interface web ponctuellement pour une raison X ou Y (test rapide, utilisation d'une fonctionnalité non encore disponible, etc.). En plus D-Bus est intégré de base, et il est très utilisé par SàT.
On n'est pas nécessairement obligé de faire tourner le serveur web (qui est intégré au frontal web) sur un serveur dédié, sans X, et qui tourne H24. Pouvoir le lancer ponctuellement depuis son bureau est pratique.
Snappy est plus pensé pour ce type de choses (logiciels serveurs), quand j'aurai un peu de temps je regarderai également (mais Flatpak m'intéresse plus parce que décentralisé – même si Flathub est le dépôt principal – ce qui n'est pas le cas de Snappy).
Merci du retour, oui la documentation est très incomplète, c'est une des choses que je veux régler d'ici la version stable. L'installation est nettement plus simple maintenant pour backend et Cagou (frontend bureau/android) mais pas encore pour Libervia (frontend web, celui qui intéresse ici).
Je suis aussi en train de travailler sur un flatpak (déjà fonctionnel), qui permet d'installer en une commande, ça va nettement faciliter la vie des gens.
Je ne connaissais pas Movim, merci pour la recommandation. Par contre, j'ai l'impression qu'il est plus orienté "conversation" que "publication", mais je me trompe peut être. Je cherchais avant tout un outil sur lequel l'info est présentée en tant que posts, que les utilisateurs peuvent commenter.
Movim (tout comme SàT) est capable de publications, regarde par exemple https://fr.movim.eu/?blog/edhelas%40movim.eu . Je pense que c'est plutôt au niveau des partages de photos que ça va pêcher pour toi.
J'avais lu ton dernier journal sur Salut à Toi, et je m'y suis intéressé au moment de choisir mon outil. Je ne l'ai pas retenu pour deux raisons qui peuvent sembler idiotes mais qui rassurent un débutant comme moi :
ça n'est pas du tout idiot. En fait j'ai fait une grosse erreur stratégique depuis les débuts de SàT, c'est que j'ai toujours voulu attendre une version « suffisamment prête » (celle qu'on appelle « grand public » et qui sera d'ailleurs la prochaine) au lieu de fournir des choses plus progressivement pour que les gens adoptent.
Je ne recommande pas moi même à un public non technique d'utiliser pour le moment, mais j'aimerais bien que des gens commence à installer pour avoir des retours et rendre justement le logiciel accessible à tous, c'était le but de mon dernier journal (et jusqu'ici j'ai peu de retours malheureusement).
Il n'est pas encore en version 1.
Alors ça par contre la version 1 pour nous c'est quand on estimera qu'il y aura tout ce qu'on veut au niveau fonctionnalités, ça n'est pas gage de stabilité. Quand on aura toutes les XEPs principales et la visio conférence fonctionnelle, il sera question de version 1. Mais dès la prochaine version (0.7) l'installation sera recommandée pour tous
Je n'ai pas vu de grosse instance le faire tourner (comme pour Diaspora ou Humhub).
oui moi aussi j'aimerais en voir, au moins en test pendant l'été. Si quelqu'un(e) nous lit et peut nous aider sur ce coup, ça serait super.
Mais mes utilisateurs n'étant pas technophiles libristes, je ne voulais pas les dégoûter si jamais l'outil présentait des bugs.
c'est tout à fait compréhensible, c'est justement ce que j'ai voulu toujours éviter en disant « attendez avant d'installer ». Mais au final ça nous aurait aidé des installations et des retours.
Concernant les Aspects dans Diaspora, ça n'équivaut pas à des groupes :
merci des explications, je comprends mieux. Du coup c'est tout à faire possible avec XMPP. Les « aspects » de Diaspora correspondent donc aux « groupes » chez nous (qui sont dans la liste des contacts), et ce que vous appelez « groupes » correspond en termes techniques au « modèle d'accès Pubsub » chez nous, et que Movim a appelé de manière plus sympa « communautés » (je pense qu'on va reprendre le même terme sur SàT).
Bon courage pour ton développement de SàT !
Merci, et n'hésite pas à faire des retours, même pour dire pourquoi vous n'utilisez pas, ça aide à rendre l'outil utilisable par tous, ce qu'on souhaite.
merci pour ce journal détaillé, c'est très intéressant pour un développeur de projet similaire comme moi.
As-tu testé XMPP et notamment Movim ? Tu peux bloquer la communication entre serveurs (la fédération donc) si tu ne la souhaites pas comme cela semble être le cas.
Salut à Toi (que je développe) est sur ce genre de créneau, mais n'est pas encore suffisamment stable poli pour une utilisation avec un public non averti, je travaille justement à ça pour que ça soit le cas d'ici la rentrée et je serais fortement intéressé par des retours pour améliorer les choses (notamment au niveau de l'interface).
D'après les captures, Humhub semble léché, il m'a l'air chouette dans ton cas d'utilisation (où la fédération n'est pas utile voir même non désirée). Est-ce qu'il y a un tchat ? Si non, est-ce que ça vous manque ?
Tu dis que Diaspora ne permet pas de créer des groupes, mais d'après ce que je lis, ça ressemble fortement à ce qu'ils appellent « aspects », quelle différence y vois-tu ?
Comme quoi, on cherche plus à se protéger de ceux qu'on connaît et à faire confiance aveuglément aux grands réseaux sociaux à la communication opaque.
C'est une remarque intéressante, et effectivement les proches ont un intérêt direct à l'espionnage ciblé. Il y a une part de confiance à accorder de toute façon à un endroit où à l'autre.
Oui, le système de tickets est très souple, on peut mettre les champs qu'on veut dedans. Pour une liste de courses, « nom » et « quantité » par exemple, on peut même partager ça avec un ou des contact(s), comme ça dans un couple ou une colocation, on peut indiquer qu'on a déjà acheté quelque chose.
Je pense que d'ici la version stable, je vais faire un mode spécifique sur Cagou pour faire une liste de courses facilement, vu que j'en ai moi-même l'utilité.
[^] # Re: publier de façon restreinte
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 5.
En effet on a introduit ça dans SàT depuis pas mal d'années et on a développé un serveur PubSub (qui est en gros la base de donnée du blog) qui gère ça (https://repos.goffi.org/sat_pubsub). Ce qu'on a introduit c'est principalement 2 choses:
Par défaut (sans nos améliorations) il est tout de même possible de gérer des permissions pour un « nœud » pubsub (c.-à-d. pour un ensemble d'items, de billets, un peu comme un flux Atom ou RSS) à l'aide d'une liste blanche (on autorise au cas par cas qui peut lire le nœud), ce qui peut être vite fastidieux, et je ne crois pas que c'est intégré dans aucune interface de client à l'heure actuelle.
Je n'ai pas encore rédigé de spécification pour notre fonctionnalités d'une part parce qu'au début il fallait tester pour voir si c'était viable (ça l'est), et d'autre part tout simplement parce que je suis débordé. Je suis le seul développeur actif sur SàT aujourd'hui, et j'ai des tonnes de choses sur les bras (sur mon temps libre, j'ai un travail salarié à côté). La priorité c'est de stabiliser et d'avoir une version utilisable et agréable le plus rapidement possible.
[^] # Re: Définition du « rebase » / relevé de coquilles
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 9.
Je ne suis absolument pas d'accord avec ça. Le jargon rend la compréhension plus compliquée, et favorise l'exclusion. Même dans le milieu informatique que je connais pourtant bien, je suis régulièrement obligé de chercher la signification de mots ou abréviations (dont certaines peuvent en plus changer de sens selon le contexte). Alors dans l'info je suis d'accord que parfois il est plus compréhensible de garder le mot technique ou anglais (parce que utilisé dans une commande, ou parce qu'il n'y a pas de bon équivalent), mais c'est, de mon expérience, très rare.
En plus de ça, on voit de plus en plus de contresens avec des mots anglais utilisés dans une autre langue (ici le français) alors qu'il veut dire tout autre chose. Par exemple « issue » qui veut dire « problème » en anglais et qui a un tout autre sens en français. Quand on me dit « regarde cette issue » j'ai plus tendance à regarder vers la porte que mon écran d'ordinateur.
Autant je ne suis pas pour être trop à cheval sur les règles d'orthographe et de grammaire (enfin ça dépend du contexte), autant l'utilisation de jargon et/ou systématiquement de mots anglais rend la compréhension plus difficile et élitiste.
Bref utiliser le terme adapté à la langue et l'audience quand il existe, ou expliquer un terme entre parenthèses faute de mieux est une bonne pratique à mon avis.
# Permissions ? Merge-requests ? import/export ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 6.
Bravo, c'est super chouette.
Quid des formats de données et permissions ? Par exemple si sur un projet je ne veux que les étiquettes "WIP", "v1.2.3" et "DEV" ? Et si je ne veux autoriser que toto et tata à modifier l'état du bug ? Est-ce qu'on peut modifier les commentaires des autres ?
Est-ce que ça aurait du sens d'étendre pour des merge requests ? Git permet bien entendu d'utiliser une branche pour ça, l'intérêt serait de permettre de commenter le code avant de pouvoir réellement merger la branche.
Ça se rapproche de ce que fait Fossil si je ne m'abuse (je n'ai jamais utilisé moi même, mais il me semble qu'il intègre tout directement, tickets, wiki, etc.), c'est vraiment une bonne idée et la possibilité de travailler hors ligne est super (même si on n'utile pas comme système de tickets principal, ça permet de faire tampon quand on est hors ligne).
Bon je pourrais vérifier moi même mais je fais mon fainéant là :), comment ça marche pour créer un importeur/exporteur ? Ça a l'air d'être du JSON, y'a une API pour récupérer directement les opérations assemblées et le ticket final ? Je travaille sur un gestionnaire de tickets et de merge-requests décentralisé (basé sur XMPP), et ça m'intéresserait de pouvoir faire les tickets en local quand internet n'est pas dispo, et de pouvoir synchroniser après coup.
Bonne continuation, c'est très prometteur.
[^] # Re: Coccinela et Inkscape
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche WBO : un tableau blanc interactif. Évalué à 6.
Sauf erreur, les 2 étaient basés sur XMPP, et c'est toujours possible (je crois que Gajim le fait également).
C'est un des nombreux projets que j'ai dans les cartons, mais pas une grosse priorité à l'heure actuelle.
[^] # Re: Utilité de Metronome ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Prosody 0.11. Évalué à 4.
Pour pubsub ça fait des années que nous avons écris une implémentation alternative qui fonctionne avec Prosody (et qui est probablement l'implémentation pubsub libre la plus avancée à l'heure actuelle au niveau des fonctionnalités).
Après encore utile ou pas, c'est à toi de voir, c'est une implémentation alternative, et c'est maintenu (enfin après un long moment sans maintenance, ce qui n'a pas été pas super).
[^] # Re: Annuaire
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Il faudrait que Jabber/XMPP soit aussi simple à utiliser que Whatsapp. Évalué à 9.
on lit ce que j'ai écris plus haut. Ça n'est pas centralisé, ça n'est pas lié à un appareil physique facilement traçable, on peut compartimenter (plusieurs comptes sur des serveurs différents par exemple).
Que le serveur connaisse les contacts est un problème, mais c'est difficilement évitable (nécessaire pour un tas de raisons comme la lutte contre le spam ou la protection des données), et tu as toujours l'option de faire tourner ton propre serveur (ou utiliser celui de quelqu'un(e) en qui t'as vraiment confiance).
Et oui il faut faire confiance, je pense que c'est un point important, il faut savoir faire confiance à un moment où un autre. Mais la responsabilité n'est pas la même quand t'as un certain nombre d'utilisateurs, et quand t'as tous les utilisateurs.
[^] # Re: Annuaire
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Il faudrait que Jabber/XMPP soit aussi simple à utiliser que Whatsapp. Évalué à 9. Dernière modification le 19 novembre 2018 à 11:55.
Sauf que l'annuaire ce sont des numéros publiques (et on peut refuser, liste rouge), et que ça ne fait pas le lien systématique entre tous tes contacts et toi. À la base c'est papier et chacun a une copie, avec les services actuels on peut associer à un numéro que tu demandes, mais ça n'est pas tous tes numéros, et ça n'est pas systématique (c.-à-d. pas pour tous tes contacts), et accessoirement ça ne sait pas si tu gardes le numéro ou pas (si tu gardes le numéro, c'est a priori que t'as un contact plus ou moins régulier).
D'autre part, ce n'est pas parce qu'on est habitués à quelque chose que c'est bien. Le téléphone c'était historiquement en clair et facile à écouter, ça ne veut pas dire que parce qu'on a été habitué à ça, pas la peine de chiffrer les communications.
Et il faut aussi comprendre que les possibilités de stockage et surtout d'analyse des données a explosé depuis 20 ans. Une des révélations de Snowdew et que les services gouvernementaux sont capables de remonter dans le temps de plusieurs jours. Ça n'était pas une chose imaginable dans les années 70 ou 80.
Et les gens ne se rendent pas forcément compte que Whatsapp fait une carte des contacts (les permissions demandées sont très probablement survolées et acceptés sans question par la plupart des personnes. Lire les contacts pourrait être légitime, c'est envoyer au serveur qui pose problème).
Je ne suis pas sur Whatsapp, mais ils ont mon numéro associé à mon nom, comme expliqué plus haut.
[^] # Re: Ça n'est pas une bonne solution.
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Il faudrait que Jabber/XMPP soit aussi simple à utiliser que Whatsapp. Évalué à 10.
Non ça n'est pas secret, j'en ai déjà parlé sur le salon de SàT. Je pense qu'il est possible de faire de la découverte de contacts en demandant à tes contacts eux-même de te renseigner, mais en compartimentant.
Je m'explique : imagine que j'ai dans mes contacts ma sœur mais je ne connais pas le jid de ma mère. Mon client fait une demande et voit que ma sœur a autorisé tous les membres du groupe « famille » à s'échanger les contacts, elle a le jid de ma mère associé à son nom, et me renseigne donc. Elle peut également m'envoyer la liste complète des identifiants qu'elle connaît des membres de ma famille. C'est comme si je l'appelais pour demander un numéro de ma famille, mais en automatisant.
En plus de ça, chacun pourrait indiquer dans son client s'il souhaite autoriser ses contacts à échanger son identifiant, éventuellement en affinant (ex. : ma famille oui, mais pas mes collègues).
Les avantages sont nombreux:
Reste à faire en sorte que ça soit facile à utiliser. Y'a du boulot et des réflexions à avoir, mais ça n'est pas insurmontable.
[^] # Re: Ça n'est pas une bonne solution.
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Il faudrait que Jabber/XMPP soit aussi simple à utiliser que Whatsapp. Évalué à 10.
Je parle du consentement de tes contacts. Mon numéro a été envoyé plusieurs fois, en l'associant à mon nom, à WhatsApp par mes proches sans que je n'ai jamais autorisé ça (et j'y suis même opposé). En plus de ça il peuvent faire une carte des mes connaissances alors que je n'ai jamais utilisé ce service.
Il n'est absolument pas impossible de demander le consentement des personnes avant de diffuser un numéro, je ne vois pas ce qui l'empêche (évidemment ça demande un effort, mais j'appelle ça du respect de tes contacts). Alors oui tu peux n'en avoir rien à faire et afficher ça publiquement sur le net ou ailleurs, tu peux aussi le faire avec des photos nues des tes (ex) partenaires si tu pars comme ça, ceci dit je doute de la légalité de la chose (et je suis certain de l'absence d'éthique).
# Ça n'est pas une bonne solution.
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Il faudrait que Jabber/XMPP soit aussi simple à utiliser que Whatsapp. Évalué à 10.
Sans jeter la pierre à Daniel, je suis absolument opposé à ce genre de solution.
Déjà c'est, comme mentionné, centralisé, proprio et payant. De ce que j'ai compris, il faut payer pour associer son jid à un numéro, mais en plus on ne peut utiliser le service que si on est sur ce serveur. Le site affirme que l'annuaire n'est pas stocké, mais aucun moyen de vérifier ou de s'assurer de la sécurité de ce qui est envoyé. De là 2 possibilités: soit le service devient très populaire et il est en situation de monopole, soit non et la plupart des contacts ne seront pas répertoriés, du coup l'intérêt est plus que limité.
Mais mes plus gros problèmes avec ça sont :
Les gens qui choisissent d'envoyer leur numéro (en supposant qu'ils comprennent bien que c'est ce qu'il se passe), c'est une chose, mais envoyer ceux des contacts sans permission c'est inadmissible (et je ne suis même certain que ça soit légal en Europe avec le RGPD).
Bref, l'intérêt par rapport à Signal est limité (oui ça reste compatible avec le reste du réseau XMPP, mais si ça devient vraiment populaire ce service deviendrait incontournable).
Je pense qu'il y a d'autres façons de faire, plus propres et éthiques, pour la découverte des contacts, et j'ai déjà plusieurs idées en tête. Dès que j'aurai du temps (vu ma liste de choses à faire, pas tout de suite) je vais essayer de travailler un peu sur le sujet.
[^] # Re: Uniquement pour les particuliers, pas les entreprises
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal La fin de Google+. Évalué à 10.
Ils devraient renommer ça en GToutesVosDonnéesStratégiques, ça serait un meilleur nom produit, plus clair.
# Très content d'être venu
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Retour de PyconFR. Évalué à 10.
Un grand merci aussi à l'orga, je ne regrette pas d'être venu (sprint + confs), l'ambiance était excellente, on a bien avancé (merci également à ceux qui sont venu participer au sprint).
J'ai pu rencontrer l'équipe de Kivy qui est également très sympa et ce qui a permis de bien progresser sur quelques points qui me gênaient. Au passage une dépêche collaborative a été commencée, de l'aide pour l'étoffer serait bienvenue !
En plus de l'avancement côté dév, ça a été l'occasion de faire des rencontres intéressantes, des contacts, et de revoir avec plaisir certaines têtes que je connaissais. Bref, je ne regrette vraiment pas d'être venu.
J'ai eu aussi des commentaires judicieux suite à ma conf, notamment l'idée de séparer par paquets les fonctionnalités (par exemple en faisant chat et blog uniquement par défaut, puis un paquet partage de fichiers, un paquet forge logicielle, etc.). J'avais déjà l'intention de faire un système de téléchargement de greffons, mais les regrouper par thème est une très bonne idée. C'est vrai que pendant la conf (et également après mon dernier journal) je me suis rendu compte que le nombre de fonctionnalités a priori différentes perdait les gens.
[^] # Re: Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 2. Dernière modification le 08 octobre 2018 à 01:32.
Je ne comprends pas ton commentaire, tu demandes à quoi sert la décentralisation pour un album photos ?
À la même chose que pour un blog. Entre autres, t'as pas besoin de recréer un compte pour voir les photos de toto@example.net alors que t'es chez titi@invalid.fr, tu peux gérer les permissions facilement, tu peux avoir des photos et/ou commentaires à différents endroits, etc.
[^] # Re: Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 3.
C'est mentionné dans mon dernier journal : https://linuxfr.org/users/goffi/journaux/salut-a-toi-0-7-alpha-contributrices-contributeurs-a-vos-claviers
Mais il y avait probablement trop de fonctionnalités montrées d'un coup, il faudra que je filtre/découpe plus à l'avenir.
# Salut à Toi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 9.
Bon ben puisqu'on parle des alternatives je vais en profiter pour dire que c'est aussi possible avec SàT. Ça sera disponible dans la version à venir, et je pense que ton cahier des charges est à peu près respecté : libre, gestion d'accès, invitations via URL et vidéos (mais il n'y a pas de multi-encodage, donc pour du multi-plateformes il faudra un format qui passe partout, une amélioration à envisager). Plaisant et simple c'est effectivement subjectif, mais on est ouverts au suggestions/contributions et il y un moteur de thèmes puissants. En prime, XMPP oblige, c'est décentralisé/fédéré.
C'est simple et encore instable, mais c'est là.
# bon courage
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 10. Dernière modification le 02 août 2018 à 11:15.
C'est malheureusement assez courant dans le monde du logiciel libre (et pas que), et ça peut en effet être difficile à encaisser. C'est vraiment triste.
C'est vraiment super ce que vous faites : joindre développement avec production artistique. Vous êtes effectivement proche de Blender dans l'esprit, j'espère que vous allez en inspirer d'autres.
Bon courage, même s'il y a des hauts et des bas, vous allez dans le bon sens, et vous pouvez lancer un nouveau mouvement dans la création artistique et le développement de logiciels.
# article sélectionné
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quelques petits changements sur le site. Évalué à 9.
Super, merci à tous ceux qui travaillent pour maintenir ce site.
2 petites remarques pour l'article sélectionné :
pourquoi ne pas mettre un bandeau « article sélectionné par la rédaction » ? Ça rendrait les choses plus claires, et serait certainement plus compréhensible pour les personnes qui n'ont pas la mise en page CSS (lecteur braille par exemple)
on s'est demandé une fois sur notre salon si les articles étaient sélectionnés par la rédaction ou par un algorithme, tu réponds à cette question en précisant que c'est la rédaction qui sélectionne. Ce serait une information utile à mettre en petit sous l'article (ou ailleurs)
Merci :)
# Bientôt dans Vim ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 10.
C'est une fonctionnalité que j'aimerais bien avoir depuis longtemps. Suite à ton journal j'ai fait une rapide recherche, et je tombe sur ça :
https://vi.stackexchange.com/a/16856
Apparemment, depuis Vim 8.1.105 il y a une nouvelle option de compilation (
+vartabs) qui permet l'implémentation de cette fonctionnalité, à suivre donc.[^] # Re: Forge décentralisée basée sur XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Forges logicielles et hébergement de projets libres. Évalué à 6. Dernière modification le 27 juillet 2018 à 12:17.
Oui c'est l'idée à moyen terme. Mais de toute façon c'est principalement pour notre utilisation à l'heure actuelle, et du coup on (enfin je pour le moment) développe ce dont on a besoin. Après ça sera en fonction des demandes, du temps qu'on peut y consacrer, et des contributions.
À mon avis, les 2 fonctionnalités les plus importantes sont la gestion des tickets/bugs, et les requêtes de fusion (gérer ses patchs, faire la revue), et ça c'est déjà en place. Après c'est de l'amélioration petit à petit. Je pense ajouter assez vite un système de tests automatisés, et éventuellement une génération de doc.
Y'a aussi des choses très intéressantes à tout avoir sur XMPP : on peut trivialement faire un système de rapport de bogue intégré directement dans les clients (en cas de plantage par exemple). Et on peut aussi profiter des notifications pubsub, par exemple pour afficher les nouveaux tickets dans le salon MUC.
# Forge décentralisée basée sur XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Forges logicielles et hébergement de projets libres. Évalué à 10. Dernière modification le 27 juillet 2018 à 07:14.
Bonjour,
j'en profite pour indiquer que je suis plus ou moins en train de faire une forge décentralisée basé sur XMPP et indépendante de l'outil de version de contrôle (utilisé avec Mercurial actuellement, mais n'importe lequel peut être intégré, Git inclus bien entendu).
J'ai écris 2 billets à ce sujet pour expliquer et faire une courte démonstration des requêtes de fusion (merge-requests) :
- Vers une forge décentralisée basée sur XMPP
- Tickets et « merge-requests » basés sur XMPP avec SàT
Ceci a été fait en premier lieu pour nos propres besoins, mais c'est fonctionnel, et il ne manque pas grand chose pour avoir une petite forge décentralisée (principalement l'affichage du code : nous n'hébergeons et n'affichons pas le code nous même, c'est le serveur intégré à Mercurial qui le fait actuellement).
Le système est très souple, par exemple le gestionnaire de tickets peut être utilisé avec des champs libres, il peut ainsi servir à faire une liste de choses à faire (TODO), ou une liste de courses.
Le tout est basé sur le pubsub de XMPP, avec son système de permissions (on peut ainsi faire un gestionnaire de tickets privé avec une liste blanche).
[^] # Re: Merci + XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Humhub 1.2.8, retour d'expérience. Évalué à 3. Dernière modification le 23 juillet 2018 à 08:34.
Pour un serveur non, c'est clairement orienté appli bureau, mais je fais tourner tous les frontaux avec, dont le serveur web, et ça reste intéressant pour quelqu'un qui veut utiliser l'interface web ponctuellement pour une raison X ou Y (test rapide, utilisation d'une fonctionnalité non encore disponible, etc.). En plus D-Bus est intégré de base, et il est très utilisé par SàT.
On n'est pas nécessairement obligé de faire tourner le serveur web (qui est intégré au frontal web) sur un serveur dédié, sans X, et qui tourne H24. Pouvoir le lancer ponctuellement depuis son bureau est pratique.
Snappy est plus pensé pour ce type de choses (logiciels serveurs), quand j'aurai un peu de temps je regarderai également (mais Flatpak m'intéresse plus parce que décentralisé – même si Flathub est le dépôt principal – ce qui n'est pas le cas de Snappy).
[^] # Re: Merci + XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Humhub 1.2.8, retour d'expérience. Évalué à 5.
Merci du retour, oui la documentation est très incomplète, c'est une des choses que je veux régler d'ici la version stable. L'installation est nettement plus simple maintenant pour backend et Cagou (frontend bureau/android) mais pas encore pour Libervia (frontend web, celui qui intéresse ici).
Je suis aussi en train de travailler sur un flatpak (déjà fonctionnel), qui permet d'installer en une commande, ça va nettement faciliter la vie des gens.
[^] # Re: Merci + XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Humhub 1.2.8, retour d'expérience. Évalué à 9. Dernière modification le 22 juillet 2018 à 18:38.
Movim (tout comme SàT) est capable de publications, regarde par exemple https://fr.movim.eu/?blog/edhelas%40movim.eu . Je pense que c'est plutôt au niveau des partages de photos que ça va pêcher pour toi.
ça n'est pas du tout idiot. En fait j'ai fait une grosse erreur stratégique depuis les débuts de SàT, c'est que j'ai toujours voulu attendre une version « suffisamment prête » (celle qu'on appelle « grand public » et qui sera d'ailleurs la prochaine) au lieu de fournir des choses plus progressivement pour que les gens adoptent.
Je ne recommande pas moi même à un public non technique d'utiliser pour le moment, mais j'aimerais bien que des gens commence à installer pour avoir des retours et rendre justement le logiciel accessible à tous, c'était le but de mon dernier journal (et jusqu'ici j'ai peu de retours malheureusement).
Alors ça par contre la version 1 pour nous c'est quand on estimera qu'il y aura tout ce qu'on veut au niveau fonctionnalités, ça n'est pas gage de stabilité. Quand on aura toutes les XEPs principales et la visio conférence fonctionnelle, il sera question de version 1. Mais dès la prochaine version (0.7) l'installation sera recommandée pour tous
oui moi aussi j'aimerais en voir, au moins en test pendant l'été. Si quelqu'un(e) nous lit et peut nous aider sur ce coup, ça serait super.
c'est tout à fait compréhensible, c'est justement ce que j'ai voulu toujours éviter en disant « attendez avant d'installer ». Mais au final ça nous aurait aidé des installations et des retours.
merci des explications, je comprends mieux. Du coup c'est tout à faire possible avec XMPP. Les « aspects » de Diaspora correspondent donc aux « groupes » chez nous (qui sont dans la liste des contacts), et ce que vous appelez « groupes » correspond en termes techniques au « modèle d'accès Pubsub » chez nous, et que Movim a appelé de manière plus sympa « communautés » (je pense qu'on va reprendre le même terme sur SàT).
Merci, et n'hésite pas à faire des retours, même pour dire pourquoi vous n'utilisez pas, ça aide à rendre l'outil utilisable par tous, ce qu'on souhaite.
# Merci + XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Humhub 1.2.8, retour d'expérience. Évalué à 5.
Salut,
merci pour ce journal détaillé, c'est très intéressant pour un développeur de projet similaire comme moi.
As-tu testé XMPP et notamment Movim ? Tu peux bloquer la communication entre serveurs (la fédération donc) si tu ne la souhaites pas comme cela semble être le cas.
Salut à Toi (que je développe) est sur ce genre de créneau, mais n'est pas encore suffisamment stable poli pour une utilisation avec un public non averti, je travaille justement à ça pour que ça soit le cas d'ici la rentrée et je serais fortement intéressé par des retours pour améliorer les choses (notamment au niveau de l'interface).
D'après les captures, Humhub semble léché, il m'a l'air chouette dans ton cas d'utilisation (où la fédération n'est pas utile voir même non désirée). Est-ce qu'il y a un tchat ? Si non, est-ce que ça vous manque ?
Tu dis que Diaspora ne permet pas de créer des groupes, mais d'après ce que je lis, ça ressemble fortement à ce qu'ils appellent « aspects », quelle différence y vois-tu ?
C'est une remarque intéressante, et effectivement les proches ont un intérêt direct à l'espionnage ciblé. Il y a une part de confiance à accorder de toute façon à un endroit où à l'autre.
[^] # Re: Liste de courses / post-it
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 6.
Oui, le système de tickets est très souple, on peut mettre les champs qu'on veut dedans. Pour une liste de courses, « nom » et « quantité » par exemple, on peut même partager ça avec un ou des contact(s), comme ça dans un couple ou une colocation, on peut indiquer qu'on a déjà acheté quelque chose.
Je pense que d'ici la version stable, je vais faire un mode spécifique sur Cagou pour faire une liste de courses facilement, vu que j'en ai moi-même l'utilité.