Discussion UX Nostr Gchange

R&D
,
1

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.

1 Like
2

Salut à tous,
je plussoie la question et les reflexions.

J’ajoute qu’il serait pertinent de demander en amont du développement à une personne spécialisé dans l’UX/UI de faire les prototypes à implémenter.

Partir sur un nouveau projet sans cette étape reviendrait à construire une nouvelle maison sans avoir de plan.

Je peux faire une annonce sur https://opensourcedesign.net/ si ça vous semble pertinent. :slight_smile:

3

NOSTR a déjà un système de market place (en BTC/sats) décris dans la NIP-15

L’avantage est que chacun peut choisir les relais où déclarer sa Boutique et ses produits que des applications “market place” agrègent (selon les préférence du Profil).

Cela fourni une base protocolaire capable de remplacer les “GChange POD” (Elastic Search). Et donne un exemple “UI/UX” à faire évoluer en remplaçant “Bitcoin et Lightning” par “Ğ1 et Astroport/UPlanet IPFS)”.

Nous avons tout un tas d’avantages sur NOSTR(BTC): la WoT (PoH) avec la primo transaction pour relier les boutiques à de vrais humains de manière fiable, plus la géolocalisation UPlanet pour savoir où se trouve le vendeur.

Oh oui, ça serait cool :wink:
Quelle annonce voudrai-tu publier ?

4

Quelque chose comme: “On a besoin d’aide pour penser l’UX de la monnaie libre.”

Ou plus précis si vous voulez. Mais le point clé c’est est-ce qu’on est ouvert à ça en tant que communauté, et particulièrement les développeurs. :slight_smile:

5

C’est l’objectif des recherches et expériences menées par le G1FabLab depuis 6 ans…Et qui a une proposition assez fonctionnelle.

L’UX utilise des “paperwallet” et des “terminaux” pour permettre l’utilisation de la ML y compris à ceux qui n’ont pas ou ne veulent pas de smartphone ou d’ordinateur (mais il faut qu’au moins un des participant à l’échange de June soit équipé)…

NB: On estime qu’environ 2 à 3 milliards de personnes dans le monde n’ont ni smartphone ni ordinateur personnel. Cela représente environ 25 à 40 % de la population mondiale.

Voici rapidement les grandes lignes :

  1. Saisir un identifiant type email (qui n’est pas forcément routé vers un serveur mail, mais doit être unique) pour créer un premier portefeuille qui sera également une clef NOSTR pour activer son identité sociale dans le réseau et profiter des applications du relai où il s’est inscrit.

NB: Particularité introduite par Astroport.ONE, la fabrication de clef jumelles avec keygen . Ainsi, une clef IPNS est associée et pourra servir à capter chaque jour les données issues de l’analyse des sphères informationnelles N1/N2. Cela permet une rationalisation des clients nostr (qui n’ont plus à configurer les relais ou les amis se trouvent) et apporte une optimisation par des synchronisations relatives entre les relais nostr du réseau (je bosse la dessus en ce moment)… L’utilisateur aura une UX plus simple dans NOSTR qui est un gros bordel à ce niveau…

  1. Récupération de sa “NOSTR Card” (format Zine) à imprimer et qui pour être activée doit recevoir 1 G1 d’un autre compte (déjà membre ou en devenir). C’est le symbole de l’identité sociale et communicante. Pour assurer une égalité d’accès (et éviter le spam), on pourrait envoyer 0.1 G1 à chaque “like/partage/réponse” à la source et autant au relai nostr (qui a aussi un wallet) pour créer un nouveau POST.

[:bird: NostrCard ] adresseformat@domainequejeveux.fr.pdf|attachment (1,7 Mo)

  1. Si le wallet reçoit 1 G1, le Backoffice va fabriquer un “UPassport” en analysant les relation WoT Duniter de cette clef “PRIMAL” (celle qui a effectué la primo transaction sur le wallet nostr) et qui attend une primal tx depuis une clef membre pour être officiel. Cette nouvelle clef wallet dispose aussi de sa clef IPNS (ZeroCard)… Qui pourra servir à établir de nouvelles toiles de confiance “administratives”…

  2. Entre en jeu les coordonnées GPS de son UPassport (à priori celles de son relai, qu’il aura choisi le plus proche de chez lui, sinon par défaut 0.00,0.00) que la station Astroport (:heart:box) utilise pour créer la clef “MULTIPASS/ZenCard” (avec le même email que la nostr Card) et qui permet de voir ses messages publiés sur la UMap où il se trouve dans un journal quotidien. Désormais inscrit dans le Système d’Information UPlanet (station reliées en essaim privé IPFS) dont le wallet envoi la primo transaction 1 G1 à la “ZenCard” pour l’activer… Cette carte est alors l’équivalent d’une CB qui reçoit autant de Ẑen que d’€ versés (stable coins similaire ERC-20 émis par “MadeInZen” que nous sommes en train de rendre officiel et associe un pacte d’actionnaire 3x1/3 à ses clients = actionnaires détenant des parts de capital de la coopérative des auto-hébergeurs)…

En fait, expliquer une UX avec du texte est certainement la plus mauvaise façon de le faire… Le mieux c’est de l’essayer :wink: @aya qui a séjourné au G1FabLab est certainement celui qui en a le meilleur aperçu.

Il reste des trucs à peaufiner, mais cette répartition en 3 clefs (“social”, “administratif”, “banque de dépôt”) est une copie de l’organisation du système actuel… Auxquelles on ajoute une 4éme clef (forgeron ML), et une 5ème (pour la Planète).

Ceux qui veulent en savoir plus et participer à peaufiner et enrichir ce qui reste à faire, je suis dispo pour une session visio ou IRL

NB: Les :heart:box sont soit des RPi (8Go), ou PC Gamer, avec 4To minimum de disque pour proposer un hébergement NextCloud à l’utilisateur (qui pourra quitter les GAFAM en y synchornisant son smartphone) en même temps que les services de Duniter, IPFS et NOSTR. Elles sont reliées en essaim de confiance (DRAGON) par le jumelage de la clef SSH avec la clef IPFS de la Station ce qui autorise la co-administration (authorized_key ssh) et la création d’une toile de confiance technique pour l’occasion

1 Like
6

Fil déplacé ici car hors sujet par rapport au message initial bien qu’intéressant.