Standardiser Markdown, c’est urgent

J’ai gazouillé plus tôt dans la journée que « Un des trucs dont l’Humanité a le plus besoin, c’est d’une normalisation d’un Markdown étendu, prenant en compte les annotations ». Cette forte pensée a suscité quelques réactions et comme 140 caractères sont un peu courts pour répondre, je vais développer ici. Markdown est mon langage de balisage favori, sans doute puisque, comme il s’inspire de conventions ancestrales pour la rédaction de mails, je le trouve assez intuitif.

Malheureusement, il lui manque quelques fonctionnalités pour couvrir l’essentiel de mes besoins, et en particulier une syntaxe pour des annotations ou des notes de pied de page dont je suis très friand. Et John Gruber ne semble pas décidé à faire évoluer la spécification originale qu’il a élaborée avec Aaron Swartz. De ce fait, de nombreuses propositions d’extension ont fleuri, comme par exemple MultiMarkdown et PHP Markdown Extra. Chacune de ces propositions a une implémentation de référence, et plusieurs outils proposent leur propres variantes, comme Maruku, Kramdown et bien entendu le couteau suisse Pandoc, l’outil quasi universel de conversion entre langages de balisages. Sans oublier bien sûr Github qui a également ses propres variations.

Les fonctionnalités proposées par les propositions d’extensions et les divers outils sont globalement les mêmes : notes de bas de page, tableaux, etc. Et les syntaxes similaires, mais avec d’infimes variations qui les rendent incompatibles entre elles. De fait, à moins de se limiter à la syntaxe de base, les documents écrits en Markdown ne sont pas interopérables. J’écris en ce moment cette note en Markdown et Maruku va la transformer en HTML. Mais rien ne me garantit que si demain je choisis un autre convertisseur, je ne vais pas perdre certaines informations, comme les notes de bas de page. C’est pourquoi il est urgent de se mettre d’accord sur une norme pour un Markdown v2 étendu. On pourra ainsi évaluer les différents outils existant à l’aune de leur respect de cette norme.

Le besoin d’une telle norme n’est pas récent, et en Octobre 2012 un groupe communautaire s’est créé au sein du W3C. Malheureusement, si j’en crois la liste de discussion publique, après une activité intense dans les premières semaines de son lancement, le groupe semble aujourd’hui en profonde hibernation (aucun message sur la liste publique depuis plusieurs mois). Sa principale production est un début de suite de tests, rédigés pas Karl. Vu l’engouement continu autour de Markdown depuis des années, je ne m’explique guère ce manque d’empressement à le standardiser. Et ne peut qu’espérer une prochaine standardisation d’une syntaxe pour les notes de pied de page, histoire de garantir l’interopérabilité de mes textes qui en font usage.

Je veux payer

source : un échange avec Karl à propos des difficultés rencontrées par les développeurs d’Opquast Desktop.

J’entend régulièrement des plaintes à propos du système de revue des extensions de Firefox, et je crains que ses problèmes n’affectent demain l’épicerie d’applications Web promue par Mozilla. Je connais mal le problème, ce qui ne m’empêche pas d’avoir une opinion dessus.

Mozilla est une organisation à but non lucratif qui ne vend pas de produits. Ses ressources ne sont pas infinies, et toujours fragiles. Elle doit donc choisir la priorité de leur affectation afin de remplir au mieux sa mission, à savoir aider à faire d’internet un lieu convivial. Les extensions ont beaucoup contribué au succès de Firefox, mais ne sont plus aujourd’hui prioritaires. Ça ne signifie pas qu’elles ne sont plus importantes. Mais elles sont moins importantes que d’autres sujets au regard des objectifs actuels, à savoir garantir l’ouverture d’Internet dans l’univers mobile. Un peu comme Thunderbird en fait. Un beau projet, utile, nécessaire, mais plus au centre des préoccupations de la Fondation. Je partage le sentiment que trop se disperser empêche malheureusement d’avancer. Mozilla ne peut donc allouer à la revue des extensions les ressources nécessaires pour en faire un service qui satisfasse tout le monde.

Mais je dirais que peu importe. Si quelque chose n’existe pas, c’est qu’il y a une opportunité pour le créer. Et de même que je pense qu’il y a un marché économiquement viable pour maintenir Thunderbird (ce que font je crois plus ou moins quelques SSLL françaises), autant je pense qu’il y aurait de la place pour une plateforme de diffusion d’extensions et d’applications Web externe à Mozilla et économiquement viable. Ou du moins, il y aurait de la place si on arrêtait de mythifier la gratuité et si on disposait d’un système propre de micro-paiement.

Je défend la liberté entendue comme l’extension des droits des citoyens numériques. Je sais que cette liberté a un coût. Ce coût peut-être du temps. Ici cela signifie prendre le temps de me former puis pour chaque extension que je veux installer, analyser son code pour m’assurer qu’il ne pose pas de problème. Mais si je ne veux pas dépenser ce temps, ça ne me dérangerait pas de payer quelqu’un pour le faire à ma place (j’ai la chance d’avoir plus d’argent que de temps libre). Après tout, avant l’ADSL, j’achetais des revues informatiques pour récupérer des distribs GNU/Linux sur le CD joint plutôt que de passer mes nuits à les télécharger en 56ko. La gratuité est une conséquence non obligatoire de la liberté du code et de l’ouverture de l’organisation le produisant.

L’hébergement d’extensions par Mozilla a pour moi une vraie valeur ajoutée : je sais que les extensions que j’y trouve ne contiennent probablement pas de code volontairement ou non nuisible. J’attache de l’importance à cette tranquillité et serais près à verser quelques cents chaque fois que j’installe une extension pour payer le service. Mais à condition de disposer d’un système de paiement que me satisfasse (ie ou l’intermédiaire technique ne se goinfre pas de 30% de la transaction et qui ne permette à aucune des parties en présence de collecter des informations sur moi à partir de mes achats).

Le code source de l’épicerie d’applications développée par Mozilla est libre, c’est à dire que quiconque peut créer un site offrant un service de revue (ça n’est pas tout à fait vrai, toutes les places de marché ne pourront pour l’instant pas distribuer certaines applications critiques). Il suffit de trouver un moyen de financer ce service et surtout de gagner la confiance des utilisateurs et développeurs.

Je ne sais pas si une entreprise remplissant ces critères serait viable. Mais il y a à mon avis une voie à explorer. Plus de 3 milliards d’extensions ont déjà été téléchargées. Même en ne facturant que quelques cents par extension, cela représente une belle somme. Suffisante pour couvrir le coût le revue équivalent ? Aucune idée. Vos avis ?

Un navigateur de contenus personnels

En vrac, trois réflexions que l’annonce de la fermeture prochaine de Google Reader m’a inpiré.

Un — faire mieux au lieu de geindre

Les gens sont vraiment cons, ils mangent de la merde. En fait ils n’ont que ce qu’ils méritent, ils n’ont qu’à faire leurs courses au marché chez des petits producteurs régionaux, être dans une AMAP, faire la cuisine. Ce n’est quand même pas compliqué de bien manger !

Je fais partie de ces cons qui mangent de la merde. Parce qu’avoir une alimentation saine ne fait pas partie de mes priorités. Cela demande du temps et je préfère consacrer mon temps à des choses que j’estime plus importantes (comme lire Twitter, chacun ses choix). Aussi, je n’adhère plus au discours qui en réponse à la fermeture de Google Reader, appelle à installer sur son serveur un des nombreux lecteurs de flux libre. Arrêtons de penser en geeks. Moi même, tout geek que je sois, je n’installerai pas un clone de Google Reader sur un serveur, parce que j’essaie de réduire le temps que je passe à faire de l’administration système. Question de priorités.

Si nous voulons promouvoir ATOM et compagnie, ce n’est pas avec ce discours que nous y arriverons. Mais en fabriquant des produits au moins aussi bons, beaux, utiles, utilisables, que leurs alternatives privatives. Des logiciels qui seront choisis et utilisés parce qu’ils ne demandent pas d’efforts et améliorent la vie. Encore une fois, le succès de Firefox n’est pas dû à sa philosophie. Seule une petite minorité l’utilise parce qu’il est libre. Je suis persuadé que la grande majorité de ses utilisateurs l’ont choisi parce qu’il est objectivement meilleur, sur un plan ou un autre, que les autres navigateurs. Donc avant de blâmer ces crétins entre la chaise et le clavier qui deviennent prisonniers volontaires de services privateurs, blâmons nous de ne pas créer de logiciels meilleurs que leurs alternatives. Et, pour ceux d’entre-nous qui ne sont pas adeptes de l’auto-flagellation, sortez vous les pouces de la bouche, et au lieu de troller, créez !

Deux — savoir ce que l’on veut

Je n’ai jamais utilisé Google Reader. Je ne comprends donc pas son succès parmi les geeks et les infovores. Mais de quelques lectures et échanges depuis l’annonce de sa fermeture, j’ai l’impression que ce que ses veufs et veuves regretteront, ce n’est pas tant le lecteur RSS que le logiciel leur permettant de gérer de manière agréable une partie des contenus qu’ils consultent. Et que donc ce qui nous manque, ce n’est pas un nouvel agrégateur RSS, mais un bon système de gestion de contenus personnels. Par contenus personnels, j’entends tous les articles intéressants que nous voyons passer, en surfant ou qui nous arrivent directement via des flux, RSS, Twitter, les partages de marque-pages, etc. Mais aussi les discussions, sur des listes de courrier électronique, Twitter voire IRC. Tous ces articles que nous mettons de côté pour les lire un jour, que nous partageons, que parfois nous annotons ou commentons.

Aujourd’hui, tous ces contenus sont dispersés. Des dizaines de dossiers thématiques dans notre courrielleur, nos lecteurs de groupe de discussions et de flux RSS, des centaines d’onglets ouverts dans notre Firefox, divers gestionnaires de signets, des favoris dans Twitter, les journaux IRC, j’en oublie. Et pourtant, quel que soit le canal par lequel arrivent ces informations, elles sont globalement similaires. Des articles ou des conversations, des métas-données, et parfois des ajouts personnels, catégorisation et commentaires. Il me semblerait pertinent de les agréger dans un seul outil. Techniquement, ce n’est guère compliqué, et je pense qu’avec toutes les briques existantes, on pourrait facilement bricoler ce genre d’outil. Mais le succès de Google Reader me semble lié davantage à son ergonomie qu’à une supériorité technique. Et c’est sur ce point, l’utilisabilité, que se jouera la crédibilité des alternatives.

Le remplaçant du défunt lecteur de Google n’est donc peut-être pas à chercher du côté d’autres lecteurs de flux, mais de la création d’un gestionnaire de contenus personnels ergonomique. Qui archive tous les contenus que nous voyons passer, avec leurs méta-données. Qui nous permette d’y accéder de partout. En rende la lecture agréable. Le partage simple comme un clic. Et permette de les enrichir. Le tout doté d’une interface agréable à utiliser quelle que soit sa maîtrise de la chose informatique. Le navigateur de contenus de David est un pas dans cette direction.

Yaplukafokon

Trois — considération pratique

J’ai beau être conscient du danger des services en ligne comme Google Reader, je dois reconnaître qu’ils sont très pratiques et que leur trouver des alternatives accessibles et crédibles est difficile. Ils sont pratiques car ils offrent un service accessible de partout depuis un simple navigateur. Difficiles à concurrencer car, comme il n’est pas réaliste à court terme d’imaginer qu’une majorité d’internautes auto-héberge ses outils, concurrencer les services de Google et compagnie suppose pour l’instant de mettre en place une architecture technique similaire. C’est à dire une masse de serveurs pour traiter et stocker les données.

L’arrivée des applications Web va probablement modifier une partie du problème. Grâce à HTML5, on peut à présent créer des applications dont tous les traitements s’effectuent dans le navigateur. Les serveurs n’ont plus qu’à fournir des fichiers statiques, et gérer le stockage et la synchronisation des données. De plus en plus d’applications vont je pense adopter un modèle composé d’une applications HTML5 s’exécutant dans le navigateur, et d’une API serveur au dessus du modèle de données. La difficulté logistique à fournir un clone libre à Google Reader s’en trouve largement réduite. Reste la question du stockage des données.

J’ai proposé de détourner IMAP et d’utiliser les comptes mails que chacun possède comme entrepôts décentralisés de données, mais mon idée n’a guère suscité de réactions. Les Grands Génies sont rarement reconnus de leur vivant. Je reviens donc à la charge avec une autre proposition : inciter les FAI à soutenir le projet unhosted. L’idée de ce projet est de découpler le traitement des données de leur stockage. Ce qui permet d’utiliser un service hébergé tout en stockant ses données dans un autre dépôt, soit auto-hébergé, soit chez un prestataire. Il encourage donc entre autre la création de services proposant juste de l’hébergement de données. Ce sont de tels entrepôts dont les applications Web ouvertes ont besoin. Malheureusement, tout cela reste un peu trop technique, et je ne pense pas que les non-geeks soient prêts à trouver et payer un prestataire d’hébergement de données pour leurs applications. Il faudrait qu’un tel service leur soit fourni clé en main, avec leur connexion.

Or, la plupart des fournisseurs d’accès internet assortissent leur offre de services annexes, comme souvent une adresse de messagerie. Jadis, certains proposaient également l’hébergement de quelques pages Web, d’une site personnel. On pourrait imaginer que demain, quelques fournisseurs de qualité proposent, avec tout abonnement à Internet, un entrepôt en ligne où stocker les données de ses applications Web. Ainsi je pourrais partager sur mon compte FDN les données des applications s’exécutant dans mes Firefox.

Faire héberger nos données par notre FAI n’est bien sûr qu’à moitié satisfaisant. Et je doute que beaucoup de fournisseurs d’accès voient un quelconque intérêt à fournir ce service. L’idée ne me semble néanmoins pas complètement irréaliste.

À vous lire.

Réformisme et terrain de jeu

Une des premières réactions des gens à qui je montre Firefox OS via le simulateur est souvent… la déception. L’interface serait trop inspirée de celle des systèmes mobiles d’Apple ou de Google. Je ne sais pas si cette similitude d’interface est voulue, pour ne pas déboussoler les utilisateurs, ou la conséquence des délais très courts dans lesquels le produit a été conçu. Mais ces remarques m’inspirent deux réflexions.

La première est que nous attendons sans doute trop de Mozilla. Nous avons peut-être trop tendance à imaginer la fondation en révolutionnaire, quand elle n’est que réformiste (au sens respectable du terme). Son maître mot est le pragmatisme. Et, je dois le reconnaître, quoiqu’il m’en coûte, c’est une des principales raisons de son succès : préférer les évolutions douces et le pragmatisme à l’utopie révolutionnaire. C’est la raison par exemple de son choix dès le début d’HTML 5, simple évolution d’HTML 4, plutôt que de la rupture annoncée par XHTML 2 et XForm. Bien sûr, la fondation sait nous faire rêver. Il y a quelques années, ses laboratoires sortaient tous les mois de nouveaux prototypes très innovants, qui faisaient saliver. Mais tous ou presque ont été rapidement abandonnés, au profit d’une évolution continue et en douceur de Firefox. Firefox OS lui-même n’est pas révolutionnaire, bien d’autres avant avaient déjà eu l’idée d’un OS Web. Mais c’est parce que le projet est géré de manière très pragmatique, en essayant d’arriver le plus vite possible sur le marché avec juste les fonctionnalités minimales pour être viable, en se concentrant sur les attentes des utilisateurs, c’est pour cela qu’il a des chances de réussir et de produire un changement profond et durable.

La seconde réflexion est que nous n’avons peut-être pas encore découvert un des intérêts (pour les geeks) de Firefox OS. C’est probablement la maquette de système d’exploitation la plus simple à modifier. On l’a dit et répété, l’ensemble de l’interface utilisateur, l’ensemble des interactions, sont entièrement réalisées en HTML / CSS / JavaScript. Ça en fait donc un terrain de jeu plutôt accessible pour les concepteurs d’interaction qui veulent essayer de nouveaux paradigmes. Vous avez des idées en matière de design, d’ergonomie, de manière d’interagir avec les utilisateurs ? Il suffit pour les tester de connaître les technos du Web, ou d’avoir sous la main quelqu’un qui les connait. La mise à jour de Gaïa, l’interface de Firefox OS, est vraiment des plus simples, pratiquement aussi simple que jouer en direct avec la maquette d’un site Web. C’est une magnifique plate-forme pour imaginer de nouvelles formes d’interactions au niveau, non uniquement d’une application, mais d’un système entier. Et j’espère que des concepteurs vont s’en emparer pour proposer d’autres façons d’utiliser un téléphone.

Synchroniser

Parmi les différentes expériences que j’ai en ce moment sur le feu pour apprendre à développer des applications Web, un petit machin tout simple de prise de notes. Une fois réglé la question du stockage local, je me suis dit qu’il serait pratique, lorsque j’aurai un terminal mobile, de pouvoir récupérer sur ma machine principale les notes saisies dans les transports. Renseignement pris, il n’existe pas encore d’API de synchronisation dans Firefox OS, et ça ne semble pas une priorité, le premier marché visé étant les pays émergents et non les geeks qui jonglent entre plusieurs terminaux. Je réfléchis donc depuis quelques jours à une solution de synchronisation.

L’apprenti geek en moi jouerait bien avec CouchDB, une base de données qui incorpore nativement des fonctionnalités avancées de synchronisation. Mais cela signifierait en avoir une instance sur un serveur et donc devoir administrer sur le long terme ce service. Or je ne veux plus rajouter de trucs sur mon serveur. Surtout, c’est une solution qui réserverait mon application aux boutonneux et boutonneuses dans mon genre, capable d’installer un serveur. Une solution accessible à tout internaute me plairait davantage, surtout si elle évite le piège de dépendre d’un entrepôt central.

Le problème de la synchronisation est qu’à moins de le faire directement entre deux terminaux (bientôt possible avec WebRTC ?), elle demande de passer par une passerelle, et que celle-ci constitue souvent un point de centralisation. Le meilleur exemple est sans doute Google. Pour y remédier, il faudrait que les internautes puissent facilement disposer de leur propre instance de serveur de synchronisation. Je me souviens de projets pour installer facilement des paquets de logiciels, dont le serveur Sync de Mozilla. Mais je crois qu’ils ne sont malheureusement jamais sortis du cercle des boutonneux.

À vrai dire, si l’on cherche un service largement répandu chez des internautes non technophiles, réellement décentralisé, encadré par des spécifications, et qui permet à chacun et chacune de lire et d’écrire des données, je ne vois qu’un seul candidat : la messagerie (éventuellement la messagerie instantanée, à présent que XMPP a pratiquement tout unifié).

Pourquoi ne pas donc utiliser un compte mail comme serveur de synchronisation ? Ou du moins de stockage de données partagées entre plusieurs instances d’une application. L’idée n’est pas neuve, GmailFs par exemple permettait d’utiliser un compte Gmail comme espace de stockage. Tout ce dont l’utilisateur aurait besoin pour synchroniser ses différents terminaux serait une adresse mail.

Si l’idée est simple, la réalisation risque de l’être nettement moins. Pour en arriver là, il faudrait :

  • définir un protocole de communication avec le serveur de messagerie. Ce protocole devrait offrir plusieurs méthodes de connexion. Si le serveur est accessible en IMAP ou POP3 et que l’application a accès à de vrais sockets (comme la TCP Socket API présente dans Firefox OS), les échanges ne poseront pas de problèmes. Sinon, il faudra soit envisager des passerelles (un service Web gérant les échanges IMAP), mais qui réintroduisent un point de passage obligé, soit des connecteurs pour que l’application navigue sur les Webmails et simule une connexion IMAP (sur le modèle par exemple de DavMAIL qui crée un vrai serveur POP/IMAP/SMTP au dessus du Webmail d’Exchange) ;
  • définir un format de stockage des données, et gérer les diverses limitations des services (taille des messages, recherche plus ou moins aisée, etc) ;
  • trouver des algorithmes performants de synchronisation, qui minimisent les échanges réseau. C’est sans doute la partie la plus simple, de telles fonctionnalités étant déjà présentes dans de nombreux logiciels libres ;
  • on peut aussi imaginer un répertoire listant les connecteurs disponibles en fonction de l’adresse de l’utilisateur, et les installant à la demande. Par exemple un utilisateur de FirefoxOS utilisant une adresse GMail pourrait utiliser un connecteur IMAP natif, quand le possesseur d’une adresse hotmail devrait passer par une surcouche du Webmail (le tout de manière évidemment transparente).

J’ai cette idée en tête depuis quelques jours, et sa mise en œuvre est très largement au dessus de mes compétences et de mes disponibilités. J’en jette donc le brouillon ici pour voir ce qu’elle vous inspire.

Fork me on GitHub