Salut les gars,
Des améliorations en termes de modération et de fédération sont envisageables. Le problème actuel réside dans la manière dont les comptes Gchange sont créés et liés aux comptes de réception des paiements. Actuellement, copier la clé publique dans le profil ne garantit pas la “paternité” du compte.
Une solution possible serait d’utiliser le “wallet naturel” associé à la clé Gchange. L’idée serait d’attendre la réception d’une Ğ1 depuis le compte membre (prouvant l’usage de la clé privée) avant de “certifier” le compte.
Ce principe de “primo transaction” pourrait étendre la “preuve d’humanité” de la WoT (Web of Trust) à d’autres clés et applications.
Une autre façon de “protéger” le graph informationnel d’un utilisateur est de distinguer les relations :
* certifications mutuelles (P2P) : “Followers/Following”
* certif entrante uniquement (12P) : “Followers”
* certif sortantes uniquement (P21) : “Following”
C’est ce principe qui est appliqué à la clef “uPassport” activable sur la station avec 1Ğ1 reçue du compte forgeron
Cette distinction appliquée à la couche informationnelle “N1” permet d’apporter plus ou moins de poids aux informations en provenance de la couche “N2” (“Amis d’amis”).
Ensuite, pour stocker et échanger des information entre les clefs, le protocole “NOSTR” semble être un excellent candidat pour y inscrire les annonces Gchange. Mais également les Profils et autres données applicatives.
Actuellement j’expérimente la création de clef “NOSTR Card” (+Ğ1 wallet +IPNS stockage datapod) partagée selon le Partage de clé secrète de Shamir — Wikipédia (3/2) pour établir une relation “tiers de confiance” entre l’utilisateur, le node (et son admin) et l’essaim (qui relie les nodes et leurs admin)
En utilisant cette clef nostr dans “Coracle” (Twitter/Facebook like) on peut y ajouter le support Ğ1 (en plus ou à la place des Btc “satoshi”), l’upload de fichier sur IPFS (à la place de blossom) et la mise en cache applicative sur IPNS (tenu à jour par un processus serveur qui construit les index du graph).
J’essaye de rendre l’application multilingue : GitHub - papiche/coracle: An experimental Nostr client focused on unlocking the full potential of multiple relays. Browse, filter, zap, and create custom feeds to create a curated Nostr experience. avant d’y ajouter le “multi App (kind)” en suivant les NIP et en proposant de nouvelles évolutions au protocole au travers des clients et relais “strfry” qui synchronisent leurs données en fonctions des relations “WoT” et des filtrages par “tag/kind” des utilisateurs.