Je me pose à nouveau cette question. On pourrait laisser le client choisir ce qu’il veut mettre et le datapod choisir s’il en tient compte. Tout ce qui compte dans le cas de documents signés c’est qu’on puisse vérifier la signature, donc que ce soit à partir d’une clé publique ou d’une adresse ne change rien. En ensuite on met ce qu’on veut en base de données, tout ce qui compte c’est qu’on puisse récupérer un profil à partir d’un account_id.
La base de donnée pourra choisir de “déshabiller” l’adresse pour en extraire la pubkey ou même de la “rhabiller” en changeant son préfixe pour que la recherche puisse se faire sans transformation directement à partir de ce que l’utilisateur rentrera dans le champ de recherche, c’est-à-dire une adresse.
Si je me souviens bien, une adresse n’est pas forcément une pubkey, puisque le runtime peut définir des adresses pour des comptes spéciaux, dont l’authentification ne passe pas par la signature (mais par une autorité comme le root ou un comité).
Je n’ai pas encore regardé dans le détail comment fonctionnent les datapods ni la structure des données (si tu as un peu de temps la semaine prochaine je suis preneur) mais à priori pour les identités c’est la pubkey en b58 (à la duniterv1) qui me parait logique comme pivot entre les applications. L’adresse est plutôt spécifique à ipfs, le moteur de stockage, alors que la pubkey représente la clé ed25519 brute.
Mais tu parles d’adresse d’un noeud ipfs ou d’une clé ipns ? ou libp2p pour v2s ?
Non on parle des address ss58 @aya : https://docs.substrate.io/reference/address-formats/
Les address ss58 sont des concaténations des pubkey (ou autre chose selon tuxmain pour certains cas), un checksum et un prefix définissant le réseau utilisé (ga, gdev, gtest, polkadot, fractalUplanetDarkCrystal, ect …).
Donc je préfère vois des address ss58 partout comme référence, de manière à savoir sur quel réseau ça a été utilisé, car ou peut en déduire la pubkey b58 de toute façon.
Les address contiennent plus d’informations que les pubkey.
J’aurais tendance a penser qu’il faut distinguer les modeles de donnees de la donnee stockee et de la donnee indexee, cad dans ipfs et dans postgres. Le but de l’indexeur est de consommer la donnee brute et de la preparer pour l’usage applicatif.
Pour reconstruire le champ address, il faudrait stocker dans ipfs la pubkey et le prefix, voir meme un link vers un objet json genre did:key a la place du champ pubkey, comme ca on isole la clee dans un objet a part entiere qui pourra etre reutilise par d’autres objets, voir d’autres applications…
Le gros avantage du champ address, c’est surtout qu’il permet plusieurs algorithme de chiffrement (Ed25519 ou sr25519 et +).
Il faut a mon avis partir la dessus.
Si un document n’était pas lié a une seule monnaie, par exemple un profil, il suffirait de mettre un préfixe générique fait pour cela.
Qu’en pensez vous ?
En BDD, il me semble utile d’avoir un champ pubkey (ed25519) pour faciliter le lien avec la v1. Mais ce champ doit être forcément optionnel.