J’ai l’impression que tu as beaucoup utilisé l’IA pour rédiger ta réponse. Je trouve que ça nuit à la compréhension de tes idées. D’autre part, c’est proscrit sur ce forum : un message rédigé par IA même partiellement doit être signalé comme tel.
J’ai quand même fait abstraction de la forme pour m’intéresser au fond. Merci de détailler ta vision du local first, ça me permet de me mieux comprendre ta vision pour Dunipod.
Local first or local later maybe?
Première remarque tout d’abord : le local first est une expérimentation qu’il me plaît de mener, et il me semble plus facile de concevoir un système local first d’abord puis de l’exposer sous forme de passerelle graphql ou autre (le serveur est alors simplement un pod du réseau avec ses propres quotas et règles) que l’inverse. Même si tu affirmes que c’est théoriquement possible de faire dans ce sens :
ça me paraît plus complexe et moins élégant. J’ai peur qu’on finisse par ne pas le faire (comme des clients avec un duniter light node), ou qu’on se retrouve avec un système pas tout à fait adapté au local first. Ma philosophie est plutôt “local first, server then” que “light client first, full p2p eventually”.
Corpus commun ou scission possible ?
Existe-t-il un mécanisme de filtre par clé publique par exemple ? Comment Dunipod se protège-t-il contre quelqu’un qui créerait d’immenses quantités de documents à partir d’une immense quantité de clés différentes ? À partir du moment où il est possible d’exclure une clé, je ne vois pas comment on peut garantir la convergence. Par exemple si Fred publie des milliards de messages sur des milliards de clés différentes avec Astroport, comment Dunipod peut-il garder une référence sur tous ces documents ?
Un ensemble qui ne fait que grandir c’est justement ce que je souhaite éviter. Je veux qu’il soit possible de supprimer en masse des documents signés du corpus sur un critère simple comme la clé publique par exemple. Je me doute que tu as pensé à ça, mais je n’arrive pas à concevoir comment si le corpus synchronise le diff des documents signés sans critère sur la clé.
La seule chose que j’arrive à imaginer, c’est si on n’accepte la connexion p2p que des pairs dont on sait qu’ils pratiquent un quota au niveau de leur API HTTP de soumission. Si un pair forge un corpus gigantesque et qu’on se connecte à lui, le protocole forcera la synchronisation de ses documents signés et saturera notre quota disque en attendant que l’epoch soit passée. Donc il faut que le mécanisme d’appariement soit sur whitelist et pas ouvert. Dans l’idée ça me va.
Fonctionnement avec connexion intermittente
Je ne comprends pas pourquoi tu dis ça. Les connexions intermittentes, qu’elles soient liées au réseau ou à l’OS sont justement la cible. Quand l’appli retrouve une connexion réseau, elle synchronise l’index qui lui manque. La synchro peut être revalidante ou faire confiance au pair, ce qu’on préférera sur smartphone.