Les prismes Lightning

Un aspect qui est encore largement sous-exploité est la programmabilité de Bitcoin. Bien que des choses simples comme les paiements planifiés et les partages de paiements automatisés existent, nous sommes sans aucun doute encore piégés dans une pensée conventionnelle en ce qui concerne le flux de sats (1 sat = 0.00000001 BTC). Je voudrais partager une idée simple qui m’a été partagée il y a quelques mois dans l’espoir qu’elle se propage plus largement et, dans le meilleur des cas, que quelqu’un l’implémente (ou créé une meilleure version).

Voici l’idée :

Le crédit revient à M. Kukks (https://nostr.directory/p/MrKukks ), qui n’a clairement plus le temps de l’implémenter lui-même.

Prismes Lightning

Un prisme Lightning est un mécanisme qui permet aux « adresses Lightning de diviser puis répartir les transactions », afin de citer l’émetteur de la transaction. Voici l’idée générale :

• Un prisme est identifié par une adresse Lightning (ou similaire)
• Un prisme a un ou plusieurs destinataires
• Un autre prisme peut être l’un des destinataires
• Les répartitions sont programmées

Cette construction simple permet toutes sortes de cas d’utilisation et peut être implémentée à la couche de l’application sans aucun changement dans Bitcoin ou Lightning.

Un cas d’utilisation évident est la répartition de la valeur pour des articles de blog et autres similaires. Imaginez si chaque article de blog (ou chapitre de livre) avait sa propre adresse Lightning, répartissant automatiquement la transaction à l’auteur, l’éditeur, l’illustrateur et les correcteurs. Le concept de ces répartitions de valeur existe déjà dans Podcasting 2.0 (https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md#payment- calculation ), où il est largement appliqué aux podcasts et aux épisodes. On pourrait soutenir que le fait d’avoir un identifiant différent pour la transaction répartie est l’évolution naturelle de ces prismes, car il est plus facile de les lier et de les enchaîner ensemble.

Un autre cas d’utilisation évident est la séparation des zaps de nostr. Imaginez que chaque « citation- tweet » qui est zappé entraîne une répartition de paiement automatisée, passant 50% (ou ce que l’utilisateur a configuré) à la publication originale. Ou imaginez un prisme qui est créé en instantané, répartissant les zaps de manière égale pour tous les utilisateurs identifiés dans une publication.

Comme les paiements sont transférés, chaque prisme agit comme une procuration. Cela peut être utile à la fois pour les organisations et les particuliers, car votre identifiant de paiement reste le même si votre infrastructure sous-jacente ou votre fournisseur de portefeuille change.

Problèmes et améliorations

Il y a principalement deux problèmes : les frais et la confidentialité. Il faut tenir compte des frais pour payer la répartition et la transmission, mais il y a aussi le problème selon lequel les adresses Lightning sont basées sur l’adresse IP, ce qui a certaines implications en matière de confidentialité. Nous pourrions faire LNURL sur nostr (https://github.com/lnurl/luds/pull/203 ) – encore une fois, un cri à Kukks – ce qui soulève la question suivante : les adresses Lightning sont-elles le bon niveau d’abstraction pour les prismes Lightning ?

À la fin, nous ne voulons pas envoyer des sats à des adresses, mais à des personnes. Si Nostr continue à être adopté, il pourrait se transformer en carnet d’adresses global pour ce type de choses, c’est-à- dire l’endroit où trouver les informations de paiement de personnes, d’organisations et d’autres entités. À l’avenir, un prisme pourrait avoir plusieurs identifiants de profil NProfile ou NPub comme cibles, derrière lesquels se trouvent les informations de paiement réelles.

En tout cas, à ce stade, je ne suis pas trop préoccupé par les détails de mise en œuvre. Je suis préoccupé par un manque d’imagination, c’est ce que ce poste est censé exprimer.

En parlant d’imagination : pourquoi n’avons-nous pas de portefeuilles de dépenses qui déplacent automatiquement les sats vers un portefeuille différent au-dessus d’un certain seuil ? Je suis plus qu’heureux d’avoir de l’argent de poche dans un portefeuille custodial, mais une fois qu’il vaut trois mois de loyer, je ne suis plus aussi à l’aise. Pourquoi le portefeuille ne peut-il pas envoyer automatiquement tous les sats en trop à mon adresse Lightning entièrement auto-souveraine une fois qu’il s’agit de plus que le coût d’un dîner ? Ou faire une sortie de boucle une fois par mois pour déplacer les sats vers un cold storage ?

Bref, je m’égare.

Une amélioration que j’aimerais voir serait de fournir un moyen de rendre les prismes Lightning transparents. Dans le meilleur des cas, les utilisateurs devraient avoir un moyen de voir comment les paiements sont divisés, facile à comprendre et à vérifier. Une possibilité serait de diffuser un NIP-33 (https://github.com/nostr-protocol/nips/blob/master/33.md ) paramétré en tant qu’événement remplaçable à chaque fois qu’un prisme est créé ou mis à jour. Bien sûr, dépendant du cas d’utilisation, il pourrait être logique de garder la.les destination.s finale.s cachée.s aux yeux du public.

Je suis sûr qu’il y a d’autres problèmes et de nombreuses autres améliorations à apporter. Mais comme toujours, le parfait est l’ennemi du bien, alors parlons de solutions pratiques qui peuvent être implémentées et utilisées dès maintenant.

Implémentation

Les prismes basés sur les adresses Lightning peuvent être construits aujourd’hui sans beaucoup d’efforts. Vous pouvez même le construire vous-même sans aucune expérience de programmation en utilisant deux extensions LNbits (https://lnbits.com/ ) : Scrub (https://github.com/lnbits/scrub ) et Split (https://github.com/lnbits/splitpayments). Ajoutez Satdress (https://github.com/nbd- wtf/satdress) par-dessus tout cela pour donner à chaque portefeuille sa propre adresse Lightning, et voilà, vous avez un Prisme Lightning ! Vous pouvez même construire une belle interface en tant qu’enveloppe autour, car tout ce qui précède peut-être programmé avec des appels d’API simples.

J’ai fait tout cela (à l’exception de « construire une belle interface en tant enveloppe autour ») juste pour jouer avec l’idée. Il est vrai que c’est un peu bricolé et probablement pas la solution la plus stable ou la plus élégante, mais ça marche plutôt bien, et ça peut être utilisé dès aujourd’hui.

L’adresse de blogpost@satprism.com qui est indiquée ci-dessus est un exemple fonctionnel 2. Elle va diviser tous les paiements en deux parts égales, une pour Kukks et une pour moi-même, et transférer les parts à nos adresses respectives qui sont fournies par nos instances personnelles de serveur BTCPay (https://btcpayserver.org/ ).

J’imagine que plusieurs services seront créés pour mettre cela en place de manière appropriée, en facturant des frais minimes pour fournir ledit service. (Comme mentionné ci-dessus, une sorte de frais sera nécessaire pour payer les frais de routage, car les paiements sont transférés à des adresses externes.)

J’espère que ce genre d’idées et de constructions novatrices deviendront plus courantes à mesure que les zaps (https://nostr-resources.com/#receiving-zaps ), les paiements similaires à V4V (https://value4value.info/ ), ainsi que Lightning en général, deviennent plus courants. Bien sûr, dans le meilleur des cas, nous aurons ces choses intégrées nativement au niveau du protocole, mais je ne vois pas pourquoi nous ne devrions pas expérimenter un peu avec ce que nous avons aujourd’hui, même si les solutions ne sont pas parfaites. Jusqu’à ce que Bolt12 (http://bolt12.org/ ) et des technologies similaires soient largement répandues, bricoler quelque chose qui fonctionne simplement n’est probablement pas la pire idée.

Réflexions finales

Je m’attends à ce que cette idée trouve une adoption généralisée parmi les écrivains et les autres créateurs de contenu, tout comme l’idée de « streaming sats » – et la répartition de ces flux de valeur – a trouvé une large adoption parmi les podcasteurs.

Des clients Nostr spécialisés pour différents types de contenu sont déjà en cours de développement, avec des interfaces similaires à SubStack et Medium, telles que BlogStack (https://blogstack.io/ ) et Habla (https://habla.news/ ), qui apparaissent de gauche à droite.

Ce qui manque encore, c’est d’attacher des informations de paiement à des événements individuels (par opposition aux profils d’utilisateurs) afin que chaque contenu de forme longue puisse avoir ses propres informations de paiement. Peut-être est-ce aussi simple que d’étendre les métadonnées NIP- 23 (https://github.com/nostr-protocol/nips/blob/master/23.md), ou peut-être serait-il judicieux d’avoir ce type de métadonnées pour d’autres types d’événements aussi.

Nous allons trouver une solution, et par « nous », j’entends vous, les développeurs qui se mettent à spécifier et à construire des choses.

Je vous encouragerai tout en shitpostant sur Nostr.

Notes de fin :

J’ai promis à Kukks de ne pas en parler pendant quelques semaines pour qu’il puisse le mettre en œuvre, mais il était préoccupé par l’amélioration de la confidentialité (https://nitter.at/MrKukks/status/1630221270246719489 ), ce qui est également très important, bien sûr ! En tout cas, désolé, Kukks, mais ton temps est écoulé !

Tous les prismes présentés dans ce post sont des exemples fonctionnels : nostr-devs-eat- handsomely@satprism.com (lightning:nostr-devs-eat-handsomely@satprism.com) divise également les paiements entre tous les développeurs mentionnés dans la note de Quiet Warrior, et dergigi- platobot@satprism.com (lightning:dergigi-platobot@satprism.com) est un partage entre le robot et moi-même. J’ai également pris la liberté de créer rhr@satprism.com (lightning:rhr@satprism.com), qui répartit les paiements entre Marty et Matt, et il y a aussi einundzwanzig@satprism.com (lightning:einundzwanzig@satprism.com) pour l’équipe germanophone.

J’ai créé manuellement les exemples de prismes, donc je crains que tant qu’une belle interface permettant aux utilisateurs de les créer eux-mêmes ne soit mise en place, il n’y aura pas d’explosion de prismes. J’aime créer une multitude de portefeuilles lnbits autant que le prochain gars, mais cliquer sur tous les boutons pour créer les répartitions et les transferts devient fatigant après un moment.

Tips Marius AaB !

bc1q9fp2gs2tw0y4dfmd2hs6jtvudljjt0gs3h58hs

Nos derniers articles