Dans 99 % des cas, l’utilisateur veut faire quelque chose qui implique des données fraîches, que ce soit rechercher un profil pour faire un transfert ou envoyer un message, ou encore chercher une annonce ou y répondre.
Les cas du type « je veux récupérer les données puis les consulter hors ligne » me semblent très minoritaires et correspondent davantage à un usage de niche.
Il est toutefois tout à fait possible de suppporter ce cas de niche à l’avenir dans dunipod avec un dunipod-light que je mentionne au point suivant.
C’est justement plutôt un inconvénient de mon point de vue. Cela impose un client lourd, qui doit effectuer beaucoup de choses localement, ce qui ne me semble pas très compatible avec un usage sur un mobile modeste (davantage de travail côté client) et/ou avec une connexion limitée, ce qui est souvent le cas en mobilité.
Je préfère donc un modèle « client léger first ». Cela ne m’empêche pas, à terme, de faire une version dunipod-light de Dunipod qui compile en WASM et se comporte localement comme un nœud Dunipod P2P si c’est souhaité. Rien ne l’empêche techniquement ; ce n’est simplement pas ma priorité actuellement.
Plus profondément, je ne vois pas très bien en quoi cette approche apporte davantage de décentralisation réelle. Je comprends qu’elle puisse paraître plus décentralisée en apparence, mais le client a toujours besoin de faire confiance à d’autres pods auxquels il s’abonne, à moins de récupérer toutes les données du réseau pour toutes les réindexer lui-même.
Or, il ne me semble pas réaliste de faire cela sur le mobile ou l’ordinateur de chaque utilisateur. En pratique, on retombe donc sur la nécessité de faire confiance à d’autres pods pour pré-indexer certaines données.
C’est déjà le cas dans Dunipod. N’importe qui peut soumettre des données off-chain à un pod Dunipod, tant que ces données respectent les règles du pod, qui sont personnalisables pour chaque pod.
Par défaut, le protocole exige uniquement une signature Ed25519, mais il n’est pas nécessaire qu’elle corresponde à un compte Ğ1 on-chain. Certaines règles peuvent l’exiger dans certains cas plus consommateurs en données, ou simplement appliquer des quotas différents selon que le compte existe ou non.
Dans Dunipod également, chaque indexeur choisit ses propres critères d’indexation pour l’acceptation d’un fait et l’indexation d’une donnée.
Là aussi, c’est déjà le cas dans Dunipod. Le protocole P2P de Dunipod est agnostique vis-à-vis des règles spécifiques à chaque pod et partage tous les documents des domaines suivis, même lorsque les pods appliquent des règles différentes.
Les règles d’indexation des données off-chain sont déterministes, et je vérifie notamment que deux pods qui choisissent les mêmes règles convergent vers le même état. Un pod peut également forker ses règles off-chain sans nécessiter de consensus sur une copie « légitime », puisqu’il n’existe justement pas de copie légitime globale.
Dunipod fonctionne bien sans consensus global et sans blockchain pour les données off-chain. L’indexeur on-chain sert uniquement à fournir, de manière déterministe, des données sur lesquelles les règles off-chain peuvent choisir de s’appuyer, avec la garantie, apportée par le protocole, de l’accessibilité des données nécessaires à l’application de ces règles.
Cela implique effectivement que le protocole générique soit « aware » des données on-chain dont les règles peuvent avoir besoin.
Au final, il me semble avoir déjà retenu et intégré dans Dunipod la plupart des bonnes idées que tu évoques, même si leur mise en œuvre ou l’architecture choisie diffèrent parfois.
Je te remercie en tout cas pour ces réflexions et ces propositions. Je reste bien sûr ouvert à toute suggestion d’amélioration, ainsi qu’à l’intégration de nouvelles idées 