Merci pour tes retours, c’est le bon moment avant que je m’enfonce trop profond dans des choix problématiques ! En plus ça m’aide à détailler des choix, ce que je remettais sans cesse à plus tard.
noeud qui tourne
Je mets tout en oeuvre pour y arriver le plus vite possible, d’ici la fin de la semaine j’espère, pour pouvoir avoir des retours sur cas concrets.
pubkeyetaddress
J’étais parti pour pubkey parce c’est agnostique du réseau et que ça évite de changer les données à la migration (donc les données de phase de test avec le préfixe d’adresse “42” sont compatibles avec le réseau de prod sans avoir à adapter). Mais en fait, tu as raison, je pourrais partir sur address, ça change pas grand chose.
éviter les trucs pas clair comme
pubk
C’était plus clair pour moi en phase de test, mais c’est le genre de trucs sur lesquels on peut se mettre d’accord à un moment donné, c’est assez facile à changer. J’utilise un modèle dag-cbor (similaire à dag-json) et à terme on pourrait plutôt se tourner vers un format plus “fortement typé” et compact comme dag-pb ou même dag-scale si on est fous ><
Ajouter aux documents (demande d’indexation, profiles, etc.) l’attribut
version(number).
J’ai beaucoup réfléchi à ça et j’aimerais bien en discuter plus avec toi. Actuellement j’ai un argument “kind” qui peut justement servir à ça : cesium profile v1, cesium profile v2, cesium profile delete, transaction comment… On peut tout mettre dedans comme c’est un CID.
Le seul intérêt que je vois à mettre un champ “version” qui est un entier numéroté est que c’est plus compact (on peut aller jusqu’à 8 bits si on prévoit de pas dépasser 256 numéros, contre 256 bits pour un CID). Mais :
- l’utilisation d’un CID permet d’éliminer le besoin de se coordonner pour ajouter des formats, n’importe qui peut ajouter un format sans consulter personne et le collecteur fonctionnera toujours, on peut même s’en servir pour des références (pointeurs) plutôt qu’une simple énumération, à la manière du NIP-27 de Nostr.
- alors qu’un numéro de version est implicite, le CID peut être explicite, donner des informations sur le format qu’il décrit, et pointer vers une documentation. Tout est contenu dans ce “kind”.
Donc en gros, c’est plus extensible de se baser sur un kind. On pourra se mettre d’accord entre nous sur des kinds communs, mais si des gens développent un plugin wordpress qui a besoin de données offchain, ils pourront développer leur propre kind sans nous consulter, mais en utilisant le même système de données. Pareil si des gens développent un bot qui bridge telegram et la Ğ1 pour afficher le profil telegram directement dans une appli Ğ1, pas besoin de passer par nous et “réserver” un numéro de version.
Conserver les documents JSON issue de la V1 dans un sous-objet dag (avec son propre cid) par exemple
raw(ou alorspreviouspour pointer vers l’ancien document en version 2)
Il y a un truc qui me gène à faire ça : on stocke donc deux fois l’avatar :
- une fois comme un fichier unixfs ipfs
- une fois comme un base64
Ça m’aurait pas posé problème de stocker uniquement le json brut s’il n’y avait que la partie données, mais avec l’image c’est un peu lourd, et d’après ce que j’ai compris la signature porte sur l’image en entier et pas uniquement son hash, donc pas moyen de s’en passer et de conserver la signature valide. Pour récupérer les données, j’ai utilisé le script de poka.
Si le but et est de faire un indexeur elasticsearch qui ré-indexe des documents bruts, la bonne manière de faire à mon avis est de reconstruire des documents json à partir du dag du document archivé.
En fait j’ai deux “kind” différents pour les profils C+ : /src/consts.ts#L19-L22. L’un est pour les profils importés pour lesquels la demande d’indexation (IndexRequest) contient une signature vide (""), et le profil entier est stocké en tant que donnée, au détail près de la photo de profil qui est stockée dans un objet IPFS à part. La raison de ce choix est que pour moi, les images et documents “lourds” et non structurés devraient être servis via IPFS, et non via un indexeur. Pour moi, une base de données (Postgres ou autre) n’est pas faite pour stocker des byte array dans lesquels aucune recherche ne sera faite.
J’aimerais que tu détailles le besoin de conserver les profils “legacy” au format raw parce que ça me semble être juste un effet de bord du “genesis” de la blockchain des Datapods IPFS. Donc perdre la vérifiabilité individuelle des données n’a pas de conséquences : une fois qu’on a vérifié que le hash du genesis provenait effectivement de l’ensemble des données C+ authentiques, plus besoin de vérifier chaque donné individuellement.