Sommaire
Cher journal,
Aujourd'hui, j'aimerais te présenter mon dernier projet, Domovik : un serveur de synchronisation pluri-navigateurs que j'ai développé durant ces derniers mois.
Pourquoi Domovik ?
Pour des raisons tant personnelles que professionnelles, j'utilise régulièrement plusieurs navigateurs répartis sur plusieurs machines, ce qui fragmente d'autant ma navigation : me souvenir sur lequel d'entre eux j'ai ouvert telle vidéo ou sauvegardé tel article est une source de tracas sans fin. « Allons donc », me direz-vous, « pourquoi diable ne pas simplement utiliser les services de synchronisation fournis par les éditeurs desdits navigateurs ? » Juste question, dont la réponse est double : d'une part, je ne tiens pas nécessairement à confier toutes mes données de navigation à des entités aux allégeances hasardeuses ; mais, et surtout, utilisant régulièrement Firefox, Vivaldi et Qutebrowser (et d'autres plus occasionnellement), aucun de ces services n'est compatible avec ce panel.
J'ai donc développé Domovik ces deux dernières années pour combler ce manque, et le confinement m'a offert le temps nécessaire pour en finaliser une première version de qualité suffisante (j'espère ?) pour l'ouvrir au public. Domovik se présente sous la forme de deux (pour le moment) logiciels : d'une part le serveur de synchronisation, d'autre part l'extension pour navigateur (actuellement disponible pour Firefox/Edge/Chrom{ium,e} et ses dérivés) ; la seconde s'accordant avec le premier pour y synchroniser les données des navigateurs sur lesquels elle est installée.
Fonctionnalités
Domovik étant avant tout développé autour de ma propre utilisation, il s'articule autour des quatre fonctions dont je ressentais particulièrement le besoin.
Onglets
La fonction clef qui m'a poussé au développement de Domovik est la synchronisation des onglets : je voulais accéder à tous les onglets de tous mes navigateurs depuis n'importe lequel d'entre eux – notamment parce que j'oublie régulièrement des pages très intéressantes sur le PC du labo, de préférence le vendredi soir. L'extension Domovik communique donc depuis le navigateur avec le serveur pour y répliquer la liste des onglets ouverts. Ceux-ci sont accessibles soit (i) directement depuis l'interface web du serveur, soit (ii) par l'extension, qui remplace la page nouvel onglet du navigateur avec un tableau de bord – une version de l'extension qui ne remplace pas celle-ci, Domovik Lite, est aussi disponible.
Favoris
La synchronisation des favoris découle naturellement de celle des onglets. Les favoris des navigateurs synchronisés sont accessibles soit depuis l'interface web du serveur, soit (comme les onglets) au travers de toute requête commençant par dom dans la barre d'URL – du moins pour les navigateurs supportant cette fonctionnalité des WebExtensions (méchant Vivaldi).
Listes de lecture
Les listes de lecture répondent à un besoin de favoris thématiques volatiles. Ces listes sont donc des listes de liens, dont la subtilité est qu'ouvrir l'un d'entre eux l'en ôte. Je les utilise avant tout pour organiser des listes de pages à lire dans un futur proche, mais dont le caractère ne justifie pas une inscription dans le marbre des favoris. Elles constituent donc une sorte de limbes entre mes barres d'onglets (par trop chargées) et mes favoris (poussiéreux). J'y range les liens relatifs à un sujet à creuser lorsque j'en aurai le temps, à des projets temporairement inactifs, etc. On y épingle une page depuis un bouton dans la barre d'outils du navigateur, et on la retrouve soit dans l'interface web du serveur, soit, par l'extension, sur la page nouvel onglet.
Partage
Enfin, las de m'envoyer par mail des liens divers et variés pour les passer d'un OS ou d'une machine à l'autre, l'extension Domovik rajoute une entrée au menu contextuel des pages web et des liens qu'elles contiennent pour envoyer ladite URL à un autre des navigateurs connectés, qui ouvrira celui-ci a la première occasion. C'est idiot, mais fichtrement pratique.
Chiffrement
Les données de navigation sont bien évidemment extrêmement intimes. Domovik utilise du chiffrement bout en bout pour toutes ces informations, et le serveur ne voit donc transiter que des flux chiffrés. L'on fait ainsi d'une pierre deux coups : les utilisateurs sont non seulement protégés d'un hébergeur par trop indélicat, mais aussi d'un putatif accès frauduleux à la base de données du serveur. La mise en œuvre est assez simple : le mot de passe de l'utilisateur est en fait une phrase de passe, de laquelle est dérivée, de façon totalement transparente, et le mot de passe d'accès au site web, et la clef de chiffrement des donnees. Avantage : c'est simple à développer et à utiliser ; inconvénient : la perte ou la modification du mot de passe implique la perte de toutes les données, alors indéchiffrables.
Infrastructure logicielle
Serveur
Le critère de choix des technologies de développement de Domovik fut extrêmement subjectif et se résuma à : « n'importe, pourvu que ça me plaise ». Le serveur est développé autour de Phoenix, un cadriciel web écrit en Elixir qui tourne sur OTP, la plateforme d'exécution développée pour Erlang. Outre ses qualités en tant qu'environnement de développement, l'ensemble offre de très bonnes performances pour une empreinte mémoire et processeur finalement modeste, ce qui ne gâte rien – et en plus, elle semble avoir d'excellentes capacités de passage à l'échelle, ce qui n'est pas très utile mais permet de fanfaronner un brin.
Le frontend des premières versions étaient en HTML/CSS purs, mais le choix d'ajouter le chiffrement bout en bout nécessita l'addition de quelques touches de JS pour déchiffrer les données retournées par le serveur. La complexité de ces fragment étant modeste, ils sont écrits en JS vanilla, la seule finesse venant de l'utilisation de Webpack pour la compilation des feuilles de style SASS, l'assemblage des divers fichiers JS et la compression du tout.
Pour l'environnement système, rien que de très commun : une base de données PostgreSQL et un proxy nginx. Ce dernier n'est pas nécessaire stricto sensu, mais comme je l'ai de toute façon pour relayer d'autres logiciels, l'occasion fait le larron. Enfin, en ce qui concerne la méthode de déploiement, c'est pour l'instant un simple cocktail à base de git et de scripts shell. Ceci dit, je suis en train de travailler à l'écriture d'un paquet Nix, ce qui permettra à tout un chacun de déployer l'ensemble bien plus sûrement et confortablement.
Extension
Grâce a la généralisation du standard des WebExtensions (ça coince encore un peu aux entournures, mais il faut savoir s'en satisfaire), développer une extension commune aux deux grands (Gecko et Blink, et même bientôt Safari) – et donc à leurs cousins (Vivaldi, Edge, Brave, …) – est relativement aisé. Les particularités propres aux uns ou aux autres sont palliées par l'utilisation de polyfills et autres artifices lors du processus de compilation.
L'extension fut d'abord développée en JS brut, puis très rapidement convertie en TypeScript quand le seuil de ma tolérance aux idiotismes de JS fut dépassée. L'on sent TypeScript limité dans ses ambitions par la rétrocompatibilité qu'il s'impose avec JS, mais il n'en demeure pas moins un indubitable plus, notamment grâce à son système de types.
Perspectives
J'ai bien entendu déjà une kyrielle d'idées pour poursuivre le développement plus avant. Pour rester sur les principales, la priorité sera donnée au développement d'applications mobiles : en effet, les navigateurs mobiles ne supportent pas les extensions – et Dieu sait que j'y ai pourtant bien des onglets à partager. Le seul moyen de les connecter à Domovik sera donc de passer par les systèmes d'échange inter-applications d'Android et iOS, ce qui requiert des applications idoines.
Ensuite, lorsque l'API sera stabilisée, je fournirai une définition OpenAPI, pour que les utilisateurs puissent facilement développer leur propres idées (à quand Domovik dans Emacs ?) – et en corollaire, l'interfacer avec des navigateurs tels que Qutebrowser ou Nyxt qui, faute de supporter les WebExtensions, offrent leur propre système d'extension.
Enfin, une API stable sera une première étape dans le développement d'un client en ligne de commande qui présenterait le système sous un jour plus enclin à l'intégration dans d'autres logiciels qu'une API web (pipes vs. requêtes HTTP).
Conclusion
Nous sommes entre libristes barbus, le logiciel est donc bien entendu libre : AGPLv3 pour le serveur et GPLv3 pour l'extension ; le tout est léger et nécessite peu de dépendances, ce qui le rend assez facilement auto-hébergeable. Bien entendu, toute question, suggestion, inévitable rapport de bug, etc. est le bienvenu ici ou sur Github. Enfin, si vous souhaitez soutenir le projet, un hébergement payant est disponible. Merci de m'avoir lu jusqu'ici, et bonne prochaine période de 12 heures !
# Merci !
Posté par tisaac (Mastodon) . Évalué à 10.
Merci pour ce beau projet et ce texte très intéressant.
Pour rappel
Ton journal aurait eu toute sa légitimité comme dépêche.
L'intérêt d'une dépêche c'est que l'équipe de modération de LinuxFR t'offre gratuitement une relecture bienveillante et que visiblement la page des dépêches est plus visitées que celle des journaux.
Seul éventuel inconvénient, la relecture par la modération prend un peu de temps (mais pas tellement).
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Merci !
Posté par orfenor . Évalué à 8.
La modération a aussi le pouvois de transformer des journaux en dépêches. Celui-ci le mérite amplement !
[^] # Re: Merci !
Posté par tisaac (Mastodon) . Évalué à 2.
Je pense qu'il est souhaitable de minimiser le fait de transformer les journaux en dépêches:
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Merci !
Posté par orfenor . Évalué à 2.
Comme tu n'es pas modérateur, mieux vaut solliciter leur avis plutôt qu'émettre des hypothèses. Si j'ai bien retenu la conférence du sieur Sibaud, linuxfr c'est des infos sur le libre — donc des dépêches — les journaux étant un fouillis dévolu à tout le reste de ce qui nous passe par la tête. Passer des journaux en dépêche c'est arrivé très souvent.
Petite chose amusante, tu viens d'écrire implicitement qu'il ne faut plus envoyer des dépêche parce que la modération a trop de travail :-) Si la modération a du travail c'est tant mieux, ça prouve que ça tourne !
[^] # Re: Merci !
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
cf https://linuxfr.org/proposer-un-contenu
(plus les différences sur la modération a priori/a posteriori, la rédaction collaborative, etc.)
Le lectorat des dépêches (directement sur le site ou via les flux Atom ou par courriel ou via les reprises ailleurs ou …) est plus large que le lectorat des journaux.
Exceptions :
Exemples :
[^] # Re: Merci !
Posté par lockidor . Évalué à 1.
Donc il faudrait mieux que je supprime le journal et que je le reposte en dépêche ?
[^] # Re: Merci !
Posté par orfenor . Évalué à 3.
Pas besoin, demande à l'équipe de modération de le transformer en dépêche.
[^] # Re: Merci !
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 03 mai 2021 à 19:11.
Alors, on ne peut pas supprimer soi-même un journal, il faut demander à quelqu'un de l'équipe de modération. Et, comme le fait remarquer Tisaac plus bas, ça fait deux contenus : la dépêche et le journal. Puisque de toute façon le journal, et ses commentaires, reste.
Mais effectivement, je suggère, comme l'a fait deuzenne, de voir un peu avant de prendre une décision dans un sens ou un autre.
Soit dit en passant, tu peux aussi faire une dépêche sur ce sujet mais enrichie (par exemple).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Merci !
Posté par tisaac (Mastodon) . Évalué à 7. Dernière modification le 03 mai 2021 à 18:13.
Je n'ai pas émis d'hypothèses, j'ai donné mon avis. Et je me permets de le faire parfois sans demander l'avis de l'équipe de modération ;-)
Non, je n'ai pas écrit cela même pas implicitement.
Quand un journal est promu en dépêche, il y a des étapes supplémentaires pour l'équipe de linuxfr par rapport au simple fait de publier directement une dépêche. Et cela constitue un surplus de travail qui ne me semble pas avoir d'intérêt. C'est le travail inutile que je souhaite réduire.
Mon désamour des transformations de journaux en dépêches provient aussi du fait que cela me donne plus de travail quand j'essaie de faire le ménage dans l'espace de rédaction.
Finalement, mon désamour de ces transformations est aussi comme tu as pu le lire, que pour le lecteur que je suis, je trouve pénible d'avoir le texte à deux endroits du site avec des fils de discussions différents.
Donc, je maintiens, qu'à mon humble avis, il vaut mieux inciter chacun à publier directement sous la forme la plus adéquate à ses yeux et compte tenu de la politique éditoriale du site plutôt que de compter sur l'équipe de linuxfr pour passer des journaux en dépêches.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Merci !
Posté par lockidor . Évalué à 4.
J'avoue que j'ai hésité, mais comme il y avait un peu d'auto-promotion à la fin, je n'ai pas voulu embarrasser la modération avec.
[^] # Re: Merci !
Posté par legranblon (site web personnel) . Évalué à 3.
mauvais prétexte.
Je trouve pertinent ton commentaire, car il nous expose ton point de vue, cependant, tu ne devrais pas t'arrêter là pour celà.
[^] # Re: Merci !
Posté par tisaac (Mastodon) . Évalué à 5.
Il me semble que tant que cela reste dans des proportions raisonnables (mais qu'est-ce donc des proportions raisonnables ?), l'auto-promotion a toujours été bien accueillie/acceptée sur linuxfr y compris dans les dépêches.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Merci !
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
On n'a rien contre les gens qui font de l'auto-promotion, tant que ça n'est pas de la vulgaire pub et que la rédaction ne fait pas trop communiqué de presse. De l'auto-promotion avec du vrai contenu et dans le thème du site pour les dépêches, tout à fait.
Ce qui nous embarrasse c'est plutôt quand ça fait trop communiqué de presse et évidemment, si on ne trouve pas le lien avec avec le logiciel libre, que c'est mal ou pas structuré, qu'il manque une véritable intro ou des trucs comme ça (et aussi quand la première image d'illustration est trop grande, soit dit en passant).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Big Up
Posté par saltimbanque (site web personnel) . Évalué à 7.
Joli projet!
Effectivement d'autres que toi partageront de ne pas trop vouloir confier ses données Mozilla Google ou autre, et/ou d'utiliser plusieurs navigateurs. J'imagine donc que tu trouverai des utilisateurs prêts à payer pour un hébergement du service, car tout le monde n'a pas son VPS ou rasberry.
Sur les favoris jusqu'ici j'ai buté sur trouver un service qui proposait de mettre du commentaire pour se constituer une vraie bibliothèque de favoris documentée, pas une liste que je n'arriverai plus à utiliser dans 2 mois car je ne m'y retrouverai pas. Mais je n'ai pas fini de tester chacun des candidats que l'auteur connait certainement https://github.com/awesome-selfhosted/awesome-selfhosted#bookmarks-and-link-sharing
[^] # Re: Big Up
Posté par saltimbanque (site web personnel) . Évalué à 5.
edit : on dirait que https://www.xbrowsersync.org/ ressemble un peu - hélas là je n'ai plus le temps de lire
# Intéressant
Posté par Mimoza . Évalué à 4.
C'est clairement quelque chose qui m'intéresse car me serait bien utile.
Il faut que je regarde si sur mon serveur OpenBSD le serveur peut tourner.
J'ai vue sur ton site qu'il y a une offre commerciale, un petit mot dessus aurait été accepté je pense, on sais bien que l'on ne vie pas que d'amour et de ligne de code ;-)
[^] # Re: Intéressant
Posté par lockidor . Évalué à 1.
J'ai essayé sur Free, mais pas sur Open. Ceci étant, Elixir et PostgreSQL tournent tous les deux sur OpenBSD, donc théoriquement ça devrait passer crème.
Je l'ai mentionné en passant à la fin ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.