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é.
Le partage de fichier est prévu depuis pratiquement le début de SàT, avant même qu'on entende parler de Own/Next Cloud, et oui ça va se recouper sur les fonctionnalités. SàT chercher à fournir une fonction complète clef en main, même le serveur HTTP est inclus.
Mais il faut aussi relativiser, Owncloud et Nextcloud se concentrent principalement (même s'ils vont voir à côté aussi comme tu l'as souligné) sur le partage de fichier, et sont développés avec des développeurs à plein temps depuis des années, on est loin d'arriver à quelque chose d'aussi complet.
D'autre part, on ne veut pas entrer dans une logique de concurrence, s'il y a possibilité de faciliter la communication entre ces différents logiciels, on fera ce qu'il faut pour.
Si l'échange de fichiers est anodin,
l'envoi direct est courant oui (encore que c'est passé de mode en faveur du tout sur un serveur), mais le partage automatique de dossiers, je ne connais que KDEConnect qui le fait (si on exclue les solutions plus complexes comme NFS ou Samba), et SàT ne se limite pas au réseau local.
ah mais je n'avais pas regardé ta commande, tu fais ça sur ta machine directement, donc tu utilises les modules systèmes qui peuvent être trop vieux en effet.
Pour l'apparence il y a un système de thèmes qui permet de faire vraiment ce qu'on veut (basé sur jinja2). Le CSS est fait à la main pour le moment, et je suis en train de petit à petit utiliser les conventions BEM partout. Il est possible d'intégrer une moulinette de type LESS ou Sass mais je n'en ai pas eu l'utilité jusqu'ici et je trouvais que ça compliquait le tout. Mais si quelqu'un souhaite contribuer à un thème et utiliser un des ces outils, je regarderai pour l'intégration ça n'est pas un problème.
Quant à un framework tout fait, j'ai regardé du côté de Bulma que j'aimais bien, mais on se retrouve avec une dépendance en plus, et maintenant que flex est géré partout, et que c'est pratiquement le cas pour grid aussi, je pense que l'intérêt des frameworks CSS est devenu très limité, et qu'on peut facilement faire sans.
Bref très facile d'ajouter des thèmes ou de changer l'apparence actuelle, et les merge-requests sont les bienvenues ;)
j'ai corrigé le problème, Mercurial met le type binary par défaut (je suppose pour éviter les exécutions de scripts), il y avait une option à spécifier (guessmime=True) et le type MIME est maintenant correct, mais les images n'apparaissent toujours pas ici, il n'y aurait pas un cache à vider ?
édition: ah bah c'est bon maintenant, c'est réglé. Merci encore Xavier !
[^] # 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é.
[^] # Re: Concurrence avec Nextcloud/Owncloud?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 5.
Le partage de fichier est prévu depuis pratiquement le début de SàT, avant même qu'on entende parler de Own/Next Cloud, et oui ça va se recouper sur les fonctionnalités. SàT chercher à fournir une fonction complète clef en main, même le serveur HTTP est inclus.
Mais il faut aussi relativiser, Owncloud et Nextcloud se concentrent principalement (même s'ils vont voir à côté aussi comme tu l'as souligné) sur le partage de fichier, et sont développés avec des développeurs à plein temps depuis des années, on est loin d'arriver à quelque chose d'aussi complet.
D'autre part, on ne veut pas entrer dans une logique de concurrence, s'il y a possibilité de faciliter la communication entre ces différents logiciels, on fera ce qu'il faut pour.
l'envoi direct est courant oui (encore que c'est passé de mode en faveur du tout sur un serveur), mais le partage automatique de dossiers, je ne connais que KDEConnect qui le fait (si on exclue les solutions plus complexes comme NFS ou Samba), et SàT ne se limite pas au réseau local.
[^] # Re: CSS ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 4.
ah mais je n'avais pas regardé ta commande, tu fais ça sur ta machine directement, donc tu utilises les modules systèmes qui peuvent être trop vieux en effet.
Tu devrais utiliser un environnement virtuel, les instructions sont là : https://wiki.goffi.org/wiki/Salut_%C3%A0_Toi/en
[^] # Re: CSS ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 3. Dernière modification le 06 juillet 2018 à 07:51.
ah, je vais regarder ça.
Pour l'apparence il y a un système de thèmes qui permet de faire vraiment ce qu'on veut (basé sur jinja2). Le CSS est fait à la main pour le moment, et je suis en train de petit à petit utiliser les conventions BEM partout. Il est possible d'intégrer une moulinette de type LESS ou Sass mais je n'en ai pas eu l'utilité jusqu'ici et je trouvais que ça compliquait le tout. Mais si quelqu'un souhaite contribuer à un thème et utiliser un des ces outils, je regarderai pour l'intégration ça n'est pas un problème.
Quant à un framework tout fait, j'ai regardé du côté de Bulma que j'aimais bien, mais on se retrouve avec une dépendance en plus, et maintenant que flex est géré partout, et que c'est pratiquement le cas pour grid aussi, je pense que l'intérêt des frameworks CSS est devenu très limité, et qu'on peut facilement faire sans.
Bref très facile d'ajouter des thèmes ou de changer l'apparence actuelle, et les merge-requests sont les bienvenues ;)
[^] # Re: problème avec les captures
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 3. Dernière modification le 05 juillet 2018 à 18:25.
j'ai corrigé le problème, Mercurial met le type binary par défaut (je suppose pour éviter les exécutions de scripts), il y avait une option à spécifier (guessmime=True) et le type MIME est maintenant correct, mais les images n'apparaissent toujours pas ici, il n'y aurait pas un cache à vider ?
édition: ah bah c'est bon maintenant, c'est réglé. Merci encore Xavier !
[^] # Re: problème avec les captures
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 2.
arf, c'est fort probable bien vu. Ça viendrait de Mercurial, je vais voir si je peux rattraper le coup avec Apache, merci.
# problème avec les captures
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi 0.7 alpha, contributrices, contributeurs, à vos claviers !. Évalué à 3.
Les images n'apparaissent pas correctement, est-ce qu'un modérateur/admin peut regarder pourquoi ? Merci
En attendant, une version avec les images affichées normalement est disponible sur mon blog.