Je ne doute pas que Dunipod soit plus avancé que mon “datapod”, et sûrement plus adapté pour les applications liées à la Ǧ1, mais il y a quelques propriétés que je vise qui me semblent incompatibles avec l’approche Dunipod :
- “local first” : l’indexeur doit fonctionner hors ligne ou en réseau local et supporter une connexion asynchrone (la connexion au reste du réseau n’a pas nécessairement lieu au moment où l’utilisateur utilise l’appli)
- “p2p” : les applis “client” intègrent l’indexeur à l’intérieur et peuvent se suffire à elles mêmes, il n’y a pas de distinction client/serveur, seulement des rôles sur le réseau pour les machines en ligne h24
- indépendance d’une blockchain : n’importe qui peut soumettre de la donnée en local sans compte sur blockchain, sans tokens, sans frais, sans autorisation, sans création de compte préalable. Chaque indexeur choisit ses critères d’indexation pour l’acceptation d’un fait et l’indexation d’une donnée.
- fork social / fédération mycélienne : c’est le concept qu’il faudrait que je détaille parce que c’est le plus nouveau, mais en gros si un groupe de personnes se mettent d’accord sur des règles, le protocole de synchronisation et indexation des faits doit les mener à un état convergent, et si un groupe entre en désaccord sur les règles, le fork doit se faire sans nécessité de consensus sur la copie “légitime”, les branches doivent pouvoir continuer à avancer en parallèle le temps que durera le désaccord.
Concernant la Ğ1 et Ğchange, ça me paraît évidemment mieux de passer par Dunipod, il ne reste plus qu’à recoder une appli basée sur une API Dunipod (et même avec un light node dans le meilleur des mondes). Mais pour mes applications hors Ǧ1, je compte continuer à explorer dans ma direction pour voir où ça me mène.
plusieurs raisons que je ne vais pas détailler ici [sauf] s’il y a une demande pour
Je suis preneur de tous ces détails, ça aide à identifier tôt les points clés de conception.