Click to reduce…

Avec la récente annonce concernant le changement de propriétaire de la plus grosse forge centralisée connue, on a vu resurgir ici et là des questionnements sur la création d'un outil similaire mais décentralisé.

J'ai profité de l'occasion pour rappeler le travail effectué pour implémenter tickets et requêtes de fusion (« merge requests ») dans Salut à Toi (SàT), travail qui était passé relativement inaperçu quand j'ai écrit à ce sujet, il y a 6 mois.

Désormais je souhaite apporter quelques précisions sur le pourquoi de ces outils.

Tout d'abord pourquoi pas la grosse forge ? Après tout une importante partie des logiciels libres actuels l'utilise déjà !
D'une part parce que ce n'est pas libre, et nous nous sommes engagés dans notre contrat social à utiliser tant que possible des logiciels libres, y compris pour l'infrastructure. D'autre part parce que c'est centralisé, et là encore notre contrat social est clair à ce sujet, même si c'est moins essentiel pour l'infrastructure que pour SàT lui-même. Enfin parce que nous utilisons à l'heure actuelle Mercurial, et que la forge la plus connue est construite autour de Git.
Ne cachons pas toutefois que nous nous sommes déjà posés la question notamment en assemblée générale (cf. les comptes rendus), nous étions intéressés en particulier par la visibilité.

« C'est centralisé ? Mais « Git » est décentralisé ! » est une réflexion que l'on entend souvent et elle est vraie, Git (et Mercurial, et d'autres) est décentralisé. Mais une forge n'est pas le gestionnaire de version, c'est tous les outils autour : hébergement, tickets, gestion des modifications (merge/pull requests), commentaires, wikis, etc. Et ces outils là ne sont pas décentralisés à l'heure actuelle, et même s'ils sont souvent accessibles par des API spécifiques aux services, ils restent soumis aux lois de la centralisation, c'est-à-dire du service qui héberge (et des aléas techniques de ce service). Cela veut également dire que si le service ne veut pas d'un projet, il peut le refuser, l'effacer, le bloquer.

La centralisation, c'est aussi la facilité pour cataloguer et rechercher… pour les projets qui sont sur ce service. Rendant de facto toute tentative extérieure moins visible et donc augmentant ses difficultés. C'est une situation que nous connaissons bien avec Salut à Toi (nous sommes également absents des « réseaux sociaux » propriétaires et centralisés pour les mêmes raisons), et que nous jugeons inacceptable. Il va sans dire que se concentrer sur une plateforme ne fait qu'encourager et prolonger cet état de fait. Notons tout de même qu'il n'est pas question ici de dénigrer ceux qui ont fait des choix différents, ces réflexions étant liées à notre implication politique forte et les contraintes changent d'un cas à l'autre.

Pourquoi, alors, ne pas utiliser des projets libres existants, avancés et fonctionnels comme Gitlab ? D'une part parce que nous travaillons avec Mercurial et non Git, et d'autre part parce que nous serions là aussi dans la centralisation. Il y a une autre raison : c'est qu'il n'existe pas ou peu (Fossil peut être ?) de forges décentralisées, et nous avons déjà tout ce qu'il nous faut avec SàT et XMPP. Et puis il y a un certain plaisir à créer les outils qui nous manquent.

SàT se veut un écosystème complet, offrant la majeure partie si ce n'est tous les outils nécessaires pour s'organiser et communiquer. Mais il est aussi générique et réutilisable. C'est pourquoi le système de « merge requests » n'est pas lié à un outil particulier (Git ou Mercurial), il peut être utilisé avec d'autre logiciels, et n'est d'ailleurs par réservé au développement de code. C'est une autre brique qui sera utilisée là où ça sera utile.

Pour conclure, je rappelle que si vous voulez voir une alternative décentralisée, éthique et engagée pour construire nos logiciels, nous organiser et communiquer, on peut la rendre possible en coopérant et contribuant, que ce soit avec du code, de la conception graphique (design), des traductions de la documentation des tests, etc.
Nous avons récemment eu de l'aide pour l'empaquetage sur Arch (merci à jnanar et aux mainteneurs précédents), et il y a des efforts continus pour l'empaquetage sur Debian (merci à Robotux, Naha, Debacle et les autre empaqueteur XMPP sur Debian). Si vous pouvez participer, merci de regarder comment nous contacter sur le site officiel), ensemble on peut faire la différence.
Si vous manquez de temps, vous pouvez aussi nous soutenir sur Liberapay: https://liberapay.com/salut_a_toi. Merci d'avance !

Click to expand… Click to reduce…

Click to reduce…

Click to expand… Click to reduce…

Click to reduce…

La dernière grosse fonctionnalité avant la préparation de la version alpha, le partage de fichiers, et désormais disponible pour Salut à Toi.

SàT est capable d'envoyer ou recevoir des fichiers depuis des années, soit directement quand 2 personnes sont connectées en même temps, ou via un téléversement sur le serveur (via « HTTP upload »).

Il est maintenant possible de partager une hiérarchie de fichiers, ou en d'autres termes un ou plusieurs répertoires. Il y a 2 cas d'utilisation principaux : avec un composant, ou un autre client.

partager un répertoire avec Cagou

Partager un répertoire avec un client

La première façon d'utiliser le partage de fichiers est directement entre 2 appareils. Ceci peut être utilisé, par exemple, pour partager des photos prises sur votre téléphone avec votre ordinateur de bureau, ou pour rapidement donner accès à des documents de travail à vos collègues.
Pour gérer les permissions, vous n'avez qu'à donner les JIDs (identifiants XMPP) des personnes autorisées (ou à cliquer sur les contacts dans Cagou, l'interface graphique).

Le transfert utilise la technologie Jingle, qui va permettre de choisir la meilleure façon d'envoyer le fichier. Cela signifie que si vous êtes sur le même réseau local que l'autre appareil (ce qui est le cas dans le précédant exemple de partager des photos prises sur le téléphone avec votre ordinateur de bureau, quand vous êtes à la maison), la connexion reste en local, et le serveur ne verra que le « signal », c'est à dire les données nécessaires à l'établissement de la connexion.

Mais si vos appareils ne sont pas sur le même réseau local, la connexion est toujours faisable, et SàT essaiera d'utiliser une connexion directe quand c'est possible.

partage de fichiers avec un client

Ci-dessus vous pouvez voir avec quelle simplicité on peut partager un répertoire avec Cagou, l'interface bureau/Android de Salut à Toi.

Le partage de fichiers avec un composant

SàT peut maintenant gérer des composants (qui sont plus ou moins des greffons génériques pour les serveurs XMPP), et un premier permet à un utilisateur de téléverser, lister, ou retrouver des fichiers.

Ceci est vraiment pratique quand vous voulez garder des fichiers privés pour une utilisation ultérieure (et y accéder depuis n'importe quel appareil), ou pour partager un album photo, par exemple, avec votre famille. Cette fonctionnalité est sur la voie d'un service similaire à ce qu'on appelle de nos jours « stockage sur le cloud », sauf que vous pouvez garder le contrôle sur vos données.

partage de fichiers avec un composant

Comme vous pouvez le voir, c'est très similaire à ce qu'il se passe entre 2 clients.

De plus avec le nouveau système d'invitation de SàT, vous pouvez partager des fichiers même avec des personnes qui n'ont pas de compte.

Quelques notes

Le transfert de fichier n'est pas encore chiffré, mais c'est prévu rapidement avec OX (OpenPGP) ou OMEMO.
La fonctionnalité de base est là et fonctionne, mais il y a encore des améliorations prévues à plus ou moins long terme : des quotas pour les utilisateurs, la synchronisation de fichiers, le chiffrement de bout en bout, ou encore la recherche avancée.

Tester

Vous trouverez sur le wiki les instructions sur comment utiliser cette fonctionnalité (en anglais).

Bien sûr vous aurez besoin de la version de développement pour tester. N'hésitez pas à demander de l'aide sur le salon SàT : sat@chat.jabberfr.org (ou avec un butineur).

Un paquet est désormais disponible pour Cagou sur AUR pour les utilisateurs d'Arch Linux, un grand merci à jnanar pour ceci.

Besoin d'aide !

SàT est un très gros projet, avec de fortes racines éthiques. Il est unique sur plus d'un point, et nécessite beaucoup de travail. Vous pouvez aider à sa réussite soit en nous soutenant sur Liberapay soit en contribuant (jetez un œil au site officiel ou venez sur le salon pour plus d'infos).

Le prochain billet sera à propos de la sortie de la version alpha, restez en ligne ;)

Click to expand… Click to reduce…

Click to reduce…

Parmi les nombreuses nouveautés et évolutions de Salut à Toi pour la version 0.7 à venir, une a un particulièrement grand potentiel : Libervia (l'interface web) est devenu un cadriciel web (ou « framework web »).

« Mais il y en a déjà plein ! » vous entends-je dire… C'est vrai, mais celui-ci est décentralisé.

Construire sur du standard, avoir des outils pour créer décentralisé

Utiliser les comptes existants

Libervia s'appuie donc sur SàT et XMPP pour aider à construire voire reconstruire le web. Quel est l'intérêt ? Et bien déjà l'authentification, chose nécessaire sur la plupart des sites de nos jours, utilise le compte que vous avez déjà. Non je ne parle pas du compte sur le gros truc bleu ou l'oisillon piailleur, mais bien de votre compte XMPP, celui que vous utilisez avec SàT, Movim, Gajim, Conversations ou encore Pidgin, celui dont les données peuvent être chez vous dans votre salon, et avec lequel vous pouvez utiliser n’importe quel nom, celui avec lequel vos faits et gestes ne sont pas épiés.

Le ou la développeur/euse n'a donc pas besoin de gérer cela, et les utilisateurs n'ont pas à recréer un compte à chaque site ou à utiliser un compte centralisé (et ainsi dire aux aspirateurs à données du net où, quand et à quoi ils se connectent).

Autre avantage : on profite de l'existant ; si vous voulez intégrer d'autre moyens de vous authentifier (par exemple utiliser vos comptes GNU/Linux), vous n'avez qu'à activer ce qui va bien sur votre serveur (voir cette liste pour prosody, vous trouverez certainement une liste équivalente pour les autres serveurs.).

pubsub, la base de données décentralisée

XMPP n'est pas une technologie, mais un ensemble de technologies cohérentes, et pubsub est l'une d'elles. Pour mémoire, il s'agit d'enregistrer des données (ou « items ») dans des « nœuds » (qu'on peut voir comme des tables ou collections dans les bases de données), qui sont sur des services.

Un service pouvant être n'importe où sur le réseau, au même endroit que votre serveur web, à l'autre bout de la planète, sur l'intranet ou sur un .onion dans le réseau Tor. Bien sûr il est possible de garder des données localement si nécessaire, notamment pour le cache.

le cache parlons en justement, pubsub a une propriété très intéressante : on peut s'abonner à un nœud pour être prévenu des modifications sur celui ci (ajout/modification ou suppression de données). Ceci permet à Libervia d'avoir un système de cache automatique : une page peut être mise automatiquement en cache et celui-ci peut-être invalidé dès qu'une modification a lieu. Voilà encore de quoi simplifier la vie du développeur, et améliorer les performances côté utilisateur.

faciliter la vie

Libervia a été pensé pour faciliter la vie des développeurs.

changer l'apparence

Le système est entièrement basé sur un moteur de modèles (jinja2), qu'il est très facile d'étendre pour faire de nouveaux thèmes (du simple changement de CSS à la transformation de toute la structure des pages). Il suffit de créer un répertoire avec le nom du thème et de modifier ce que l'on souhaite, et uniquement ce que l'ont souhaite : les pages du thème par défaut vont être utilisées si nécessaire.

Intégration entre serveur et client

Un certain nombre d'outils sont présents pour faciliter l'intégration entre la partie cliente (dans le butineur) et la partie serveur (HTTP). Ainsi par exemple, il suffit de déclarer "dynamic = True" dans votre page Libervia (côté serveur), pour activer automatiquement un système de communication dynamique avec le navigateur (basé sur les websockets). Une méthode permet d'envoyer des données n'importe quand à la page, et une autre est appelée quand des données sont émises depuis le navigateur.

Ceci sera encore plus poussé dans la version 0.8, avec l'intégration prévue de transpileurs Python vers Javascript. Libervia utilise jusqu'ici Pyjamas, un projet qui n'est plus maintenu et qui se base sur un Python 2 obsolète. Pour éviter d'être bloqué sur une seule option, le choix sera laissé au développeur d'utiliser un transpileur Python vers Javascript (Brython et Transcrypt sont prévus), du Javascript simple (dit « vanilla »), ou s'il ou elle aime se faire du mal, un cadriciel Javascript à la mode.

Gérer les tâches communes

Un système de traduction est intégré nativement (utilisant Babel), ainsi que des filtres pour les dates, le rendu d'interfaces venant du backend, ou encore la création de formulaires.

Les modèles sont prévus pour êtres réutilisables, ainsi il est simple d'intégrer, par exemple, des commentaires dans une page.

Un écosystème en symbiose

Je m'arrête là pour les fonctionnalités, même si la liste n'est pas finie (il est par exemple possible de générer des sites statiques à la manière d'un Pelican ou d'un Hugo).

Ce nouvel outil a déjà été mis en pratique dans certaines des nouveautés de la version à venir, notamment avec le gestionnaire de tickets et de demande d'intégration de patch (« merge requests ») mentionnés précédemment.

La prochaine version de Salut à Toi est un aboutissement, c'est la première version prévue pour être utilisée en production, et constitue désormais tout un écosystème de communication, de création et de travail collaboratif, compatible avec le reste de la famille XMPP.

Si vous voulez vous tenir à jour vous pouvez consulter mon blog (qui est fait avec Libervia) ou nous rejoindre sur le salon sat@chat.jabberfr.org.

Si vous voulez nous soutenir, vous pouvez soit adhérer à l'association, soit nous aider sur Liberapay.

Click to expand… Click to reduce…

Click to reduce…

Beaucoup de travail a été effectué lors des derniers mois, me laissant peu de temps pour parler des nouveautés. Jetons un coup d'œil à la dernière.

Pour le développement de Salut à Toi nous ne voulons pas utiliser de logiciels propriétaires ou centralisés et nous utilisons Mercurial, aussi nous avons jusqu'ici été réfractaires à utiliser les plateformes actuellement à la mode. Avec les améliorations récentes de notre composant SàT Pubsub (vous pouvez lire – en anglais – l'article de jnanar pour plus d'infos), et de Libervia, notre interface web, il est devenu clair que notre vieille idée d'utiliser XMPP et SàT pour gérer les tickets était à portée de main, nous l'avons donc fait.

SàT est maintenant capable de gérer les tickets via XMPP, en utilisant pubsub. Il a de nombreux avantages à cela :

  • c'est décentralisé et fédéré, pas besoin de X comptes pour utiliser X gestionnaires de tickets. Vous pouvez également importer des tickets de projets tiers (par exemple des greffons pour votre projet) dans votre propre site web.
  • c'est standard : il est possible de retrouver ou gérer des tickets sur un serveur extérieur facilement, sans API propriétaire.
  • c'est extrêmement souple : n'importe quel champ peut être utilisé, et le mécanisme peut être utilisé pour toute liste (rapports de bogues, choses à faire, liste de courses, etc.).
  • étant basé sur SàT, c'est multi-plateformes
  • on peut utiliser des passerelles, pour par exemple intégrer de manière transparente les tickets d'autres services (par exemple Gitlab ou Github)

Le fonctionnement est basé sur pubsub avec une extension expérimentale (non standard pour le moment): les schémas de nœud qui permettent de spécifier une mise en forme des données (en utilisant les « data forms » qui devra être respectée pour chaque élément (chaque ticket). De cette façon, les tickets publiés par des clients tiers peuvent être vérifiés et validés. Pubsub a également un système de permissions qui permet d'avoir des collections de tickets publiques ou privées (des nœuds dans la terminologie pubsub). Les commentaires utilisent l'extension microblogage de XMPP (qui aurait plutôt dû s'appeler « blog »).

Mais ça n'est pas tout ! Une autre fonctionnalité a été implémentée par-dessus ça : les requêtes de merges (« merges requests »). L'idée ici et d'avoir un moyen de proposer des modifications/améliorations à un projet sans être lié à un outil particulier, c'est-à-dire que l'on peut les utiliser avec Mercurial, Git ou potentiellement n'importe quel outil. Encore une fois, nous profitons de la décentralisation, et nous pouvons avoir des collaborations/contributions en personnes sur des serveurs différents.

Ci-dessous vous avez une petite vidéo (en anglais) qui montre les requêtes de merge. On utilise jp (l'interface CLI de SàT) pour envoyer les modifications à un serveur. Par défaut, le serveur va essayer tous les gestionnaires de « merge requests » jusqu'à ce qu'il trouve lequel peut gérer le dépôt demandé. Il y a une petite couche autour des commandes pour faire les opérations de base (en particulier créer les données à exporter), puis les données et métadonnées sont mises en forme et envoyées sur le nœud pubsub. Pour le moment, seul Mercurial est implémenté, mais Git va bien entendu suivre, et peut-être un gestionnaire de base utilisant un diff pour les cas les plus simples.

Note : si vous voulez faire une « merge request » pour Salut à Toi sur https://bugs.goffi.org, il vous suffit de faire depuis votre répertoire de travail:

jp merge-request set

Bien sûr, la fonctionnalité est nouvelle et encore basique : il n'est pas encore possible de préciser les lignes du code auxquelles un commentaire se réfère, ou d'utiliser une mise en forme riche. Cela va bien sûr venir plus ou moins vite, mais si vous voulez accélérer les choses, eh bien, les « merge requests » sont les bienvenues ;).

Vous pouvez le voir en œuvre sur le gestionnaires de tickets de SàT

Pour celles et ceux qui sont à Paris, je serais au « Paris Open Source Summit » (POSS) demain et jeudi (au stand A2, « Salut à Toi »). Si vous voulez aider le projet, nous sommes sur Liberapay.

Bientôt d'autres billets sur les nouveautés dans SàT…

Click to expand… Click to reduce…

Click to reduce…

Radio Prague vient de mettre en ligne une émission d'environ 10 min sur la vie privée où j'ai été interviewé pour parler de Salut à Toi.

Je suis vraiment content de l'émission qui est claire, bien expliquée, et pas trop technique . la journaliste a très bien compris le projet (ce qui n'est pas évident, il faut bien le reconnaître), et a fait du beau travail.

Vous pouvez l'écouter et la lire ici : http://www.radio.cz/fr/rubrique/panorama/la-disparition-de-la-vie-privee-nest-pas-inevitable

À écouter et faire circuler si le thème et/ou le projet vous intéressent. Comme indiqué dans lémission nous avons beaucoup de mal à nous faire connaître, aussi ce genre de chose nous aide bien.

Il y a beaucoup de choses qui ont avancé pour la version 0.7 à venir qui sera la première version dite « grand public » (comprendre, installable sans trop de difficultés et utilisable au jour le jour). J'espère trouver le temps de faire des articles pour expliquer les nouveautés comme un cadriciel (framework) web asynchrone/basé sur XMPP, la gestion des évenements ou encore des tickets (donc en décentralisé et basé sur XMPP). Si tout va bien une bêta est à attendre pendant l'été ou à la rentrée, ça sera l'occasion de s'organiser pour faciliter les contributions et mises en production.

À bientôt…

Click to expand… Click to reduce…

Click to reduce…

Click to expand… Click to reduce…

Click to reduce…

Click to expand… Click to reduce…

Click to reduce…

Salut à Vous !

Cela fait maintenant un peu plus d'un an que la campagne de financement participatif s'est achevée avec succès et que nous nous sommes engagés à développer une interface bureau/Android de « Salut à Toi », outil de communication multi-interfaces et multi-usages basé sur XMPP.

Il est temps de faire un petit état des lieux du développement. Vous trouverez en bas de cet article un lien vers une première version (pré-alpha) POUR TEST UNIQUEMENT.

Le contexte

Pour la petite histoire, nous entendions faire une campagne plus importante à l'origine quand nous avons décidé de faire un financement participatif. Mais suite à des discussions avec l'équipe d'Arizuka (plate-forme que nous avons choisie), nous avons largement réduit la somme demandée, ce qui s'est avéré judicieux puisque nous avons réussi la campagne : nous avons récolté 3 326,00 € sur les 3000 € demandés, soit 3 159,70 € après les frais.

Évidemment, cette somme est insuffisante pour vivre, aussi nous avons repris une activité salariée (j'en ai d'ailleurs parlé ici) et dû réduire le rythme de développement : je suis le seul développeur actif à l'heure actuelle (avec quelques contributions, notamment les accusés de réception et la authentification HTTP par XMPP par Chteufleur).

Ajouté aux choses annexes (gestion de l'association, écriture d'articles, projets liés, etc), ceci explique le temps de développement.

C'est aussi cette situation qui explique que nous avons réduit notre participation aux événements du Libre, ainsi vous ne nous avez pas vu au Fosdem cette année.

La plupart des contreparties promises aux soutiens ont été fournies (mais pas toutes, certaines n'ayant pas encore été réclamées). La somme reçue n'a pas encore été utilisée, sauf pour les frais fixes (serveurs, plate-forme de paiement des cotisations, banque).

Si ceci vous intéresse, vous trouverez les détails dans le compte rendu de la dernière assemblée générale extraordinaire de notre association.

Cagou

Comme déjà annoncé, la nouvelle interface de bureau et pour appareils mobiles (Android pour le moment) de SàT s'appelle « Cagou », un clin d'œil à l'outil Kivy que nous utilisons, et à cet oiseau emblématique de la Nouvelle-Calédonie, oiseau qui ne vole pas et qui aboie.

Développement

Cette partie est technique, vous pouvez passer directement à la suivante si cela ne vous intéresse pas.

Après une petite phase de prise en main de l’écosystème de Kivy, la première étape a été d'intégrer « Quick Frontend » (frontal rapide) qui est une base que nous utilisons, comme son nom l'indique, pour développer rapidement un frontal et factoriser le code (gestion du cache, de la liste des contacts (« roster » en XMPP), des widgets, etc.), puis d'intégrer le « bridge » (pont) qui est le nom que utilisons pour l'IPC qui permet la communication entre le « backend » (démon qui gère le cœur de SàT) et les frontaux.

Cette phase s'est relativement bien passée, elle a été accompagnée d'une réflexion sur l'architecture et l'interface utilisateur.

Une fois ceci à peu près utilisable, le port sur Android a pu commencer.

Les choses ont été un peu plus compliquées. La communauté Kivy a créé plusieurs outils pour développer sur cette plate-forme, dont python-for-android (outils de compilation et empaquetage) et Buildozer (outil multi-plateformes qui facilite l'utilisation du premier). La prise en main de ces outils demande quelques efforts, surtout pour un projet déjà en place (c'est nettement plus simple quand on commence directement avec Kivy et le port Android).

Il y a 2 « chaînes » de développement pour Android, l'ancienne et la nouvelle. Après des premiers tests non concluants avec la nouvelle, elle a été temporairement mise de côté pour l'ancienne le temps de développer les bases du port.

Les dépendances en Python pur s'importent facilement, mais dès que ça se complique un peu, il faut faire des recettes (« recipes ») pour indiquer à python-for-android comment faire la compilation. Heureusement, la plupart de celles nécessaires pour SàT (en particulier Twisted) étaient déjà disponibles, il a toutefois fallu les mettre à jour.

Une fois ces questions de dépendances et de chaîne de compilation réglées, et après le plaisir de voir un premier .apk apparaître (mais non fonctionnel). 2 autres gros problèmes se sont posés : D-Bus qui est le « bridge » principal n'est pas utilisable sur Android, et comment faire fonctionner backend et frontal en même temps ?

Étant novice pour le développement sur Android, j'ai dû lire beaucoup de documentation (qui ne manque pas heureusement) et après un premier essai avec un nouveau bridge « embedded » permettant d'avoir backend et frontal dans le même processus, c'est finalement l'écriture d'un bridge « pb » pour perspective broker, IPC de Twisted, qui s'est révélé être la meilleure solution. L'IPC d'Android est aussi une piste à explorer à l'avenir.

Pour lancer le backend, Kivy fourni des outils permettant de le lancer comme service Android, ce qui permet de le garder en arrière plan et de pouvoir gérer les messages et autres activités quand l'interface n'est pas visible pour l'utilisateur (ce qui signifie sur Android que l'interface est gelée jusqu'à ce qu'elle soit de nouveau sélectionnée par l'utilisateur).

Cette section est déjà bien longue, aussi je vous passe les autres difficultés (comme l'absence de widget gérant le HTML), parlons maintenant de l'interface.

L'interface

Cagou est donc utilisable sur bureau (GNU/Linux, mais probablement d'autres plates-formes également) et sur Android.

La version actuelle est une pré-alpha, l'.apk plus bas est fourni uniquement pour se faire une idée. Elle est très boguée, ne vérifie pas encore les certificats sur serveur, les enregistrements SRV ne sont pas pris en compte sur Android, etc. Elle est fournie pour d'une part montrer l'avancement, et d'autre part profiter des retours suffisamment tôt dans le développement pour prendre une bonne direction.

concepts de base

L'interface de Cagou est inspirée de celle de l'excellent Blender. En particulier la sélection de widget et la possibilité de faire des divisions à volonté en faisant glisser les bords du widget. Les grosses barres actuelle devraient disparaître à terme pour un bouton plus discret, probablement là encore inspiré de Blender. L'idée est qu'un utilisateur novice puisse changer de widget intuitivement, et qu'un utilisateur avancé puisse utiliser cette fonctionnalité.

séparation de widdgets

La liste des contacts n'est pas l'élément principal de l'interface, elle peut être affichée si souhaité, mais n'est pas nécessaire à l'utilisation de Cagou.

Le menu en haut, pour le moment tout le temps visible, ne devrait être disponible que sur bureau, sur Android le bouton menu ou un bouton flottant vont probablement le remplacer d'ici la sortie stable.

Si vous avez des notifications, elles apparaissent pendant quelques secondes en haut, mais vous pouvez le lire en prenant votre temps en caressant la tête du cagou qui apparaît alors en haut à gauche.

une notification dans Cagou

Dans le cas d'événements nécessitant votre intervention (par exemple une autorisation d'accès via XMPP sur un site), un cagou apparaîtra sur la droite, et le dialogue n'apparaîtra qu'après l'avoir touché. L'idée est de ne jamais avoir de fenêtre modale (type « pop-up ») qui surgit et vole le focus alors que vous faites autre chose. Ces dernières n'apparaissent que suite à une action de l'utilisateur.

Dans le cas d'Android, il est possible que ces notifications soient remplacées par le système de notification natif, mais le choix n'est pas arrêté puisque l'historique des messages ne serait alors plus disponible.

Pour changer de mode (de widget), il suffit de cliquer sur le bouton en haut à gauche du widget actuel. Il n'y a actuellement que 4 widgets : le sélecteur qui affiche tous ceux disponibles, la configuration, la liste de contacts, et le chat. D'autres sont à venir, en particulier le blogage.

sélection du widget/mode

À l’intérieur d'un widget (uniquement pour la messagerie instantanée pour l'instant), il est possible de faire un mouvement de glisser horizontal pour passer d'une conversation ouverte à une autre.

exemple d'un glissé de widget dans Cagou

Pour le moment ça n'est pas évident à utiliser la première fois (il faut faire un mouvement vif), il y a des petits réglages à prévoir.

Comme pour le reste de SàT, Cagou est prévu dès l'origine pour fonctionner avec des greffons et être facilement extensible. Tous les widgets et système d'envoi de fichiers (voir plus bas) sont des greffons.

messagerie instantanée (chat)

Comme nous voulons une interface utilisable sur petits écrans, simple, mais qui ne sacrifie pas les fonctionnalités, il faut trouver un compromis entre les informations affichées/ables à l'écran et les éléments/boutons permettant des actions. Trop d’éléments compliquent l'interface et prennent de l'espace, mais trop peu rendent les actions difficiles d'accès.

La disposition choisie actuellement (qui peut évoluer) consiste en un en-tête avec une barre de saisie et un bouton (en plus du sélecteur de widgets), le corps avec les messages, et une barre de saisie avec un bouton également.

Pour discuter avec un ou des contact(s), entrez des lettres faisant partie de son nom (n'importe où dans le nom). Pour le moment uniquement les identifiants (« jid ») et les conversations déjà ouvertes sont cherchés, mais à terme la recherche se fera également dans les noms, surnoms et dans les marque-pages.

sélection d'un contact pour une discussion instantanée

Cagou détecte si vous voulez parler à une personne seule ou dans un salon de discussion, et s'adapte en conséquence.

Le chiffrement de bout en bout est de la partie, mais uniquement avec OTR (v2) à l'heure actuelle. Il est prévu d'intégrer OX (OpenPGP moderne) et OMEMO, mais il n'est pas certains que ça sera disponible pour la prochaine version (ça sera peut-être pour la 0.8). Pour l'activer, il suffit de cliquer sur le cadenas, ce dernier sera fermé si la conversation est chiffrée, et aura un point d'interrogation si votre correspondant n'est pas authentifié.

Passons directement à la barre de saisie. Vous trouverez sur la droite un bouton « + » qui sert pour le moment à ouvrir le dialogue d'envoi d'élément.

Ce dialogue comporte 2 boutons en haut, qui permettent de choisir si vous voulez téléverser votre fichier ou l'envoyer directement à un correspondant en pair à pair. Un texte en dessous indique en langage clair où votre fichier transitera, et si le chiffrement intervient (à l'heure actuelle tout est en clair pour les fichiers).

Le message texte est important pour que l'utilisateur comprenne bien où vont ses données, c'est une indication que l'on va sûrement placer à divers endroits stratégiques.

dialogue d'envoi de fichier sous Android

Les boutons en dessous sont les types d'envoi. Sur bureau il n'est actuellement possible que d'envoyer un fichier de votre arborescence, mais sur Android il est possible également d'envoyer une photo de votre galerie, d'en prendre une nouvelle ou de faire une vidéo, et d'enregistrer un message audio.

Voici à quoi ressemble l'enregistrement de messages :

enregistrement d'un message audio

et autour

En plus du travail sur Cagou lui-même, d'autres travaux ont été effectué.

Désormais indispensable avec l'utilisation sur appareils portables, la copie carbone a été implémentée. La gestion des archives sur le serveur est elle implémentée depuis longtemps pour le blogage, mais pas encore pour les messages, ça sera fait d'ici la sortie de la version stable.

La gestion des petits fichiers binaires (« BoB » pour « Bits of Binary ») est désormais disponible, son implémentation a notamment été motivée parce qu'ils sont utilisés par Movim.

Comme indiqué plus haut, les accusés de réception et l'authentification HTTP ont été implémentés par Chteufleur.

Depuis la 0.6.1 la gestion des messages a été améliorée, préparant notamment le terrain pour des fonctionnalités comme la correction du dernier message, prévue pour la version stable.

Plus récemment la gestion des composants (pour préparer les passerelles) et des blogs statiques sont également arrivés, mais nous en parlerons peut-être une autre fois.

soutien

C'est un appel que nous faisons souvent mais qui n'est pas toujours entendu, de l'aide serait grandement appréciée.

Ce peut être aussi simple que venir discuter avec nous (notre salon est à sat@chat.jabberfr.org, disponible en cliquant sur ce lien).

Si vous avez de quoi, une contribution financière serait bien sûr utile, nous avons récemment ouvert un compte sur Liberapay, suite a discussion résumée dans le compte rendu de l'A.G. lié plus haut. Notre objectif est de réussir dans un premier temps à travailler un jour par semaine sur SàT et de compenser la perte de salaire par des dons.

Vous pouvez aussi adhérer à notre association, toutes les infos sont par ici. Vous choisissez le montant de la cotisation (entre 0 et 100 €).

Et bien sûr des contributions, en particulier du développement, mais aussi des traductions, du graphisme, du thème CSS, de l'administration des serveurs. La plupart du développement est fait en Python, et c'est participer à un outil que vous utiliserez potentiellement tous les jours.

Parler de notre association et projet autour de vous est toujours utile.

Je crois que l'essentiel est dit pour cette fois, j’essaierai de tenir informé avec des billets moins longs les prochaines fois.

Ah, et le lien vers la pré-alpha actuelle (encore une fois: POUR TEST UNIQUEMENT): https://www.goffi.org/public/Cagou-0.1-debug.apk

Click to expand… Click to reduce…

Click to reduce…

Salut à vous,

je n'avais pas abordé mon activité salariée jusqu'ici, une récente émission diffusée sur Radio Prague m'en donne l'occasion.

Je travaille pour Sourcefabric, une organisation à but non lucratif qui produit plusieurs logiciels libres, dont vous connaissez peut-être certains : Newscoop, Airtime, Booktype (utilisé notamment par FLOSS manuals), Live Blog et Superdesk. C'est pour développer ce dernier que je suis employé, il s'agit d'un logiciel destiné au journalisme, qui permet de gérer le cycle de vie d'un article dans une salle de rédaction virtuelle.

L'émission présente cette organisation de 3 points de vue : un des fondateurs, un employé (moi), et un client, on y parle de logiciel libre et de journalisme.

Vous trouverez l'émission ainsi que sa retranscription en cliquant sur ce lien ou sur ce lien direct vers le fichier audio.

Click to expand… Click to reduce…

Click to reduce…

Salut à vous,

Cagou commençant à prendre sérieusement forme, il est temps de faire un billet sur l'avancement.

Avant le début du développement de l'interface elle-même, des changements nécessaires ont été faits en particulier sur la gestion des messages. Outre la gestion des langues dont j'ai parlé dans des précédents billets, le plus important est que nous pouvons désormais changer l'état d'un message après réception, ou y faire référence. Ceci permet d'implémenter des fonctionnalités comme les accusés de réception, ce qui a été fait par une contribution de Chteufleur (merci :)). D'autres fonctionnalités qui attendaient comme la correction du dernier message vont bientôt pouvoir suivre.

Il était nécessaire de faire ce travail avant d'implémenter la messagerie instantanée sur Cagou, pour pouvoir partir sur de bonnes bases.

Ensuite il a fallu intégrer l'interface sous Kivy à SàT, et en particulier D-Bus et QuickFrontend, notre modèle pour faire des frontaux en Python.

Tout ceci s'est relativement bien passé, et voici une petite vidéo pour vous mettre en appétit :

Quelques explications maintenant.

Comme vous le voyez, l'interface peut-être divisée facilement. Cette idée est inspirée de l'excellente interface de Blender, et permettra de s'adapter facilement à un petit ou grand écran en choisissant le nombre de widgets et leur disposition.
Au lieu d'être un logiciel discret qu'on utilise uniquement quand on veut répondre à quelqu'un, Cagou est une interface qui s'utilise principalement en plein écran, avec une disposition adaptée à la situation et les outils importants directement visibles (si la taille de l'écran le permet).

Autre point important, la liste de contacts n'est pas l'élément central comme c'est souvent le cas dans les logiciels de messagerie. Vous pouvez y accéder en sélectionnant le widget, voire la mettre sur le côté pour reproduire le comportement traditionnel, mais elle n'est pas affichée par défaut et n'est pas indispensable.

sélection de widget

Tous les widgets sont des greffons, a terme il devrait être possible d'en télécharger, ou de changer complément le fonctionnement d'un widget de base. Comme effet de bord, et surtout grâce au travail de l'équipe derrière Kivy, Cagou sera une plate-forme qui permettra d'échanger facilement des scripts Python sur Android (reste à voir comment on va gérer les permissions).

En ce qui concerne les notifications, le fonctionnement va être différent sur bureau et sur les plates-formes qui ont déjà un système de notification (comme Android). Dans ce dernier cas, le système de la plate-forme va être utilisé.
Sur bureau, un en-tête spécifique est utilisé. 2 icônes de Cagou (merci à Muchoslava pour ses contributions) peuvent apparaître : une à gauche pour les notes (c.-à-.d les messages court qui ne s'affichent que quelques secondes), et une à droite pour les notifications plus importantes, nécessitant l'action de l'utilisateur.
Un clique sur l’icône de gauche permet d'afficher les 10 dernières notes, et un sur l’icône de droite affiche la notification importante suivante.

Ceci a été pensé pour éviter les popups, ces dernières ne sont affichées que suite à une action de l'utilisateur, et n’apparaissent pas d'elles même si un quelconque événement les déclenche.

exemple de notification

Les menus ont également été implémentés, ils apparaissent en haut sur bureau. Sur petits écrans (téléphones), ils ne seront sûrement visibles que suite à l'appui de la touche idoine.

Grâce au fonctionnement de Salut à Toi, ceux-ci permettent déjà de faire des actions de base comme ajouter ou modifier un contact et avancées comme piloter son serveur.

Enfin le lancement d'une conversation peut se faire de plusieurs manières. On peut en commencer une en cliquant sur un contact dans le widget « liste de contacts », ou en tapant son jid dans un widget « chat » (il devrait rapidement être possible de taper quelques lettres pour avoir les suggestions). Les conversations ne se ferment pas quand on change de widget, on peut accéder aux conversations en cours en faisant passer son doigt (ou sa souris pendant un clique) rapidement vers la droite ou la gauche, cf. la vidéo ci-dessous. Il sera bientôt possible de les fermer via un menu dédié.

Voilà l'état des lieux actuel. Il y a déjà eu beaucoup de travail, et l'interface commence à être vraiment utilisable. Côté bureau le plus gros est fait, il s'agit maintenant d'adapter l'interface aux fonctionnalités (afficher l'accusé de réception par exemple), et à faire de nouveaux widgets. Un gros morceau reste toutefois l'affichage du contenu HTML, vu que ça n'est pas géré de base par Kivy (mais il y a différentes solutions possibles).

En ce qui concerne Android, il va y avoir une partie qui risque d'être un peu difficile pour faire le port, mais je ne m'inquiète pas plus que ça.

J'envisage également de faire un port sur Ubuntu Touch, j'ai commandé à cette fin une tablette d'occasion qui devrait me permettre de l'installer (ce n'est pas une promesse, juste une éventualité).

Ah et bien sûr, Cagou va profiter des fonctionnalités de SàT, y compris le chiffrement de bout en bout (OTR pour le moment, mais OpenPGP est envisagé pour la 0.7, et peut-être OMEMO également).

Petite note pour les programmeurs : une fois la prise en main passée (qui n'est pas très difficile), j'apprécie beaucoup travailler avec Kivy, c'est souple, agréable à utiliser et ça fonctionne jusqu'ici très bien, félicitation aux équipes derrière.

Je conclus sur une bouteille à la mer : c'est un travail absolument énorme de travailler sur SàT, et à l'heure actuelle je suis pratiquement seul dessus, et en plus de mon emploi salarié. Le projet avance toujours à bon train, mais j'ai besoin d'aide. La base de code est importante, mais il n'est pas insurmontable de s'y mettre : Chteufleur mentionné plus haut a pu rapidement écrire des greffons et a fait les implémentations des XEP-0070 et XEP-0184.

Il est aussi possible de contribuer en dehors du code : empaquetage pour des distributions, tests, graphismes, traductions, installation de serveurs, etc. Contribuer à une bibliothèque utilisée par SàT (comme l'implémentation de XMPP dans Twisted ou Kivy) est également très utile.

Au passage, je rappelle à ceux qui ont participé à la campagne de financement, qu'ils peuvent nous contacter sur « contact chez salut-a-toi point org » pour réclamer leur contrepartie, ou la demander plus tard s'ils préfèrent.

À très bientôt pour la suite :)

Click to expand… Click to reduce…

Click to reduce…

Salut à tous,

la version 0.6.1 de Salut à Toi vient de sortir, et elle est conséquente malgré son numéro de version mineur. La prochaine version — qui est déjà bien entamée — sera la version « grand public » que nous annonçons depuis des années, autrement dit une version que nous voulons suffisamment stable pour être utilisée au quotidien, et suffisamment facile à installer pour être disponible pour un large public.

Vous pouvez toujours vous référer au journal des modifications (changelog) ou au dépôt pour avoir le détail, mais voici quelques unes des nouveautés et corrections principales :

  • plugin d'import extensible avec « importeurs » pour Dotclear et DokuWiki. Notez bien que grâce à l’utilisation des standards, ça peut vous être utile même si vous n’utilisez pas SàT pour afficher votre blog (c’est compatible avec Movim par exemple)
  • en plus de l'import Dotclear, la syntaxe wiki Dotclear est également disponible avec SàT désormais, elle vient s’ajouter à Markdown et XHTML.
  • inscription automatique à un flux PubSub pour les nouveaux comptes, ce qui évite d'arriver sur une page vide
  • MAM (XEP-0313) est implémentée pour PubSub, ce qui permet de remonter dans les articles et de faire des recherches de manière beaucoup plus souple et puissante. Notez que MAM n’est pas encore disponible pour la messagerie instantanée, ce sera le cas pour la 0.7
  • meilleure détection de la version du dépôt utilisée
  • jp (l’interface en ligne de commande) a désormais une option --output qui permet de spécifier le format de sortie (par exemple du JSON ce qui permet de facilement parser le résultat avec une autre commande). C’est encore peu utilisé mais la base est là.
  • jp : nouvelles commandes pour importer un blog (import), (ré-)éditer un nouveau/ancien billet (edit) ou voir l’aperçu mis à jour en temps réel (preview). Pour plus d’infos, référez-vous au billet d’explication qui montre comment publier sur votre blog avec Vim ou autre
  • jp : des nouvelles commandes également pour la gestion du roster, qui permettent de l’afficher (get), d’avoir des statistiques (stats) ou de le nettoyer (purge)
  • jp : la commande « message » a été déplacée vers « message send » par cohérence avec les autres commandes, et parce qu’un « message get » est à prévoir
  • jp : les codes de retour utilisent maintenant des constantes, afin qu’ils soient plus utiles
  • Primitivus (interface console) : détection d’un « coller » (une validation est nécessaire dans ce cas, ce qui évite l’envoi accidentel d’un mauvais message comme un mot de passe copié peu avant) et gestion du mode « bracketed paste »
  • Libervia (interface web) : une nouvelle option « allow_registration » permet de désactiver la création de nouveaux comptes, pratique si vous êtes seul sur votre instance, ou si vous créez les comptes par vos propres moyens
  • Libervia : affichage d’un message avec compteur en cas de perte de connexion avec le serveur
  • Libervia : utilisation d’une nouvelle favicon avec un compteur de notifications visible
  • Libervia : correction de la connexion avec un compte (jid) extérieur. Cette fonctionnalité très demandée nous avait causé de gros problèmes à la sortie de la 0.6.0, ils devraient être désormais réglés.
  • Libervia : il est maintenant possible de rediriger les pages ou d'intégrer un répertoire local dans Libervia. C’est ce qui permet d’afficher directement le blog au lieu de la page d’enregistrement sur www.goffi.org.
  • Libervia : gestion des chaînes TLS (Let's Encrypt, si tu nous lis…)
  • Libervia (blog): gestion des étiquettes (tags), y compris la recherche

Voilà pour un aperçu, et c’est loin de couvrir toutes les améliorations de la 0.6.1.

En lisant ceci vous aurez peut-être une petite idée de la quantité de travail nécessaire pour faire avancer un projet comme celui-ci, sachant que nous ne sommes que 2 (et que pour la 0.7 je suis pratiquement tout seul). Aussi si vous voulez participer à un projet éthique et qui refuse de céder aux sirènes des grosses entreprises privatristes, contactez-nous (contact at salut-a-toi point org) ! Rejoignez-nous sur notre salon MUC ! Venez nous aider, on en a grand besoin !

La version 0.6.1 n’est pas parfaite, elle a quelques problèmes (connus ou non), mais nous avons préféré sortir cette version qui malgré tout fonctionne, pour nous concentrer sur la 0.7, qui sera la première version « grand public », annoncée depuis des années.

La version 0.7 passera par une phase de bêta test, et devrait apporter en particulier :

  • un ré-usinage des messages qui permettra d’implémenter de nombreuses extensions bloquées jusqu’ici, comme la correction du dernier message, ou les archives côté serveur (MAM). Cette partie est déjà finie

  • Cagou, l'interface bureau/appareils portatifs que nous avons promis suite au succès de notre campagne de financement participatif. Le développement est bien avancé, bientôt un billet sur le sujet

  • des passerelles de messagerie et de blog. Cela fait longtemps qu'on parle d'en faire, les premières devraient voir le jour dès que Cagou est disponible

En dehors de ça, il est probable que nous implémentions de nouveaux systèmes de chiffrement de bout en bout, en plus d'OTR qui est déjà disponible. OpenPGP est visé en particulier, ainsi qu'OMEMO.

Les grosses fonctionnalités comme l’organisation d’événements ou les calendriers partagés sont plutôt envisagées pour la version suivante.

Ah, et la nouvelle version est disponible comme d’habitude sur le FTP, sur PyPi ou directement depuis le dépôt.

Click to expand… Click to reduce…