J’ai cette erreur lorsque que je fais le curl que tu as mis dans le message. J’imagine qu’il faut des params spécifiques?
Je crois que c’est parce qu’il y a des “\” dans la commande.
Retire les ou copie ma commande qui fonctionne :
curl -X POST https://gdev.cgeek.fr -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"duniter_peerings","params":{}}'
2 Likes
Il y avait des espaces après le premier \, c’est pour ça. Je viens de les supprimer.
2 Likes
Super, merci beaucoup. C’était bien ça !
Sur Cesium v1, on pouvais avoir l’identité de la personne qui héberge. Et vu que je commence cette page pour Cesium v2, je viens de remarquer que les informations ne sont pas présentes dans les datas remontés.
Ou alors existe-t-il un moyen de contourner ce problème?
1 Like
Tu ne peux pas, le trousseau P2P n’est pas du tout lié à une identité par la blockchain.
Solution éventuelle pour lier un nœud P2P à une identité
On pourrait éventuellement le faire un lien via link-account et tu pourrais trouver ce lien sur un indexeur Squid avec ce genre de requête :
query getIdentity($account: String) {
account(where: { id: { _eq: $account } }) {
linkedIdentity {
accountId
index
name
}
}
}
Où $account vaudrait par exemple 12D3KooWGvtbSM9SXMTAukT9zQo26QWegPcvP7pRhPU4HxK151Sx (la clé publique de mon nœud ici).
Ce qui donnerait :
{
"data": {
"account": [
{
"linkedIdentity": {
"accountId": "5E6q47RRGZU15LjUiBTm2DZjpqFKAjRNafYS8YV8AzTQZtLG",
"index": 34,
"name": "cgeek"
}
}
]
}
}
Mais je ne suis pas sûr que ça fonctionne, qu’en penses-tu @HugoTrentesaux ? En plus ce serait de toutes façon une opération optionnelle et manuelle contrairement à Duniter v1 où tout ça est directement déductible. La dé-corellation dans Duniter v2 est faite exprès.
À mon avis tu ferais mieux de partir sur un écran qui ne remonte plus l’identité associée au nœud.
2 Likes
Le nœud forgeron possède des clés de session qui sont associées à son identité en blockchain, donc c’est possible. Mais je ne sais plus si on peut les récupérer en RPC public.
De toute façon on déconseille de cumuler les fonctions de RPC public et de forgeron sur un même nœud, donc cette fonction ne devrait pas être très utile. (un nœud miroir n’est pas lié à une identité)
Par contre les nœuds ont un nom dans lequel il est conseillé d’indiquer son pseudo. C’est purement déclaratif donc il ne faut pas s’y fier, mais ça peut être sympa de l’afficher.
2 Likes
J’ai une question bête à poser?
Le format d’adresse peer_id semble être au format IPFS, est-ce le cas ?
1 Like
Oui je crois bien que c’est le cas. C’est une clé publique Ed25519 préfixée d’un identifiant d’algorithme si j’ai bien compris, sur 4 octets.
1 Like
OK, c’est donc le format multihash qui a été choisi. Mais, est-ce que le endpoint Duniter s’en sert pour publier des données à cette adresse IPFS ?
Si c’est le cas, nous aurions alors un mécanisme qui permet le relier les endpoints à l’espace des “datapod” et disposer d’une base qui permet d’établir un protocole “zero proof knowledge” pour permettre de vérifier la possession de la clef privée correspondant à cette clef jumelle.
Je me sers de cela pour garantir qu’une station Astroport.ONE appartient bien à un utilisateur reconnu par la preuve d’Humanité inhérente à la WoT Duniter. Comment créer une toile de confiance entre les machines sur internet? | CopyLaRadio
Le fait de disposer de clef jumelles sur différents canaux de communication permet d’envoyer un secret chiffré avec la clef publique en commentaire d’une transaction émise depuis un autre portefeuille puis de vérifier que ce secret est bien décodé par la clef privée en le récupérant (chiffré avec la clef publique source) sur la jumelle IPNS ce qui assure de l’usage et la possession de la clef privée correspondante.
Cette méthode combinée à la vérification que la primo transaction reçue par le “wallet machine” provient d’un compte membre assure que le node appartient bien à un humain et établi un lien cryptographique qui permet aux Stations de se faire confiance pour autoriser l’ouverture de tunnels SSH entre les machines des amis déclarés dans la WoT. C’est d’après cette preuve de liaison “Homme/Machine” que les essaims d’auto-hébergeurs se relient et permet la co-administration entre les membres de la coopérative CopyLaRadio.
1 Like
Je ne sais pas te dire. Duniter utilise un sous-stream sur la connexion P2P réalisée avec cette adresse, gérée par Substrate. Te dire si cette “adresse” est utilisée comme une adresse IPFS, je n’en sais rien. Je vois bien traîner des protocoles IPFS sur la couche réseau mais suis incapable de te dire à quel point c’est utilisé.
C’est peut-être simplement la façon de causer au travers de la libp2p qui est utilisée par substrate dont le traffic n’est pas relatif à IPFS lui-même. Dans ce cas, il ne devrait pas y avoir de conflit à laisser utiliser cette clef par les “datapod”… Pour disposer de cette clef jumelle, peut-on exporter la clef privée correspondante ?
Oui la clé privée est stockée en clair sur disque.
Parfait, dans ce cas, il suffit de l’injecter dans ~/.ipfs/config pour que le DataPod IPFS en dispose également 
@HugoTrentesaux il faudrait qu’on essaye.
Est ce que le endpoint dispose d’un G1 wallet ?
En v1, il me suffisait de convertir la clef publique du node pour le découvrir
1 Like
Non, Substrate utilise des protocoles communs à IPFS (multiaddress, multihash, uvarint, libp2p) mais pas IPFS. J’imagine qu’il y a plein de projets d’interaction mais ce n’est pas le cas pour Duniter, actuellement. (à part les datapods mais c’est complètement séparé de Substrate)
1 Like
TL;DR pour la capture suivante, la colonne de droite avec les blocs peut être réalisée à partir de squid (tout en gardant en tête qu’il y en a un toutes les six secondes), et pour la colonne de gauche (la liste des endpoints), on n’a pas encore de mécanisme pour associer des infos à un endpoint.
Il me semble que ces informations (notamment l’avatar) étaient récupérées via les données Cesium+. Cela n’empêchait donc pas tellement l’usurpation d’identité : je pouvais faire un nœud miroir sur g1.cgeeek.fr avec une clé publique en ma possession et publier un profil Cesium+ avec l’avatar de cgeek et le nom “Cédric Moreau” et en terme d’affichage il me semble que seule la couleur changerait (bleu pour membre vs noir pour simple profil / portefeuille). Donc les gens pouvaient se connecter à mon nœud malicieux en pensant que c’était celui de cgeek.
En v2, on interdit d’exposer l’API RPC de son nœud forgeron, donc les seuls nœuds listés seront des nœuds miroir. Pour que des données hors chaîne (sur datapods) existent pour les clés des nœuds miroir, il faut que leur propriétaire publie des données avec la clé du nœud, ce qui n’est pas prévu pour l’instant, mais l’utilisateur pourrait théoriquement le faire. Ceci dit, tant qu’il n’y a pas de lien avec l’identité ce n’est pas un gage de confiance.
C’est effectivement une des applications que j’envisageais pour le link account : montrer on chain qu’une clé est digne de confiance car reliable à un membre. Mais dans ce cas, ce n’est pas facilité parce que le fichier node.key écrit par la commande duniter key generate-node-key est simplement la clé privée : duniter-polkadot-sdk/substrate/client/cli/src/commands/generate_node_key.rs at duniter-substrate-v1.17.0 · duniter/duniter-polkadot-sdk · GitHub, ce qui n’est pas pratique pour l’utiliser pour signer une transaction link-account (on pourrait cependant ajouter la saisie d’une clé privée dans gcli).
À partir du moment où on peut extraire la clé, c’est effectivement aussi possible de signer un document datapod avec si on veut. Par contre “à cette adresse” ça ne veut pas dire grand chose (ce n’est pas un CID, le hash d’une donnée), et il faudrait éviter d’avoir plusieurs fois le même peer id sur le réseau, donc là non plus…
Pour les discussions IPFS / Duniter il y a aussi ce sujet Option "ipfs" de substrate.
C’est déjà le cas, via -S seed <node.key> la dérivation Sr25519 est correcte, mais il manque la dérivation Ed25519.
Enfin je ne sais pas si le terme “dérivation” est le bon, mais vous voyez l’idée.
Dans ma compréhension, c’est de la seed (nombre aléatoire) qu’on dérive les clés (nombre avec des propriétés particulières relatives à la courbe x25519), dont la clé privée. Or il semble que c’est la clé privée et non la seed qui est écrite dans node.key, mais peut-être que je me mélange ?
En tout cas quand j’ai testé cette option dans Gcli e en utilisant Ed25519 pour la « dérivation », et en transformant la clé publique ainsi déduite avec multihash, j’obtiens bien le PeerId de mon noeud.
3 Likes