Comment les datapods vont gérer les différentes monnaies ? Que ce soit pour bien séparer les réseaux gtest et g1, ou pour éviter les collisions avec des réutilisations du protocole pour d’autres réseaux.
Les commentaires de transaction nécessitent-ils de spécifier la blockchain ? S’ils font référence à un hash de bloc, non.
Pour un éventuel antispam basé sur des frais ou de la monnaie verrouillée, ce serait critique.
Les datapods peuvent-ils indexer plusieurs blockchains à la fois ?
Est-ce qu’il faudrait un réseau de datapods par monnaie, ou peut-on mutualiser certaines informations (profils) et spécifier un hash de bloc ou un identifiant de monnaie seulement dans les documents qui le requièrent (commentaires de transaction) ?
1 Like
Je me permets de déplacer ce post dans un nouveau sujet parce que c’est une question que je me pose aussi et qui gagnerait à être débattue en détail.
Pour l’instant les datapods sont généralistes et agnostiques du réseau.
Il y a plusieurs leviers pour les rendre spécifiques à un réseau :
- utiliser un réseau différent (pour l’instant j’utilise le réseau IPFS public, la DHT “Amino”)
- utiliser un canal pubsub différent pour les demandes d’indexation (pour l’instant j’utilise “ddd” pour Duniter Datapods Demo), mais rien n’empêche de republier une demande d’indexation récente sur un autre canal
- utiliser un préfixe de payload de signature différent (pour l’instant j’utilise “Duniter Datapod”), cela permettrait à l’utilisateur de préciser son intention pour la publication de la donnée)
- filtrer les clés publiques / addresses acceptées dans la TAMT d’un datapod
- filtrer les clés publiques / addresses acceptées dans la base postgres d’un datapod
Pour moi, un utilisateur peut s’il le souhaite utiliser la même clé publique et donc les mêmes données sur plusieurs réseaux, ça aurait du sens et ça éviterait les problématiques de migration de réseau ou de fork.
Les datapods n’indexent pas une blockchain, juste des messages qu’on leur soumet.
Donc pour moi on peut tout mutualiser, même si certaines informations n’ont de sens que dans un contexte donné (monnaie donnée).
3 Likes
Lorsqu’un document est lieya une blockchain en particulier (commentaires de TX), n’est-ce pas possible : - d’utiliser un ‘kind’ différent dans l’IndexRequest ?
- Ou bien d’utiliser les adresses (qui intègre un préfixe) plutôt que les pubkeys ?
2 Likes
Je me dirige vers une solution qui se rapproche de cette proposition :
- au niveau de la
IndexRequest, le champ “pubkey” est une string dont la seule contrainte est de pouvoir vérifier une signature. L’utilisateur est libre de la mettre au format qu’il souhaite, il faudrait d’ailleurs utiliser un format standard genre did (cc @aya). Pour l’instant on accepte une pubkey base58 ou une adresse ss58
- au niveau de l’ajout en AMT, c’est le propriétaire du nœud IPFS qui choisit ce qu’il collecte, il peut filtrer les pubkey sur la base d’une liste de pubkey de confiance en tenant en compte ou pas des préfixes
- au niveau de l’ajout en base de données (SQL, Elasticsearch, peu importe) c’est un choix du développeur qui voudra fournir une API de son choix utilisé dans le client de son choix. Donc il aura toutes les options suivantes :
- convertir tout (pubkey, address…) dans un format accountid de son choix en ignorant les préfixes
- filtrer uniquement les adresses qui ont le préfixe d’un réseau défini
Ce que je compte faire par défaut c’est :
- si le “kind” est un import de document C+, alors convertir en adresse avec un préfixe (pour l’instant 42 en mode dev)
- si le “kind” est une demande d’indexation, alors laisser tel quel (pubkey ou address)
Cela permet au client qui soumet une demande d’indexation de choisir s’il veut que la donnée soit indépendante du réseau (clé publique sans préfixe) ou qu’elle cible un réseau (adresse avec préfixe de réseau). Ensuite il pourra faire des requêtes graphql en utilisant ce qu’il veut : pubkey pour récupérer un document générique ou adresse pour récupérer un document spécifique à un réseau (qui a été soumis en ciblant un réseau).