Lightning For Life – Hvordan Lightning kan og vil integreres med nettet

Lightning er klar til å sømløst integreres i vår daglige drift omtrent på samme måte som internett har gjort.

Roy Sheinfeld er medgründer og administrerende direktør i Breez, et Bitcoin-selskap med fokus på Lightning-betalinger.

Hver gang du googler noe, hver gang du tuller, gjør seriøs research på YouTube eller Instagram, hver gang du bestiller en Uber, hver gang du sjekker porteføljen din eller leser nyhetene, bruker du nettet. Faktisk bruker du nettet akkurat nå og leser dette. Nettet er et verktøy, men det er et verktøy på samme måte som lunger eller tomler er verktøy; det har blitt en integrert del av oss som vi bruker konstant uten å tenke på det.

Penger er lik ved at vi bruker dem konstant og ubevisst. Så lenge kjøleskapet ditt går, så lenge midlene dine påløper renter et sted, så lenge gjeldsklokken på lånet ditt tikker, er du involvert i finansiell aktivitet. Ditt økonomiske selv er våkent og opprettholder sin posisjon i det globale verdinettverket, selv mens du sover.

Bitcoinere har en tendens til å være svært oppmerksomme på denne typen ting. Hvis du bruker Lightning, ser du sannsynligvis på det som en kanal mellom deg og det globale verdinettverket. Det er ikke bare en måte å kjøpe en øl i Helsinki; Lynet kobler deg til havet av Bitcoin.

Rart nok opererer disse to viktige nettverkene - nettet og Lightning - fortsatt parallelt med liten integrasjon. Vi ønsker ikke å leve uten noen av dem, men sømmene mellom dem er til å ta og føle på, noen ganger vanskelige.

Som jeg lærte på bolt.morsom hackathon (shoutout til min mann Johns!), mange webutviklere ville elske å bygge apper med Lightning-funksjonalitet. Viljen til å integrere er der ute, men mange ser ikke ut til å innse at det er en måte også. Faktisk er det flere måter å bringe Lightning til nettet på, og hver av dem utvikler seg med sine egne styrker og bruksområder. Kanskje verden bare ikke vet om eller forstår dem?

Så la oss gjøre det. La oss se på hvordan du integrerer nettet og Lightning, trekker trådene ut, vever dem sammen og lager et sterkere, kombinert, sømløst nett.

LNURL: Holde det enkelt

Lightning-brukeropplevelsen (UX) har kommet langt siden jeg først dekket det tre år siden. Men hull gjenstår. Fakturaer er ett eksempel. Teknisk sett er det kun betalingsmottakeren som kan sette i gang en betaling, noe som er upassende i mange sammenhenger. Mange brukere vil kanskje ikke generere en faktura uansett årsak, og i scenarier som tipping kan det med rimelighet fremstå som tungvint og frekt.

LNURL er et veldig enkelt sett med spesifikasjoner for å bygge bro over noen av disse gjenværende UX-gapene, inkludert fakturagenerering. Det fine med LNURL er dens enkelhet. Som navnet antyder, er LNURL-spesifikasjonene basert på lenker, enten i form av klikkbare URL-er eller skannbare QR-koder. URL-lenker er en del av vår teknologiske bakgrunn. Du har allerede sett fire i dette innlegget, sannsynligvis uten å legge merke til dem. QR-koder er det samme, bare en annen visuell representasjon:

Det finnes flere LNURL spesifikasjoner der ute, men disse er spesielt relevante for Lightnings nettintegrering:

• LNURL-Pay: La oss si at du driver en Bitcoin-blogg. Du vil samle inn tips, men du vil ikke generere og gjengi en faktura for hvert tips, og du vil heller ikke samhandle med hver enkelt leser for hvert tips. LNURL-Pay lar deg generere QR-koder for betalinger innenfor et spesifisert område, for eksempel 2,500 10,000 – XNUMX XNUMX sats. En bruker kan ganske enkelt skanne en kode, angi det nøyaktige beløpet og betale. Brukeren forblir uvitende om språket til forhåndsbilder og fakturaer, i stedet skanner han bare en kode og svarer på en melding.
• LNURL-Trekk tilbake: Dette er det omvendte scenarioet: du vil betale brukere for samhandling med nettstedet ditt, men du vil spare dem for bryet med å generere en faktura. LNURL-Withdraw lar brukere skanne en kode eller klikke på en lenke som vil be lommeboken deres om å generere riktig type faktura og sende den til noden din for betaling.
• LNURL-Auth er et annet kult LNURL-verktøy. Den genererer et offentlig-privat nøkkelsett basert på frøsetningene i brukernes lommebøker for å la dem logge på nettsteder pseudonymt. Den er like privat som selve frøsetningen og vanskeligere å brutal enn "passord123" eller "correct_horse_battery_staple." Det beste av alt er at den bruker data som allerede finnes i brukernes lommebøker, klar til bruk med lite input.

Lynadresser

E-post er kanskje så kjent at vi tar fordelene for gitt. E-postadresser er strengt unike (i motsetning til fingeravtrykk), og e-post gjør det ekstremt enkelt å sende og motta informasjon til nøyaktig rett person. Lynadresser har samme xxx@yyy.zzz-format som e-post, men de lar brukere overføre penger uten å måtte rote med en QR-kode.

Foreløpig er LNURL-Pay den mest populære måten å implementere Lightning Addresses på, men Lightning Address-protokollen er åpen for innovasjon. For eksempel kan Lightning-adresser utvides til å bruke statiske fakturaer eller BOLT12 (Basis for Lightning Technology; Lightning-ekvivalenten til spesifikasjonene for Bitcoin Improvement Proposal [BIP]), når disse er tatt i bruk.

Selv i sin nåværende form basert på LNURL, er Lightning Addresses veldig populære og enkle å integrere. Faktisk inkluderer flere apper Lightning-adresser naturlig, men det er også ikke-forvarende broservere tilgjengelig for de med sine egne noder som ikke har noe imot litt konfigurasjon, og det er instruksjoner for et fullstendig selvhostet oppsett med ditt eget domenenavn.

For å virkelig gjøre Lightning Addresses til en suksess, må vi finne ut hvordan vi kan aktivere mobillommebøker som ikke er forvaring motta mens du er frakoblet.

WebLN

WebLN starter fra en enkel premiss: mesteparten av tiden når vi samhandler med nettet, gjør vi det gjennom en nettleser. Nettlesere er praktisk talt små operativsystemer i seg selv, som kan kjøre all slags kul programvare i sine egne miljøer.

Gitt at Lightning bare er programvare og at vi ønsker å integrere det med nettet, vil det gå langt å legge Lightning til nettlesere.

Dette er nettopp ideen bak WebLN, som er et enkelt JavaScript-verktøy for å bygge Lightning-aktiverte nettleserutvidelser ved å bruke makePayment og sendInvoice - igjen, de to kjernefunksjonene for enhver form for penger: sending og mottak. Med andre ord lar WebLN nettapper samhandle med Lightning-lommebøker.

WebLN tilbyr noen fordeler. For det første er JavaScript nesten universelt og nesten tretti år gammelt. Vi er ganske sikre på at det fungerer. For det andre er WebLN enkelt. Hvor enkelt? Michael Bumann fra Alby kan sette den opp og demonstrere hvordan du bruker den på fem minutter og trettiåtte sekunder.

Link til YouTube-video her.

For det tredje leverer WebLN en mye bedre UX enn QR-koder, og starter med det faktum at du ikke trenger å bruke en annen enhet. Det føles naturlig, ikke som en løsning. Du har også tilgang til alle nettleserhendelser, så et tastetrykk, et museklikk, et rulleposisjon, etc. kan alle utløse en betaling. QR-fri UX er spesielt nyttig på mobil der WebLN også fungerer.

Likevel er ikke WebLN et universelt web-to-Lightning-grensesnitt. Det krever et WebLN-aktivert miljø. På en stasjonær nettleser kan en enkel utvidelse, som Alby, skape det miljøet. På mobil kan utviklere enten utarbeide sin egen WebLN-løsning eller finne et hjem i en Lightning-app som allerede tilbyr et innebygd WebLN-miljø, som f.eks. bris og BlueWallet. Kanskje det faktum at WebLN ikke er hjemmehørende i nettlesere har forhindret eller bremset den utbredte bruken. Jeg kan se en fremtid der WebLN-verter implementeres naturlig på nettsteder som bruker WebAssembly, fjerning av sømmene for sluttbrukere.

For mange enkle nettleserbaserte transaksjoner, som tipping og engangskjøp, er WebLN alt du trenger for å integrere våre to favorittnettverk. Det fungerer så bra at mange av de beste Lightning-tjenestene har brukt det med suksess i årevis. Det inkluderer bitrefill, LNMarketsog Kollider.

APIer

Når det gjelder å integrere en webtjeneste og en Lightning-tjeneste sømløst, er det vanskelig å slå et applikasjonsprogrammeringsgrensesnitt (API) designet for å gjøre nettopp det. API-integrasjon gir utviklere den største kontrollen over brukeropplevelsen og grensesnittet.

Så bra som det høres ut, kommer APIer også med avveininger. Den første er at å velge en API er en ganske seriøs forpliktelse. Det er ingen overordnet integrasjonsstandard, så hver Lightning-tjeneste definerer sin side av API-en som den vil, og nettjenesten må bygge sin UX rundt API-en. Å bytte til et annet API kan være svært kostbart og innebære betydelige endringer i brukeropplevelsen og den generelle arkitekturen.

En viktig vurdering når du velger hvilken Lightning-tjeneste og hvilken API som er riktig for hvilken nett- eller mobilapp er om du skal velge en selvhostet løsning som BTCPay-server, LNPay or LNbits, eller en varetektsløsning som SEBEDE or Streik. Igjen gjelder avveininger.

• Selvvertsbaserte løsninger gir deg full kontroll over midlene dine, men de krever vedlikehold i form av administrasjon av kanaler, saldoer, tilkobling, regeloverholdelse, serveroppetid, etc.
• Forvaringsløsninger tar mye av vedlikeholdet fra hendene dine, men du må stole på at depotmottakeren holder pengene dine (og hvis du er villig til å gjøre det, trenger du egentlig ikke Lightning i utgangspunktet). Dessuten opererer forvaringstjenester kun i visse jurisdiksjoner for deres egen etterlevelse, og disse geografiske begrensningene gjelder naturligvis også tjenester som bruker dem nedstrøms.

Men uansett deres dyder i Bitcoiner-filosofien, fungerer begge tilnærmingene. Fontene lar brukere streame sats tilbake til favorittpodcasterne mens de lytter, og de er vert for sin egen node med LNPay. På samme måte, Lyn-siden av Twitters tippefunksjon fungerer på Strikes API, så jeg antar at et stort offentlig selskap (eller er det bare Elon?) er komfortabel med forvaringstjenesten deres.

Velg det som er riktig for deg.

LNC

Nodeadministrasjonen som er involvert i en selvvertsbasert løsning kan høres ut som et drag. Men forestill deg at du kan gjøre det i et hendig nettlesergrensesnitt, og administrere kanalene og saldoene til Lightning-noden din, akkurat som du ville administrere regningene og kontoene dine på et nettbanknettsted. Tenk deg nå å tilby den typen funksjonalitet til brukerne dine. Verden blir din Lyn-aktiverte fintech-østers. Og Lightning Node Connect (LNC) er perlen.

Som jeg sa ovenfor, er nettlesere i utgangspunktet sandkasseoperativsystemer. LNC bruker WebAssembly for å utnytte denne egenskapen for Lightning. LNC gir i utgangspunktet full, ekstern nodeadministrasjon gjennom en nettleser. Å la brukere få tilgang til og kontrollere nodene sine gjennom nettleseren gir nettutviklere fantastisk fleksibilitet i hvordan de lager sine nettsteders UX og åpner døren til en rekke potensielt lukrative applikasjoner.

LNC gir tilgang til nodens gRPC (grpc remote procedure call) grensesnitt, slik at operatører kan åpne, lukke og rebalansere kanaler i tillegg til andre avanserte funksjoner. Lightning Web Terminal er et godt eksempel på hvordan det kan se ut i praksis. Denne terminalen er i utgangspunktet en fjernkontroll for strømbrukeres noder som de kan få tilgang til hvor som helst.

Hva er fangsten? Det er to. For det første er LNC ideen til Lightning Labs og fungerer bare med LND foreløpig. For det andre, jo mer kontroll du har over noden din utenfra, jo flere tillatelser må du gi til det eksterne grensesnittet; og jo flere tillatelser du gir, desto større kan angrepsoverflaten din være. Lightning Labs viser en rekke potensielle trusler seg selv, inkludert mennesker med tilgang til demonen, phishing-forsøk, nettlesersårbarheter og tredjepartsutvidelser. Mens teknologifolkene ved Lightning Labs er seriøse ingeniører, kan enhver app med så omfattende tillatelser være en invitasjon til å bli «pwned».

LSAT-er

Lyntjenestegodkjenningstokener (LSAT-er) er det siste middelet for å integrere Lightning med nettet som vi vil diskutere. Nei, de er ikke en måte å sjekke hvem som er irriterende nok til å bli en advokat. Den grunnleggende ideen bak LSAT-er er å bruke nøye definerte makroner for å autentisere brukeren og definere deres betalingsmuligheter på nettstedet.

smart, LSAT-protokollen bruker HTTP-kode 402 som er en feilkode på klientsiden som betyr enten "betaling kreves"Eller"reservert for fremtidig bruk", avhengig av hvem du spør (Lightning Labs LSAT-spesifikasjonen sier utrolig, men paradoksalt nok "dette dokumentet antar at fremtiden har kommet"). Denne 402-koden brukes til å påkalle en "billett" - en makron som samtidig identifiserer brukeren og definerer hvordan denne brukeren kan samhandle med tjenesten.

Den første fordelen med LSAT-er er at autentisering og betalingstillatelser skjer i ett enkelt trinn. Tjenesten gjenkjenner brukeren og hvordan betalinger til og fra denne brukeren skal fungere så snart de dukker opp. Ingen brukernavn, passord eller innstillingsbeløp ved hvert besøk. Noen ganger er det det bare hyggelig å bli kjent.

For det andre kan disse API-ene spesifisere målte betalinger, akkurat som streaming-satsene i Breez podcastspiller (selv om vi bruker nøkkelsending i stedet). Dette er en annen måte å unngå abonnement. Brukere kan betale for det de bruker – enten det er podcast-lyd, streaming av video, spill, tekstbaserte medier – uansett enhet eller intervall, helt ned til det andre.

LSAT-er har stort potensial og kan kanskje til og med forvise roboter fra sosiale medier ved å belaste mikrobetalinger for mikrointeraksjoner som ville være trivielle for brukere, men uoverkommelige for roboter.

Høres bra ut! Revolusjonerende teknologi som forbyr bots og integrerer Lightning og nettet! Halleluja! Hva er fangsten? Jeg vet ikke, men jeg kan ikke finne ut hvordan LSAT-er har eksistert i noen år, og likevel kan jeg ikke nevne en eneste større tjeneste som har implementert dem. Er det bare et spørsmål om nettverkseffekter og alle venter på at alle andre skal ta skrittet fullt ut? Eller er det en dypere, mer betydelig hemning? Kanskje du, kjære leser, kan utdanne meg om det.

Fremtiden er en forlengelse av nåtiden

Noen sier at web3 er fremtiden, og det ser ut til å ha noe å gjøre med krypto ... og et nettverk ... og det er sannsynligvis noe DeFi-tulleri der inne også. Jeg vet ikke, og jeg er ikke sikker på at noen andre gjør det heller. Det jeg vet er at fremtiden tilhører Bitcoin, at Lightning er teknologien som gjør bitcoin flytende, og at vi har et fungerende World Wide Web som alle elsker og ønsker å beholde.

Er det ikke åpenbart at Lightning er bestemt til å trenge inn på nettet og at nettet er bestemt til å bruke Lightning som sin ledende betalingsteknologi? Eller er det bare meg?

Å integrere Lightning og nettet var en gang et skremmende prospekt, men ikke lenger. Vi har en rekke teknologier for en rekke bruksområder, et blomstrende fellesskap av utviklere som innoverer og perfeksjonerer teknologien, og en verden som allerede elsker nettet og stadig blir mer glad i bitcoin.

Kanskje det beste av alt, vi trenger ingen sentral standard for å fortelle oss hvordan vi integrerer Lightning og nettet. Alle kan velge den teknologien som passer best for deres lokale behov og samarbeide med utviklingsfellesskapet for å hjelpe den med å bli bedre. Den nye Lightning-aktiverte nettet vil vokse organisk fra grunnen av, som den skal.

Dette er et gjesteinnlegg av Roy Sheinfeld. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis de til BTC Inc. eller Bitcoin Magazine.

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• Kilde: https://bitcoinmagazine.com/technical/how-lightning-can-integrate-with-the-web