"Gchange Pod" est actuellement utilisé pour synchroniser les essaims ipfs "astrXbian".
Ce service en cours de développement permet de faire profiter le réseau G1 d'un disque commun. Chaque station disposant d'un portefeuille June, ce projet offre une alternative à l'UNL "filecoin" en permettant l'usage d'une monnaie libre pour activer un modèle économique autour de la sauvegarde, et du partage de fichiers...
Chaque station possède une identité "ipfs id" (multihash) identique à la clef publique (base58) d'un profil Gchange+ (et Cesium).
Pendant que le développement avance, voici quelques points notables sur l'intégration des deux systèmes
1) Profils "LIKE (étoile) / HEART (cœur)"
Pour déterminer les autorisations de connections réplication IPFS qui se mettent en place, le système attribue et consulte les "like" échangés... Ce mécanisme permet de forcer l'essaim ipfs à garder une structure amis d'amis (similaire à ScuttleButt, avec 5 niveaux de confiance en plus grâce aux étoiles)
Pour y parvenir l'API est contactée au travers de jaklis.
Afin de déterminer la liste des profils "amis", une boucle récupère la liste des profils ("étoiles" reçues) avant de vérifier qu'une étoile est présente en retour:
for liking_me in $(jaklis.py -k ~/.zen/secret.dunikey -n "https://data.gchange.fr" stars | jq -r '.likes[].issuer'); do
friend_of_mine=$(jaklis.py -k ~/.zen/secret.dunikey -n "https://data.gchange.fr" stars -p $liking_me | jq -r '.yours')
done
Existe-t-il un moyen de trouver à qui un profil a attribué des étoiles ou un coeur en une seule requête?
Cela réduirait le stress en optimisant le nombre de requêtes nécessaires à obtenir cette information...
Cette fonctionnalité existe-t-elle déjà dans l'API ?
Est-il possible de l'ajouter ? A quel endroit regarder dans le code de Gchange Pod pour cela ?
2) Résolution des doublons de MEDIAKEY
Le réseau de stockage étant "anoptique", chaque media est associé à une MEDIAKEY (IPNS) qui détermine (et permet de modifier, façon blockchain) le type de partage (contrat) appliqué aux fichiers. Lorsque 2 stations qui deviennent amies détectent posséder la même MEDIAKEY, un message est envoyé aux 2 protagonistes pour résoudre le conflit et élire celui qui conserve la paternité de la clef (et donc du wallet et du droit à modifier le contrat) avant de fusionner les métadonnées.
En cas de désaccord, ou non réponse aux messages, il est envisagé de forcer la fusion en fonction du nombre de coeurs que les annonces gchange publiées associées aux deux MEDIAKEY auraient reçus... Ici, se pose la question de savoir quelle API, catégorie, visibilité donner à ces annonces...
Cette "greffe" béta effectuée avec Gchange+ remplace avantageusement celle expérimentée avec "secure-ssb".
Ce message a pour volonté de clarifier le fonctionnement de ce service de stockage ipfs entre amis (qui nous libère des datacenter) et valider qu'une collaboration est possible. Pourrions-nous avancer ensemble afin de proposer une version officielle commune?
zicmama
commented
3 years ago
"Gchange Pod" est actuellement utilisé pour synchroniser les essaims ipfs "astrXbian". Ce service en cours de développement permet de faire profiter le réseau G1 d'un disque commun. Chaque station disposant d'un portefeuille June, ce projet offre une alternative à l'UNL "filecoin" en permettant l'usage d'une monnaie libre pour activer un modèle économique autour de la sauvegarde, et du partage de fichiers...
Chaque station possède une identité "ipfs id" (multihash) identique à la clef publique (base58) d'un profil Gchange+ (et Cesium). Pendant que le développement avance, voici quelques points notables sur l'intégration des deux systèmes
1) Profils "LIKE (étoile) / HEART (cœur)" Pour déterminer les autorisations de connections réplication IPFS qui se mettent en place, le système attribue et consulte les "like" échangés... Ce mécanisme permet de forcer l'essaim ipfs à garder une structure amis d'amis (similaire à ScuttleButt, avec 5 niveaux de confiance en plus grâce aux étoiles)
Pour y parvenir l'API est contactée au travers de jaklis. Afin de déterminer la liste des profils "amis", une boucle récupère la liste des profils ("étoiles" reçues) avant de vérifier qu'une étoile est présente en retour:
Existe-t-il un moyen de trouver à qui un profil a attribué des étoiles ou un coeur en une seule requête? Cela réduirait le stress en optimisant le nombre de requêtes nécessaires à obtenir cette information...
Cette fonctionnalité existe-t-elle déjà dans l'API ? Est-il possible de l'ajouter ? A quel endroit regarder dans le code de Gchange Pod pour cela ?
2) Résolution des doublons de MEDIAKEY Le réseau de stockage étant "anoptique", chaque media est associé à une MEDIAKEY (IPNS) qui détermine (et permet de modifier, façon blockchain) le type de partage (contrat) appliqué aux fichiers. Lorsque 2 stations qui deviennent amies détectent posséder la même MEDIAKEY, un message est envoyé aux 2 protagonistes pour résoudre le conflit et élire celui qui conserve la paternité de la clef (et donc du wallet et du droit à modifier le contrat) avant de fusionner les métadonnées.
En cas de désaccord, ou non réponse aux messages, il est envisagé de forcer la fusion en fonction du nombre de coeurs que les annonces gchange publiées associées aux deux MEDIAKEY auraient reçus... Ici, se pose la question de savoir quelle API, catégorie, visibilité donner à ces annonces...
Cette "greffe" béta effectuée avec Gchange+ remplace avantageusement celle expérimentée avec "secure-ssb". Ce message a pour volonté de clarifier le fonctionnement de ce service de stockage ipfs entre amis (qui nous libère des datacenter) et valider qu'une collaboration est possible. Pourrions-nous avancer ensemble afin de proposer une version officielle commune?
merci