Hvordan Lightning kan og vil integreres med internettet

Beregnet lesetid: 10 minutter

Forfatter: Roy Sheinfeld | Utgitt: 26/05/22 | Original: Lightning For Life — How Lightning Can And Will Integrate With The Web

---

Hver gang du googler noe, hver gang du 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 likt ved at vi bruker dem konstant og ubevisst. Så lenge kjøleskapet ditt går, så lenge pengene 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 på i Helsinki; Lightning kobler deg til havet av Bitcoin.

Rart nok opererer disse to viktige nettverkene – internettet og Lightning – fortsatt parallelt med lite integrasjon. Vi ønsker ikke å leve uten noen av dem, men sømmene mellom dem er merkbare, noen ganger klumsete.

Som jeg lærte på bolt.fun hackathon, vil mange utviklere 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?

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: Hold det enkelt

Lightning-brukeropplevelsen (UX) har kommet langt siden jeg først dekket det for 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 å gi tips kan det med rimelighet fremstå som tungvint og frekt.

LNURL er et veldig enkelt sett med spesifikasjoner for å bygge en 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 fem i dette innlegget, sannsynligvis uten å legge merke til dem. QR-koder er det samme, bare en annen visuell representasjon:

Det er flere LNURL-spesifikasjoner der ute, men disse er spesielt relevante for Lightning sin nettintegrering:

• LNURL-Pay: La oss si at du driver en Bitcoin-blogg. Du vil samle inn donasjoner, men du vil ikke generere og gjengi en faktura for hver donasjon, og du vil heller ikke samhandle med hver enkelt leser for hver donasjon. LNURL-Pay lar deg generere QR-koder for betalinger innenfor et spesifisert område, for eksempel 2 500 – 10 000 sats. En bruker kan ganske enkelt skanne en kode, angi det nøyaktige beløpet og betale. Brukeren forblir uvitende om fakturaer, i stedet skanner han bare en kode og bekrefter.
• LNURL-Withdraw: Dette er det omvendte scenarioet: du vil betale brukere for å samhandle 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å seed phrases i brukernes lommebøker for å la dem logge inn på nettsteder pseudonymt. Det er like privat som selve seed phrase’n og vanskeligere å brute force 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.

WebLN

WebLN tar utgangspunkt i et enkelt 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 på 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.

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, ved å scrolle, osv. 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 bruke en Lightning-app som allerede tilbyr et innebygd WebLN-miljø, som Breez 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, og fjerner sømmene for brukere.

For mange enkle nettleserbaserte transaksjoner, som å gi tips 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, LNMarkets og Kollider.

APIer

Når det gjelder å integrere en webtjeneste og en Lightning-tjeneste sømløst, er det vanskelig å slå et programmeringsgrensesnitt (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 det å 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 en annen 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 din nett- eller mobilapp, er om du skal velge en selvhostet løsning som BTCPay Server, LNPay eller LNbits, eller en depotløsning som ZEBEDEE eller Strike. Igjen gjelder avveininger.

• Selvhostet løsninger gir deg full kontroll over midlene dine, men de krever vedlikehold i form av administrasjon av kanaler, saldoer, tilkobling, regeloverholdelse, serveroppetid, osv.
• Depotlø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 depotløsninger bare i visse jurisdiksjoner, og de geografiske begrensningene gjelder naturligvis også tjenestene som bruker dem.

Men uansett hvor du ligger i Bitcoiner-filosofien, fungerer begge tilnærmingene. Fountain lar brukere streame sats til favorittpodcasterne mens de lytter, og de bruker sin egen node med LNPay. På samme måte fungerer Lightning-siden av Twitter sin tippefunksjon på Strike sin API, så jeg antar at et stort offentlig selskap (eller er det bare Elon?) er komfortabel med depotløsningene deres.

Velg det som er riktig for deg.

LNC

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

Som jeg sa ovenfor, er nettlesere i utgangspunktet små operativsystemer. 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 UX-en til sidene sine 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 brukeres noder som de kan få tilgang til hvor som helst.

Hva er haken? 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 lister opp en rekke potensielle trusler selv, inkludert mennesker med tilgang til daemon, 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

Lightning Service Authentication Tokens (LSAT-er) er det siste middelet for å integrere Lightning med nettet som vi vil diskutere. Nei, det 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 macaroons for å autentisere brukeren og definere betalingsmulighetene deres på nettstedet.

På en smart måte bruker LSAT-protokollen HTTP-kode 402, som er en feilkode på klientsiden som betyr enten «betaling kreves» eller «reserveres for fremtidig bruk«, avhengig av hvem du spør (Lightning Labs LSAT-spesifikasjonen, utrolig, men paradoksalt nok, sier «dette dokumentet antar at fremtiden har ankommet»). Denne 402-koden brukes til å påkalle en «billett» – en macaroon 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 beløp trengs å oppgis ved hvert besøk. Noen ganger er det bare hyggelig å være kjent.

For det andre kan disse API-ene spesifisere betalinger, akkurat som streaming-sats i Breez-podcastspilleren (selv om vi bruker keysend i stedet). Dette er en annen måte å unngå abonnementer på. 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 sekundet.

LSAT-er har et stort potensial og kan kanskje til og med fjerne 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 med nettet! Halleluja! Hva er haken? 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 stor 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 hindring? 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 å gjøre… 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 vet 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 nå 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 enhet 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 til å bli bedre. Det nye Lightning-aktiverte nettet vil vokse organisk fra grunnen av, som den bør.

Dette er et gjesteinnlegg skrevet av Roy Sheinfeld. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til Bitcoinplassen.