Lightning For Life - Comment Lightning peut et va s'intégrer au Web

Lightning est sur le point de s’intégrer de manière transparente à nos opérations quotidiennes, de la même manière qu’Internet.

Roy Sheinfeld est le co-fondateur et PDG de Breez, une société Bitcoin axée sur les paiements Lightning.

Chaque fois que vous recherchez quelque chose sur Google, chaque fois que vous faites des recherches sérieuses sur YouTube ou Instagram, chaque fois que vous commandez un Uber, chaque fois que vous consultez votre portefeuille ou lisez les actualités, vous utilisez le Web. En fait, vous utilisez le Web en ce moment pour lire ceci. Le web est un outil, mais c'est un outil au même titre que les poumons ou les pouces sont des outils ; c'est devenu une partie intégrante de nous que nous utilisons constamment sans même y penser.

L'argent est similaire en ce sens que nous l'utilisons constamment et inconsciemment. Tant que votre réfrigérateur fonctionne, tant que vos fonds accumulent des intérêts quelque part, tant que le compte de la dette sur votre prêt tourne, vous êtes impliqué dans une activité financière. Votre moi financier est éveillé, maintenant sa position dans le réseau mondial de la valeur, même pendant votre sommeil.

Les Bitcoiners ont tendance à être parfaitement conscients de ce genre de choses. Si vous utilisez Lightning, vous le voyez probablement comme un intermédiaire entre vous et ce réseau mondial de valeur. Ce n'est pas seulement un moyen de acheter une bière à Helsinki; Lightning vous connecte à la mer de Bitcoin.

Bizarrement, ces deux réseaux vitaux - le Web et Lightning - fonctionnent toujours en parallèle avec peu d'intégration. Nous ne voulons pas vivre sans l'un ou l'autre, mais les coutures entre eux sont palpables, parfois gênantes.

Comme je l'ai appris au hackathon bolt.fun (merci à mon homme Johns !), de nombreux développeurs Web aimeraient créer des applications avec la fonctionnalité Lightning. La volonté d'intégration est là, mais beaucoup ne semblent pas se rendre compte qu'il existe également un moyen. En fait, il existe plusieurs façons d'amener Lightning sur le Web et chacune évolue avec ses propres forces et cas d'utilisation. Peut-être que le monde ne les connaît pas ou ne les comprend pas ?

Alors faisons-le. Voyons comment intégrer le Web et Lightning, en tirant les brins, en les tissant ensemble et en créant un réseau plus solide, combiné et homogène.

LNURL : Rester simple

L'expérience utilisateur Lightning (UX) a parcouru un long chemin depuis que j'ai l'a d'abord couvert il y a trois ans. Mais des lacunes subsistent. Les factures en sont un exemple. Techniquement, seul le bénéficiaire peut initier un paiement, ce qui est inapproprié dans de nombreux contextes. De nombreux utilisateurs peuvent ne pas vouloir générer de facture pour une raison quelconque et, dans des scénarios tels que les pourboires, cela peut raisonnablement sembler encombrant et grossier.

LNURL est un ensemble très simple de spécifications pour combler certaines de ces lacunes UX restantes, y compris la génération de factures. La beauté de LNURL est sa simplicité. Comme son nom l'indique, les spécifications LNURL sont basées sur des liens, sous la forme d'URL cliquables ou de codes QR scannables. Les liens URL font partie de notre bagage technologique. Vous en avez déjà vu quatre dans ce post, probablement sans même les remarquer. Les codes QR sont la même chose, juste une représentation visuelle différente :

Il y a plusieurs LNURL spécifications disponibles, mais celles-ci sont particulièrement pertinentes pour l'intégration Web de Lightning :

• LNURL-Payer: Disons que vous dirigez un blog Bitcoin. Vous souhaitez collecter des pourboires, mais vous ne souhaitez pas générer et afficher une facture pour chaque pourboire, ni interagir avec chaque lecteur individuellement pour chaque pourboire. LNURL-Pay vous permet de générer des codes QR pour les paiements dans une plage spécifiée, par exemple 2,500 10,000 à XNUMX XNUMX sats. Un utilisateur peut simplement scanner un code, saisir le montant précis et payer. L'utilisateur reste inconscient du langage des pré-images et des factures, se contentant de scanner un code et de répondre à une invite.
• LNURL-Retirer: C'est le scénario inverse : vous voulez payer les utilisateurs pour interagir avec votre site, mais vous voulez leur épargner la peine de générer une facture. LNURL-Withdraw permet aux utilisateurs de scanner un code ou de cliquer sur un lien qui invitera leurs portefeuilles à générer le type de facture approprié et à l'envoyer à votre nœud pour paiement.
• LNURL-Auth. est un autre outil LNURL sympa. Il génère un ensemble de clés publiques-privées basé sur les phrases de départ dans les portefeuilles des utilisateurs pour leur permettre de se connecter aux sites Web sous un pseudonyme. C'est aussi privé que la phrase de départ elle-même et plus difficile à forcer que "password123" ou "correct_horse_battery_staple.” Mieux encore, il utilise des données déjà contenues dans les portefeuilles des utilisateurs, prêtes à l'emploi avec peu d'entrées.

Adresses Lightning

Le courrier électronique est peut-être si familier que nous prenons ses avantages pour acquis. Les adresses e-mail sont strictement uniques (contrairement empreintes digitales), et le courrier électronique rend extrêmement facile l'envoi et la réception d'informations à la bonne personne. Adresses Lightning ont le même format xxx@yyy.zzz que le courrier électronique, mais ils permettent aux utilisateurs de transférer des fonds sans avoir à manipuler un code QR.

Actuellement, LNURL-Pay est le moyen le plus populaire d'implémenter des adresses Lightning, mais le protocole Lightning Address est ouvert à l'innovation. Par exemple, les adresses Lightning peuvent être étendues pour utiliser des factures statiques ou BOULON12 (Basis of Lightning Technology ; l'équivalent Lightning des spécifications Bitcoin Improvement Proposal [BIP]), une fois celles-ci adoptées.

Même dans leur forme actuelle basée sur LNURL, les adresses Lightning sont très populaires et faciles à intégrer. En effet, plusieurs applications incluent nativement des adresses Lightning, mais il existe également des serveurs de pont non dépositaires disponibles pour ceux qui ont leurs propres nœuds et qui ne se soucient pas d'un peu de configuration et il y a Des instructions pour une configuration entièrement auto-hébergée avec votre propre nom de domaine.

Afin de vraiment faire de Lightning Addresses un succès, nous devons trouver comment permettre aux portefeuilles mobiles non dépositaires de recevoir hors ligne.

WebLN

WebLN part d'un principe simple : la plupart du temps, lorsque nous interagissons avec le Web, nous le faisons via un navigateur Web. Les navigateurs Web sont pratiquement de petits systèmes d'exploitation à part entière, capables d'exécuter toutes sortes de logiciels sympas dans leurs propres environnements.

Étant donné que Lightning n'est qu'un logiciel et que nous souhaitons l'intégrer au Web, l'ajout de Lightning aux navigateurs Web ira loin.

C'est précisément l'idée derrière WebLN, qui est un simple outil JavaScript pour créer des extensions de navigateur compatibles Lightning en utilisant makePayment et sendInvoice - encore une fois, les deux fonctions principales pour tout type d'argent : envoyer et recevoir. En d'autres termes, WebLN permet aux applications Web d'interagir avec les portefeuilles Lightning.

WebLN offre quelques avantages. Premièrement, JavaScript est presque universel et a presque trente ans. Nous sommes presque sûrs que cela fonctionne. Deuxièmement, WebLN est simple. Comment simple? Michel Bumann de Alby peut le configurer et montrer comment l'utiliser en cinq minutes et trente-huit secondes.

Lien vers la vidéo YouTube ici.

Troisièmement, WebLN offre une UX bien meilleure que les codes QR, à commencer par le fait que vous n'avez pas besoin d'utiliser un deuxième appareil. Cela semble natif, pas comme une solution de contournement. Vous avez également accès à tous les événements du navigateur, donc une pression sur une touche, un clic de souris, un position de défilement, etc. peuvent tous déclencher un paiement. L'UX sans QR est particulièrement pratique sur mobile où WebLN fonctionne également.

Néanmoins, WebLN n’est pas une interface Web vers Lightning universelle. Il nécessite un environnement compatible WebLN. Sur un navigateur de bureau, une simple extension, comme Alby, peut créer cet environnement. Sur mobile, les développeurs peuvent soit élaborer leur propre solution WebLN, soit trouver leur place dans une application Lightning qui offre déjà un environnement WebLN intégré, comme Breez ainsi que Portefeuille bleu. Peut-être que le fait que WebLN ne soit pas natif des navigateurs Web a empêché ou ralenti son adoption généralisée. Je peux voir un avenir où les hôtes WebLN sont implémentés nativement dans les sites utilisant WebAssembly, supprimant les coutures pour les utilisateurs finaux.

Pour de nombreuses transactions simples basées sur un navigateur, comme les pourboires et les achats ponctuels, WebLN est tout ce dont vous avez besoin pour intégrer nos deux réseaux préférés. Cela fonctionne si bien que bon nombre des meilleurs services Lightning l'utilisent avec succès depuis des années. Qui comprend Bitrefill, LNMarchéset Collider.

Apis

Lorsqu'il s'agit d'intégrer un service Web et un service Lightning de manière transparente, il est difficile de battre une interface de programmation d'application (API) conçue pour cela. L'intégration de l'API donne aux développeurs le plus grand contrôle sur l'expérience utilisateur et l'interface.

Aussi bon que cela puisse paraître, les API comportent également des compromis. La première est que choisir une API est un engagement assez sérieux. Il n'y a pas de norme d'intégration globale, donc chaque service Lightning définit son côté de l'API à sa guise, et le service Web devra construire son UX autour de l'API. Le passage à une autre API pourrait être très coûteux et entraîner des modifications importantes de l'UX et de l'architecture globale.

Une considération majeure lors du choix du service Lightning et de l'API qui convient à l'application Web ou mobile est de savoir s'il faut sélectionner une solution auto-hébergée comme Serveur BTCPay, LNPay or LNbits, ou une solution de garde comme ZÉBÉDÉE or grève. Encore une fois, des compromis s'appliquent.

• Les solutions auto-hébergées vous donnent un contrôle total sur vos fonds mais nécessitent une maintenance sous forme de gestion des canaux, des soldes, de la connectivité, de la conformité réglementaire, de la disponibilité du serveur, etc.
• Les solutions de garde vous déchargent d’une grande partie de la maintenance, mais vous devrez faire confiance au dépositaire pour conserver votre argent (et si vous êtes prêt à le faire, vous n’avez pas vraiment besoin de Lightning en premier lieu). De plus, les services de garde n'opèrent dans certaines juridictions que pour leur propre conformité et ces limitations géographiques s'appliquent naturellement également aux services qui les utilisent en aval.

Mais quelles que soient leurs vertus dans la philosophie Bitcoiner, les deux approches fonctionnent. Fontaine permet aux utilisateurs de diffuser des sats vers leurs podcasteurs préférés tout en écoutant et ils hébergent leur propre nœud avec LNPay. De la même manière, le côté Lightning de La fonction de pourboire de Twitter fonctionne sur l'API de Strike, donc je suppose qu'une grande entreprise publique (ou est-ce juste Elon ?) Est à l'aise avec son service de garde.

Choisissez ce qui vous convient.

LNC

La gestion des nœuds impliquée dans une solution auto-hébergée peut sembler un frein. Mais imaginez que vous puissiez le faire dans une interface de navigateur pratique, en gérant les canaux et les soldes de votre nœud Lightning comme vous le feriez pour gérer vos factures et vos comptes sur un site Web bancaire en ligne. Imaginez maintenant offrir ce genre de fonctionnalité à vos utilisateurs. Le monde devient votre huître fintech compatible Lightning. Et Connexion de nœud Lightning (LNC) est la perle.

Comme je l'ai dit plus haut, les navigateurs sont essentiellement des systèmes d'exploitation en bac à sable. LNC applique WebAssembly pour tirer parti de cet attribut pour Lightning. LNC permet essentiellement une gestion complète des nœuds à distance via un navigateur. Permettre aux utilisateurs d'accéder à leurs nœuds et de les contrôler via leur navigateur offre aux développeurs Web une flexibilité fantastique dans la façon dont ils élaborent l'UX de leurs sites et ouvre la porte à une gamme d'applications potentiellement lucratives.

LNC permet d'accéder à l'interface gRPC (grpc remote procedure call) du nœud, afin que les opérateurs puissent ouvrir, fermer et rééquilibrer les canaux en plus d'autres fonctions avancées. Borne Web Lightning est un bon exemple de ce à quoi cela peut ressembler dans la pratique. Ce terminal est essentiellement une télécommande pour les nœuds des utilisateurs avancés auxquels ils peuvent accéder n'importe où.

Quel est le piège? Il y en a deux. Tout d'abord, LNC est une idée originale de Lightning Labs et ne fonctionne qu'avec LND pour l'instant. Deuxièmement, plus vous avez de contrôle sur votre nœud depuis l'extérieur, plus vous devrez accorder d'autorisations à cette interface extérieure ; et plus vous accordez d'autorisations, plus votre surface d'attaque peut être grande. Lightning Labs répertorie un certain nombre de menaces potentielles eux-mêmes, y compris les humains ayant accès au démon, les tentatives de phishing, les vulnérabilités du navigateur et les extensions tierces. Bien que les techniciens de Lightning Labs soient des ingénieurs sérieux, toute application dotée d'autorisations aussi étendues peut être une invitation à se faire "pwner".

LSAT

Jetons d'authentification Lightning Service (LSAT) sont le dernier moyen d'intégrer Lightning au Web dont nous parlerons. Non, ce n'est pas un moyen de vérifier qui est assez ennuyeux pour devenir un avocat. L'idée de base derrière les LSAT est d'utiliser soigneusement défini macarons pour authentifier l'utilisateur et définir ses capacités de paiement sur le site.

Habilement, le protocole LSAT utilise le code HTTP 402 qui est un code d'erreur côté client signifiant soit "Paiement RequisouRéservé pour une utilisation future", selon à qui vous demandez (la spécification LSAT de Lightning Labs, mais paradoxalement, déclare "ce document suppose que le futur est arrivé"). Ce code 402 est utilisé pour invoquer un "ticket" - un macaron qui identifie simultanément l'utilisateur et définit comment cet utilisateur peut interagir avec le service.

Le premier avantage résultant des LSAT est que l'authentification et les autorisations de paiement se produisent en une seule étape. Le service reconnaît l'utilisateur et comment les paiements vers et depuis cet utilisateur sont censés fonctionner dès qu'ils apparaissent. Aucun nom d'utilisateur, mot de passe ou montant de réglage à chaque visite. Parfois c'est juste agréable d'être familier.

Deuxièmement, ces API peuvent spécifier des paiements mesurés, tout comme les sats de streaming dans le Lecteur de podcast Breez (même si nous utilisons envoi de clés Au lieu). C'est une autre façon de éviter les abonnements. Les utilisateurs peuvent payer pour ce qu'ils utilisent - qu'il s'agisse de podcast audio, de vidéo en streaming, de jeu, de média textuel - par n'importe quelle unité ou intervalle, jusqu'à la seconde.

Les LSAT ont un grand potentiel et pourraient peut-être même bannir les bots des réseaux sociaux en facturant des micropaiements pour des microinteractions qui seraient anodines pour les utilisateurs mais prohibitives pour les bots.

Super! Une technologie révolutionnaire qui interdit les robots et intègre Lightning et le Web ! Alléluia! Quel est le piège? Je ne sais pas, mais je n'arrive pas à comprendre comment les LSAT existent depuis quelques années et pourtant je ne peux pas nommer un seul service majeur qui les a mis en œuvre. Est-ce juste une question d'effets de réseau et tout le monde attend que tout le monde saute le pas ? Ou y a-t-il une inhibition plus profonde, plus substantielle ? Peut-être que vous, cher lecteur, pouvez m'éclairer sur celui-là.

Le futur est une extension du présent

Certains disent que le Web3 est l’avenir, et cela semble avoir quelque chose à voir avec la cryptographie… et un réseau… et il y a probablement aussi des folies DeFi quelque part. Je ne sais pas et je ne suis pas sûr que quelqu’un d’autre le sache non plus. Ce que je sais, c’est que l’avenir appartient au Bitcoin, que Lightning est la technologie qui liquéfie le Bitcoin et que nous disposons d’un World Wide Web fonctionnel que tout le monde aime et veut conserver.

N'est-il pas évident que Lightning est destiné à pénétrer le Web et que le Web est destiné à utiliser Lightning comme principale technologie de paiement ? Ou est-ce juste moi?

L'intégration de Lightning et du Web était autrefois une perspective intimidante, mais ce n'est plus le cas. Nous disposons d’une gamme de technologies pour une large gamme de cas d’utilisation, d’une communauté florissante de développeurs qui innovent et perfectionnent la technologie, et d’un monde qui aime déjà le Web et qui est de plus en plus friand de Bitcoin.

Mieux encore, nous n'avons besoin d'aucune norme centrale pour nous dire comment intégrer Lightning et le Web. Chacun peut choisir la technologie qui convient le mieux à ses besoins locaux et travailler avec la communauté du développement pour l'aider à s'améliorer. Le nouveau Web compatible Lightning se développera de manière organique à partir de zéro, comme il se doit.

Ceci est un article invité de Roy Sheinfeld. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc. ou Magazine Bitcoin.

• Coinsmart. Le meilleur échange Bitcoin et Crypto d'Europe.
• Platoblockchain. Intelligence métaverse Web3. Connaissance amplifiée. ACCÈS LIBRE.
• CryptoHawk. Radar Altcoins. Essai gratuit.
• Source : https://bitcoinmagazine.com/technical/how-lightning-can-integrate-with-the-web