- Earthstar est une spécification de données et une bibliothèque JavaScript pour créer des applications distribuées privées possédées et exploitées directement par leurs utilisateurs
- La nouvelle spécification Earthstar repose désormais sur Willow, et Earthstar v11 est actuellement disponible en bêta
- Les applications sont conçues pour fonctionner hors ligne par défaut, tout en prenant en charge la synchronisation en direct, les documents temporaires, la suppression réelle et le stockage de musique, photos et vidéos
- Les serveurs sont optionnels, mais le mode d’exploitation est toujours auto-hébergé, sans dépendre d’une blockchain ni de tokens
- Fonctionne dans le navigateur, avec Deno et Node, et fournit la vérification ed25519, l’accès en lecture seule, la synchronisation en streaming, ainsi que la prise en charge de plusieurs auteurs et de pilotes de stockage
Rôle actuel et état d’Earthstar
- Earthstar est une spécification à vocation de base de données et une bibliothèque JavaScript pour créer des applications appartenant aux utilisateurs
- La nouvelle spécification Earthstar repose sur Willow
- Earthstar v11 est actuellement proposé en version bêta
- La documentation, l’API JavaScript, la spécification et un tutoriel d’application de chat sont proposés comme principaux points d’entrée
Fonctionnalités pour des applications offline-first
-
Fonctionnalités applicatives
- Prend en charge le fonctionnement hors ligne
- Prend en charge la synchronisation en direct et l’approche Sneakernet
- Permet de stocker musique, photos et vidéos
- Prend en charge les documents temporaires et la suppression réelle des données
- Permet d’utiliser une ou plusieurs identités (identity)
-
Modèle d’exploitation
- Les serveurs sont optionnels
- Le mode d’exploitation est toujours auto-hébergé
- N’utilise ni blockchain ni token
- Revendique d’être « gratuit pour toujours, dans tous les sens du terme »
-
Fonctionnalités techniques
- Prend en charge la vérification ed25519
- Fonctionne dans le navigateur, avec Deno et Node
- Peut accorder un accès en lecture seule
- Prend en charge la synchronisation efficace et la synchronisation en streaming
- Permet d’utiliser une même identité sur plusieurs appareils
- Prend en charge plusieurs auteurs, des pilotes de stockage et les permissions d’écriture de documents
1 commentaires
Avis sur Hacker News
C’est un peu similaire à nostr, mais avec des différences. Les données ne sont pas adressées par contenu, elles sont basées sur des noms, ce qui permet l’écrasement et la suppression, et le type de données brut n’est pas non plus un ensemble de messages, mais un tableau associatif allant des noms vers des documents.
Les documents sont regroupés en « shares », et pour qu’un serveur reconnaisse qu’il possède les documents d’un share donné, il doit d’abord connaître la « share address ». L’approche où certains accès sont privés et d’autres publics est intéressante ; les projets qui choisissent un extrême sur cet axe ont généralement du mal, et je pense que c’est le cas de la plupart d’entre eux.
Ça devrait réussir à bloquer les spammeurs et les escrocs, mais je serais prudent pour de grands groupes face à des attaquants motivés. Si un utilisateur expose une share address qui se trouve dans une zone ambiguë entre public et privé, il semble que tous les utilisateurs de ce share soient révélés.
Un web of trust, où un attaquant devrait percer chaque saut du graphe de confiance avant de trouver sa cible, serait préférable, mais cela augmente la complexité à gérer pour l’utilisateur ; je comprends donc aussi pourquoi on sacrifie la granularité au profit de la simplicité. J’espère que ce genre de projet réussira : j’ai l’impression que nous avons perdu le Web, et sans quelque chose qui ressemble au Web, il sera difficile pour beaucoup de gens de se coordonner à grande échelle aux moments importants.
Une share address devrait être traitée comme une clé ssh.
Je ne sais pas exactement ce que c’est.
Une sorte de base de données de documents et de médias avec beaucoup de JavaScript ? Un peu orientée auto-hébergement, avec réplication vers des nœuds pairs façon Mastodon ? Il semble y avoir une grande vision, mais elle n’est pas très lisible.
Je ne sais pas ce qu’apporte la décentralisation d’Earthstar. Si c’est pour les sauvegardes, c’est déjà assez simple avec SQLite et PGlite. Je ne vois pas bien si cela représente un gros avantage pour la plupart des utilisateurs de bases de données.
Cela semble utile pour les personnes qui veulent stocker leurs données sur leurs propres appareils, les partager avec d’autres particuliers, et que ceux-ci disposent aussi d’une copie locale. Peut-être aussi pour le partage illégal de contenus.
Il y a clairement des fonctionnalités intéressantes, mais la vision semble se perdre dans l’énumération des fonctionnalités.
Je considère que cela a été remplacé par le protocole Willow [0], déjà présenté ici auparavant.
J’ai essayé de lire Willow, mais je n’ai vraiment pas réussi à en saisir l’idée [1]. On dirait un stockage clé-valeur hiérarchique avec une foule de champs supplémentaires pour les timestamps et les jetons cryptographiques, mais il manque beaucoup trop d’exemples de fonctionnement.
Même la bibliothèque Rust récente [2] est en pratique un ensemble de classes abstraites, avec une implémentation qui se contente de lancer des erreurs. Je pourrais faire une blague sur l’état du raffinement technologique européen, mais je vais me contenter d’un sourire poli.
[0] https://willowprotocol.org/earthstar/spec/
[1] https://willowprotocol.org/specs/data-model/index.html#data_...
[2] https://github.com/earthstar-project/willow-rs/tree/main
[1] https://nlnet.nl/project/current.html
[2] https://nlnet.nl/funding.html
Si l’on jugeait la qualité des logiciels produits dans la Silicon Valley à partir des projets financés par des VC qui n’ont pas réussi, on n’en finirait pas.
Les personnes derrière Willow semblent aussi être la même équipe : https://earthstar-project.org/docs/future#willow-protocol
https://willowprotocol.org/more/compare/index.html#compare_e...« Les fonctionnalités ci-dessus deviennent toutes possibles grâce au nouveau Willow General Purpose Sync Protocol sur lequel nous travaillons. C’est un nouveau protocole inspiré d’Earthstar, qui en affine et étend les concepts. Nous publierons un nouveau site web avec la spécification complète de ce protocole. »
« Si Earthstar vous semble très similaire à Willow, ce n’est pas un hasard. Willow a commencé comme une réinvention d’Earthstar ; les futures versions d’Earthstar seront construites sur Willow, et le principal mainteneur d’Earthstar est l’un des deux auteurs de Willow. »
Existe-t-il un client Python ? Dans la documentation, la seule chose qui semble liée à Python est ceci :
# Earthstar timestamps in pythontimestamp = int(time.time() * 1000 * 1000)À la rigueur, je recommanderais jellyfin, immich, et pour le reste simplement sftp. La synchronisation — non, la décentralisation — peut se faire avec git, syncthing, rsync.
Je n’ai pas encore vu de bon gestionnaire d’identité auto-hébergé, ni de SSO du même genre. Je crois que bluesky en prépare un, mais je ne sais pas s’il pourra être auto-hébergé. L’autocomplétion, de façon très freudienne, a remplacé par self hostage.
Un autre problème que je n’ai pas encore résolu dans un homelab/cloud privé, c’est comment devenir soi-même une CA et gérer l’accès à mes machines sans apprendre ssh à l’autre personne.
Je veux quelque chose comme meshnet de NordVPN, où les personnes connectées au forfait familial peuvent voir les machines des autres comme sur un réseau local. Est-ce possible avec wireguard ? yggdrasil semble aussi faire ce genre de chose, mais je ne l’ai pas encore examiné en profondeur.
Par « bonne » gestion d’identité, tu veux dire autre chose qu’OpenLDAP ou 389 ? Si l’on tient aussi compte de Windows, je ne sais pas à quel point ça convient.
Devenir sa propre CA est facile, mais la partie pénible est d’installer cette CA sur toutes les machines voulues. Avec Let’s Encrypt, tout fonctionne bien.
Wireguard peut relier deux LAN via Internet, mais c’est mieux d’avoir à chaque extrémité deux routeurs compatibles wireguard, comme pfsense. Sinon, il faut installer une configuration de routage spéciale sur chaque machine cliente. Je n’ai pas encore trouvé comment faire passer avahi pour la découverte automatique de l’autre côté du lien.
Je regrette encore qu’on ait rejoint la fête SQLite seulement après que les navigateurs ont abandonné sa prise en charge.
Un billet de blog serait vraiment utile pour ça. Par exemple, expliquer pourquoi cette conception a été choisie, quelles étaient les alternatives, etc.
À première vue, c’est intéressant. J’aime aussi le fait que l’identité soit une paire de clés, et que les fichiers et les contenus soient accessibles par nom.
Y a-t-il une chance que ce soit implémenté dans d’autres langages, comme Python ? Tout me plaît, sauf le fait que ce soit du JavaScript, et je reste encore prudent à l’idée d’utiliser JavaScript pour ce genre d’usage.
Malheureusement, aucun des deux n’est très populaire, donc on finit par demander des implémentations dans plusieurs langages, ce qui risque d’être une charge pour les mainteneurs de ce type de projet. Quoi qu’il en soit, c’est la réalité, et si ce n’est pas fait avec ce genre de langage, je serais aussi intéressé par une bibliothèque cliente Python.
« Toujours auto-hébergé. Serveur facultatif. Pas de blockchain. Pas de token. Gratuit pour toujours, dans tous les sens du terme. »
C’est le meilleur résumé de thèse possible.