Nous sommes sur Liberapay depuis pratiquement le début, mais suite à leurs problèmes avec MangoPay nous n'avons plus d'opérateur de paiement parce que les 2 options proposées ne nous conviennent pas pour diverses raisons, donc le compte n'est actuellement pas utilisable.
Est-ce que vous pourriez détailler ces raisons ? Ça nous serait utile car nous sommes en train de reprendre notre financement via cette plateforme.
Pour Paypal c'est avant tout des raisons politiques : entre autres ils se sont plusieurs fois illustrés par des fermetures et/ou blocages de comptes arbitraires.
Stripe je ne connais pas, mais dans les 2 cas le siège social est aux États-Unis. Or notre contrat social précise que nous ne faisons aucune discrimination y compris pour une zone géographique. Autrement dit nous sommes ouverts à l'utilisation du projet y compris par des gens dans les pays sur la "liste noire" des États-Unis. Donc si demain nous avons des utilisateurs et/ou soutiens en Iran ou à Cuba, on ne veut pas risquer l'ingérence.
Évidemment tout n'est pas rose non plus ailleurs, mais au moins en gardant les acteurs dans l'Union européenne, on limite les risques juridiques et on pourra plus facilement se défendre en cas de problème.
Salut, et merci pour cette initiative. Je pourrais être intéressé, mais le projet (https://salut-a-toi.org) bien qu'il rentre dans plusieurs thèmes est nettement moins connu, visible et utilisé que ceux cités. Est-ce qu'il y a des contreparties à votre proposition (comme ajouter un logo, ce qui serait incompatible avec notre contrat social) ?
Mon point de vue sur vos questions:
faut-il privilégier le versement d'une grosse somme en une seule fois ou privilégier une dilution sur le long terme ? Nous prévoyons aussi de distribuer des fonds via Liberapay.
C'est à voir au cas par cas avec les projets. Nous sommes sur Liberapay depuis pratiquement le début, mais suite à leurs problèmes avec MangoPay nous n'avons plus d'opérateur de paiement parce que les 2 options proposées ne nous conviennent pas pour diverses raisons, donc le compte n'est actuellement pas utilisable. Aussi cela dépend de comment le projet veut utiliser la somme : payer ou participer au paiement de contributeurs, servir aux déplacements ou à se faire connaître, etc.
comment s'assurer que les fonds versés financeront du Libre qui le restera ? Faut-il exiger un partage du copyright pour éviter un changement unilatéral de la part du mainteneur vers une licence propriétaire a posteriori ?
Est-ce que vous excluez tout ce qui n'est pas copyleft ?
J'étais partisan à un moment de « diluer » au maximum les contributions pour éviter un changement de licence, et j'en reviens maintenant. D'une part, si le projet reste sur peu de contributeurs⋅trices majeur⋅e⋅s, ils ou elles ont toujours la possibilité de supprimer le code extérieur et éventuellement le réécrire s'ils veulent changer de licence, et d'autre part un changement de licence peut être nécessaire sans pour autant fermer le code.
Par exemple, nous nous posons actuellement la question de la licence pour un éventuel client iOS (l'AGPL n'étant pas compatible avec l'Apple store), et il semble que Google va imposer une bibliothèque non libre pour les notifications push sur Android (ce qui peut poser problème selon la licence). Nous avons aussi un framework web qui n'était pas forcément prévu à l'origine et qui peut demander un changement de licence. Bref on peut vouloir rester dans du libre mais devoir changer la licence.
comment inciter plus d'entreprises à reverser une partie de leur chiffre d'affaire ?
Il y a clairement un problème de financement et je ne suis pas sûr que le salut vienne des entreprises, mais c'est en tout cas une très bonne chose de faire ce que vous faites, et communiquer dessus est déjà une bonne façon d'inciter d'autres à suivre.
ActivityPub ou plutôt XMPP, qui a d'ailleurs déjà été utilisé par Google, Facebook, Microsoft et même Apple pour son système de notification (je me demande s'il n'est pas encore utilisé dans ce cas d'ailleurs), et ils ont tous fini par changer (sans vouloir trop m'avancer sur le sujet, il y a probablement diverses raisons comme un public qui n'a pas suivi, et le modèle économique qui se base sur qui a la plus grosse).
Article sympa (je ne suis plus joueur depuis des années, mais c'était sympa à lire).
Tu cites Unity, du coup j'en profite pour placer l'excellent Godot engine, il font un super boulot, c'est libre, multi-plateformes, et c'est un vrai moteur 2D + un moteur 3D. Un des fleurons actuels du libre à mon avis.
Et pour ceux qui ne connaissent pas, il y a jump'n'bump qui me rappelle un peu mes études :)
Pareil, je m'en suis déjà servi pour plusieurs vidéos et même pour une démo live dans une conférence à la Pycon fr l'année dernière, donc merci pour le boulot et ce logiciel fort utile.
C'est juste pour un coup d'œil de quelques minutes comme tu l'as fait dans ton commentaire, et si t'as le temps (crois moi je sais ce que c'est de manquer de temps). Je note, merci :)
Ne le prends pas mal, j'ai bouffé de la PAO et de la mise en page web qq années.
Pourquoi veux tu que je le prenne mal ? D'une c'est moi qui l'ai demandé, et de deux ça m'aide :). Merci pour les commentaires, ceux sur l'alignement sont particulièrement pertinents.
Si t'as des notions de mise en page, ça serait très utile d'avoir des retours de temps en temps sur l'évolution de l'interface, si jamais t'as envie de passer sur notre salon XMPP (sat@chat.jabberfr.org [lien web]) ou un contact.
Le cadre a en fait une utilité, mais ça aussi ça n'est pas visible sur une simple capture: on peut diviser l'interface pour afficher plusieurs choses en même temps (plusieurs conversations par exemple).
La première ligne se comprend à l'usage, elle affiche les messages importants quand la fenêtre de chat correspondante n'est pas visible, en défilant à la manière d'une chaîne d'information. J'ai montré ça à quelques personnes au FOSDEM, et ça plaisait.
l'icône sur la deuxième ligne permet de changer de « mode » (chat, partage de fichier, télécommande, etc.). Là aussi c'est particulier et à voir à l'usage, sur une capture c'est difficile de se faire une idée. C'est inspiré de Blender pour ceux qui connaissent.
ce n'est pas ta propre adresse mais cette de ton correspondant qui est affichée. C'est temporaire, ça sera plus probablement le nom qui sera affiché à terme. Le verrou n'est pas qu'un indicateur mais permet aussi de changer le type de chiffrement, ça peut être intéressant de le déplacer, je vais y réfléchir.
oui pour les métadonnée c'était prévu de travailler dessus, notamment il y a une XEP qui propose un système de couleurs consistant pour les pseudos (pour retrouver les mêmes couleurs sur les différents clients). Je ferai sûrement ça pour la prochaine version, parce qu'il y a un peu boulot et là je veux sortir cette version dès que possible.
oui pour les espaces (padding) ça fait partie des améliorations déjà faites depuis la capture, enfin peut-être pas à côté de l'avatar, je vais faire des essais.
ce n'est pas une icône d'envoi de message, mais d'ajout de données spéciales (image/vidéo, enregistrement sonore, et probablement bientôt coordonnées GPS ou autre). Dans la version actuelle elle est plus petite. Mais du coup le + cerclé n'est pas assez explicite ? C'est pourtant utilisé dans d'autres clients…
Voilà de mon côté, en espérant que ça puisse être un peu utile
Oui c'est utile, merci. J'essaye de plus en plus de demander ce genre d'avis pour améliorer l'interface, et ça aide.
Alors ça par exemple, j'avais commencé l'interface en fond noir, on m'a conseillé de partir en fond blanc ce que j'ai fait, mais je lis des articles qui parlent d'un retour au noir (ex.: https://www.lord.re/ideas/005-black-header/), bref ça n'a pas l'air si évident.
Perso je trouve que le blanc donne plus une impression d'interface aérée mais que le noir est plus reposant, je pense faire une option à terme pour passer de l'un à l'autre, avec certainement un fond blanc par défaut.
Le peu de couleurs oui, les grands contrastes, etc. Ce sont des effectivement des bonnes pratiques.
Ça c'est une capture un peu ancienne (elle a été légèrement améliorée depuis) de notre interface bureau/mobile en cours de dév, ça me semble coller aux critères que tu donnes, tu (vous) en pense(z) quoi ?
Le menu en haut n'est visible que sur bureau, mais je pense qu'il va disparaître d'ici la sortie de la 0.7.
Qu'entends tu précisément par « moderne » ? Ce n'est pas une question piège, je me demande vraiment parce que ce terme est à la mode et utilisé à toutes les sauces, aussi j'aimerais bien avoir une liste plus ou moins précises des choses que vous aimez dans l'interface, dans l'idée d'améliorer notre frontal graphique (cette question ne s'adresse pas qu'à Zatalyz d'ailleurs).
Un vrai bon journaliste, ça recoupe les informations, ça va sur le terrain, et ça a une base de contacts fiables.
Un des problèmes principaux, c'est que les difficultés financières entraînent une augmentation des cadences, et les journalistes font de plus en plus de choses dans l'urgence, et en multipliant les rôles (papier + photo + correction par exemple, là où avant il y avait 3 personnes différentes), ça laisse moins de temps pour faire correctement la vérification.
En plus de ça il y a l'expérience qui devrait aider à démêler le vrai du faux.
Si tu n'es plus capable de garantir que ce que tu vois est la réalité, comment les gens peuvent faire confiance à une information plutôt qu'à une autre
C'est entre autres à ça que servent les journalistes. C'est un milieu en grande difficulté, et il y a des choses à reprocher à nombre de médias, mais ça reste un métier essentiel, et un de leur rôle principal est de vérifier les informations (ce qui est peu compatible avec l'actuelle culture de l'urgence).
oui si l'admin le permet, c'est le cas sur jabberfr.org, comme mentionné par ailleurs. C'est une excellente pratique (autoriser un nom de domaine externe) qui devrait se généraliser (on ne le fait pas encore sur notre serveur de démo, mais j'aimerais mettre ça en place à terme).
la plus simple, avoir son propre nom de domaine, et le changer quand on change de serveur. Ça suppose qu'on puisse récupérer ses archives sur le premier serveur pour réinstaller sur le second.
le 2) peut poser des problèmes de sécurité (voir par exemple https://xmpp.org/extensions/xep-0283.html#security). Si on veut que ça soit confortable, il faudrait aussi transférer les archives (historique des messages par exemple).
Bref, il y a des débuts de solutions, mais ça peut être dangereux de trop automatiser. Il y a certainement des choses à creuser avec les nouvelles méthodes de chiffrement de bout en bout (OMEMO et OX).
Un truc aussi que je trouve très cool avec XMPP, c'est que le couple identifiant/mot de passe permet de se connecter sur tout l'écosystème. Concrètement, j'ai depuis quelques années mon identifiant en movim.eu, mais avec ça je peux me connecter au webchat de conversejs.org, à l'instance movim hébergée par jabberfr.org, ou sur le site movim.eu aussi. Et sur chaque service, je retrouve mes contacts, mon historique, etc. Et le jour où j'ai envie de tester SàT ou un énième client, pas besoin de refaire un compte.
Oui enfin attention avec ça, il faut bien comprendre qu'on file identifiant et mot de passe au service tiers. C'est valable pour un compte de test, si on héberge tout soit même, ou si on fait très confiance au service tiers, mais ça reste une mauvaise pratique.
La méthode propre pour pouvoir sauter d'un service à l'autre facilement, c'est d'utiliser une authentification de type OAuth, ce qu'il est possible de faire avec XMPP, mais très peu implémenté aujourd'hui. En gros le principe c'est que si t'as un compte sur jabberfr.org et tu veux tester sur conversejs.org, tu entres ton identifiant (jid), et sur jabberfr.org t'as une confirmation (« conversejs.org veut accéder à votre service bla bla »), et tu peux te connecter sans entrer ton mot de passe.
C'est une des choses que j'aimerais pousser dans XMPP, mais on a déjà trop de choses à faire.
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.
[^] # Re: Comment assurer un mécénat de qualité ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Appel à projet libre pour la campagne de mécénat 2019 de Code Lutin. Évalué à 4.
Pour Paypal c'est avant tout des raisons politiques : entre autres ils se sont plusieurs fois illustrés par des fermetures et/ou blocages de comptes arbitraires.
Stripe je ne connais pas, mais dans les 2 cas le siège social est aux États-Unis. Or notre contrat social précise que nous ne faisons aucune discrimination y compris pour une zone géographique. Autrement dit nous sommes ouverts à l'utilisation du projet y compris par des gens dans les pays sur la "liste noire" des États-Unis. Donc si demain nous avons des utilisateurs et/ou soutiens en Iran ou à Cuba, on ne veut pas risquer l'ingérence.
Évidemment tout n'est pas rose non plus ailleurs, mais au moins en gardant les acteurs dans l'Union européenne, on limite les risques juridiques et on pourra plus facilement se défendre en cas de problème.
[^] # Re: Comment assurer un mécénat de qualité ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Appel à projet libre pour la campagne de mécénat 2019 de Code Lutin. Évalué à 6.
Salut, et merci pour cette initiative. Je pourrais être intéressé, mais le projet (https://salut-a-toi.org) bien qu'il rentre dans plusieurs thèmes est nettement moins connu, visible et utilisé que ceux cités. Est-ce qu'il y a des contreparties à votre proposition (comme ajouter un logo, ce qui serait incompatible avec notre contrat social) ?
Mon point de vue sur vos questions:
C'est à voir au cas par cas avec les projets. Nous sommes sur Liberapay depuis pratiquement le début, mais suite à leurs problèmes avec MangoPay nous n'avons plus d'opérateur de paiement parce que les 2 options proposées ne nous conviennent pas pour diverses raisons, donc le compte n'est actuellement pas utilisable. Aussi cela dépend de comment le projet veut utiliser la somme : payer ou participer au paiement de contributeurs, servir aux déplacements ou à se faire connaître, etc.
Est-ce que vous excluez tout ce qui n'est pas copyleft ?
J'étais partisan à un moment de « diluer » au maximum les contributions pour éviter un changement de licence, et j'en reviens maintenant. D'une part, si le projet reste sur peu de contributeurs⋅trices majeur⋅e⋅s, ils ou elles ont toujours la possibilité de supprimer le code extérieur et éventuellement le réécrire s'ils veulent changer de licence, et d'autre part un changement de licence peut être nécessaire sans pour autant fermer le code.
Par exemple, nous nous posons actuellement la question de la licence pour un éventuel client iOS (l'AGPL n'étant pas compatible avec l'Apple store), et il semble que Google va imposer une bibliothèque non libre pour les notifications push sur Android (ce qui peut poser problème selon la licence). Nous avons aussi un framework web qui n'était pas forcément prévu à l'origine et qui peut demander un changement de licence. Bref on peut vouloir rester dans du libre mais devoir changer la licence.
Il y a clairement un problème de financement et je ne suis pas sûr que le salut vienne des entreprises, mais c'est en tout cas une très bonne chose de faire ce que vous faites, et communiquer dessus est déjà une bonne façon d'inciter d'autres à suivre.
# XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Appel de plusieurs organisations à imposer un minimum d’interopérabilité pour les GAFA. Évalué à 6. Dernière modification le 23 mai 2019 à 09:06.
ActivityPub ou plutôt XMPP, qui a d'ailleurs déjà été utilisé par Google, Facebook, Microsoft et même Apple pour son système de notification (je me demande s'il n'est pas encore utilisé dans ce cas d'ailleurs), et ils ont tous fini par changer (sans vouloir trop m'avancer sur le sujet, il y a probablement diverses raisons comme un public qui n'a pas suivi, et le modèle économique qui se base sur qui a la plus grosse).
[^] # Re: Godot
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Une vision de l'état du jeux vidéo sur Linux. Évalué à 2.
oui, c'était vraiment génial :)
# Godot
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Une vision de l'état du jeux vidéo sur Linux. Évalué à 8.
Article sympa (je ne suis plus joueur depuis des années, mais c'était sympa à lire).
Tu cites Unity, du coup j'en profite pour placer l'excellent Godot engine, il font un super boulot, c'est libre, multi-plateformes, et c'est un vrai moteur 2D + un moteur 3D. Un des fleurons actuels du libre à mon avis.
Et pour ceux qui ne connaissent pas, il y a jump'n'bump qui me rappelle un peu mes études :)
[^] # Re: Se passer de Google ... quand une alternative équivalente existe
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Se passer de Google, Facebook et autres Big Brothers 2.0 #2 — Le courriel. Évalué à 2.
j'ai un ancien collègue qui travaille sur un client de ce style (Mailur), je n'ai pas essayé moi même mais ça a l'air chouette:
[^] # Re: Questions bêtes
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quel type de messagerie ouverte et interopérable j’utilise le plus ?. Évalué à 4. Dernière modification le 01 avril 2019 à 20:51.
Il me semble que faire l'aumône aux projets permettrait plutôt de les chasser les
insectesbugs.[^] # Re: Remerciements
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal scrcpy a 1 an. Évalué à 5.
Pareil, je m'en suis déjà servi pour plusieurs vidéos et même pour une démo live dans une conférence à la Pycon fr l'année dernière, donc merci pour le boulot et ce logiciel fort utile.
[^] # Re: Et?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Dino, le client XMPP, est disponible sur plusieurs distributions GNU/Linux. Évalué à 4.
C'est juste pour un coup d'œil de quelques minutes comme tu l'as fait dans ton commentaire, et si t'as le temps (crois moi je sais ce que c'est de manquer de temps). Je note, merci :)
[^] # Re: Et?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Dino, le client XMPP, est disponible sur plusieurs distributions GNU/Linux. Évalué à 8.
Pourquoi veux tu que je le prenne mal ? D'une c'est moi qui l'ai demandé, et de deux ça m'aide :). Merci pour les commentaires, ceux sur l'alignement sont particulièrement pertinents.
Si t'as des notions de mise en page, ça serait très utile d'avoir des retours de temps en temps sur l'évolution de l'interface, si jamais t'as envie de passer sur notre salon XMPP (sat@chat.jabberfr.org [lien web]) ou un contact.
Le cadre a en fait une utilité, mais ça aussi ça n'est pas visible sur une simple capture: on peut diviser l'interface pour afficher plusieurs choses en même temps (plusieurs conversations par exemple).
[^] # Re: Et?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Dino, le client XMPP, est disponible sur plusieurs distributions GNU/Linux. Évalué à 5.
Merci pour ces commentaires.
La première ligne se comprend à l'usage, elle affiche les messages importants quand la fenêtre de chat correspondante n'est pas visible, en défilant à la manière d'une chaîne d'information. J'ai montré ça à quelques personnes au FOSDEM, et ça plaisait.
l'icône sur la deuxième ligne permet de changer de « mode » (chat, partage de fichier, télécommande, etc.). Là aussi c'est particulier et à voir à l'usage, sur une capture c'est difficile de se faire une idée. C'est inspiré de Blender pour ceux qui connaissent.
ce n'est pas ta propre adresse mais cette de ton correspondant qui est affichée. C'est temporaire, ça sera plus probablement le nom qui sera affiché à terme. Le verrou n'est pas qu'un indicateur mais permet aussi de changer le type de chiffrement, ça peut être intéressant de le déplacer, je vais y réfléchir.
oui pour les métadonnée c'était prévu de travailler dessus, notamment il y a une XEP qui propose un système de couleurs consistant pour les pseudos (pour retrouver les mêmes couleurs sur les différents clients). Je ferai sûrement ça pour la prochaine version, parce qu'il y a un peu boulot et là je veux sortir cette version dès que possible.
oui pour les espaces (padding) ça fait partie des améliorations déjà faites depuis la capture, enfin peut-être pas à côté de l'avatar, je vais faire des essais.
ce n'est pas une icône d'envoi de message, mais d'ajout de données spéciales (image/vidéo, enregistrement sonore, et probablement bientôt coordonnées GPS ou autre). Dans la version actuelle elle est plus petite. Mais du coup le
+cerclé n'est pas assez explicite ? C'est pourtant utilisé dans d'autres clients…Oui c'est utile, merci. J'essaye de plus en plus de demander ce genre d'avis pour améliorer l'interface, et ça aide.
[^] # Re: Et?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Dino, le client XMPP, est disponible sur plusieurs distributions GNU/Linux. Évalué à 5.
Alors ça par exemple, j'avais commencé l'interface en fond noir, on m'a conseillé de partir en fond blanc ce que j'ai fait, mais je lis des articles qui parlent d'un retour au noir (ex.: https://www.lord.re/ideas/005-black-header/), bref ça n'a pas l'air si évident.
Perso je trouve que le blanc donne plus une impression d'interface aérée mais que le noir est plus reposant, je pense faire une option à terme pour passer de l'un à l'autre, avec certainement un fond blanc par défaut.
Le peu de couleurs oui, les grands contrastes, etc. Ce sont des effectivement des bonnes pratiques.
Ça c'est une capture un peu ancienne (elle a été légèrement améliorée depuis) de notre interface bureau/mobile en cours de dév, ça me semble coller aux critères que tu donnes, tu (vous) en pense(z) quoi ?
Le menu en haut n'est visible que sur bureau, mais je pense qu'il va disparaître d'ici la sortie de la 0.7.
[^] # Re: Et?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Dino, le client XMPP, est disponible sur plusieurs distributions GNU/Linux. Évalué à 3.
Qu'entends tu précisément par « moderne » ? Ce n'est pas une question piège, je me demande vraiment parce que ce terme est à la mode et utilisé à toutes les sauces, aussi j'aimerais bien avoir une liste plus ou moins précises des choses que vous aimez dans l'interface, dans l'idée d'améliorer notre frontal graphique (cette question ne s'adresse pas qu'à Zatalyz d'ailleurs).
[^] # Re: Comment "démasquer" un faux visage
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Cette personne n'existe pas. Évalué à 8.
Un vrai bon journaliste, ça recoupe les informations, ça va sur le terrain, et ça a une base de contacts fiables.
Un des problèmes principaux, c'est que les difficultés financières entraînent une augmentation des cadences, et les journalistes font de plus en plus de choses dans l'urgence, et en multipliant les rôles (papier + photo + correction par exemple, là où avant il y avait 3 personnes différentes), ça laisse moins de temps pour faire correctement la vérification.
En plus de ça il y a l'expérience qui devrait aider à démêler le vrai du faux.
[^] # Re: Comment "démasquer" un faux visage
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Cette personne n'existe pas. Évalué à 10.
C'est entre autres à ça que servent les journalistes. C'est un milieu en grande difficulté, et il y a des choses à reprocher à nombre de médias, mais ça reste un métier essentiel, et un de leur rôle principal est de vérifier les informations (ce qui est peu compatible avec l'actuelle culture de l'urgence).
[^] # Re: exporter un compte
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 4.
Oui c'est bien ça.
[^] # Re: exporter un compte
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 2.
oui si l'admin le permet, c'est le cas sur jabberfr.org, comme mentionné par ailleurs. C'est une excellente pratique (autoriser un nom de domaine externe) qui devrait se généraliser (on ne le fait pas encore sur notre serveur de démo, mais j'aimerais mettre ça en place à terme).
[^] # Re: exporter un compte
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 2.
Les 2 méthodes possibles aujourd'hui:
le 2) peut poser des problèmes de sécurité (voir par exemple https://xmpp.org/extensions/xep-0283.html#security). Si on veut que ça soit confortable, il faudrait aussi transférer les archives (historique des messages par exemple).
Bref, il y a des débuts de solutions, mais ça peut être dangereux de trop automatiser. Il y a certainement des choses à creuser avec les nouvelles méthodes de chiffrement de bout en bout (OMEMO et OX).
[^] # Re: exporter un compte
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.14 « Scotty ». Évalué à 5.
Oui enfin attention avec ça, il faut bien comprendre qu'on file identifiant et mot de passe au service tiers. C'est valable pour un compte de test, si on héberge tout soit même, ou si on fait très confiance au service tiers, mais ça reste une mauvaise pratique.
La méthode propre pour pouvoir sauter d'un service à l'autre facilement, c'est d'utiliser une authentification de type OAuth, ce qu'il est possible de faire avec XMPP, mais très peu implémenté aujourd'hui. En gros le principe c'est que si t'as un compte sur jabberfr.org et tu veux tester sur conversejs.org, tu entres ton identifiant (jid), et sur jabberfr.org t'as une confirmation (« conversejs.org veut accéder à votre service bla bla »), et tu peux te connecter sans entrer ton mot de passe.
C'est une des choses que j'aimerais pousser dans XMPP, mais on a déjà trop de choses à faire.
[^] # 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.