Lightning For Life — Hur Lightning kan och kommer att integreras med webben

Lightning är redo att sömlöst integreras i vår dagliga verksamhet ungefär på samma sätt som internet har gjort.

Roy Sheinfeld är medgrundare och VD för Breez, ett Bitcoin-företag fokuserat på Lightning-betalningar.

Varje gång du googlar på något, varje gång du lurar gör seriös research på YouTube eller Instagram, varje gång du beställer en Uber, varje gång du kollar din portfölj eller läser nyheterna, använder du webben. Faktum är att du använder webben just nu och läser detta. Nätet är ett verktyg, men det är ett verktyg på samma sätt som lungor eller tummar är verktyg; det har blivit en integrerad del av oss som vi använder ständigt utan att ens tänka på det.

Pengar är liknande genom att vi använder dem konstant och omedvetet. Så länge ditt kylskåp är igång, så länge som dina pengar drar på sig ränta någonstans, så länge som skuldklockan på ditt lån tickar, är du involverad i finansiell aktivitet. Ditt ekonomiska jag är vaket och behåller sin position i det globala nätverket av värde, även när du sover.

Bitcoiners tenderar att vara mycket medvetna om den här typen av saker. Om du använder Lightning ser du det förmodligen som en kanal mellan dig och det globala nätverket av värde. Det är inte bara ett sätt att köpa en öl i Helsingfors; Blixten kopplar dig till havet av Bitcoin.

Konstigt nog fungerar dessa två viktiga nätverk – webben och Lightning – fortfarande parallellt med liten integration. Vi vill inte leva utan någon av dem, men sömmarna mellan dem är påtagliga, ibland besvärliga.

Som jag lärde mig på bolt.roligt hackathon (shoutout till min man Johns!), många webbutvecklare skulle älska att bygga appar med Lightning-funktionalitet. Viljan att integrera finns där ute, men många verkar inte inse att det också finns ett sätt. Faktum är att det finns flera sätt att föra Lightning till webben och var och en utvecklas med sina egna styrkor och användningsfall. Kanske världen helt enkelt inte känner till eller förstår dem?

Så låt oss göra det. Låt oss titta på hur man integrerar nätet och Lightning, drar ut trådarna, väver ihop dem och gör ett starkare, kombinerat, sömlöst nät.

LNURL: Att hålla det enkelt

Lightning-användarupplevelsen (UX) har kommit långt sedan jag först täckte det tre år sedan. Men luckor kvarstår. Fakturor är ett exempel. Tekniskt sett är det bara betalningsmottagaren som kan initiera en betalning, vilket är olämpligt i många sammanhang. Många användare kanske inte vill generera en faktura av någon anledning och, i scenarier som dricks, kan det rimligen framstå som besvärligt och oförskämt.

LNURL är en mycket enkel uppsättning specifikationer för att överbrygga några av dessa återstående UX-luckor, inklusive fakturagenerering. Det fina med LNURL är dess enkelhet. Som namnet antyder är LNURL-specifikationer baserade på länkar, antingen i form av klickbara webbadresser eller skanningsbara QR-koder. URL-länkar är en del av vår tekniska bakgrund. Du har redan sett fyra i det här inlägget, förmodligen utan att ens märkt dem. QR-koder är samma sak, bara en annan visuell representation:

Det finns flera LNURL specifikationer där ute, men dessa är särskilt relevanta för Lightnings webbintegration:

• LNURL-Pay: Låt oss säga att du driver en Bitcoin-blogg. Du vill samla in tips men du vill inte generera och rendera en faktura för varje tips, och du vill inte heller interagera med varje läsare individuellt för varje tips. LNURL-Pay låter dig generera QR-koder för betalningar inom ett specificerat intervall, till exempel 2,500 10,000 – XNUMX XNUMX sats. En användare kan helt enkelt skanna en kod, ange det exakta beloppet och betala. Användaren förblir omedveten om språket i förbilder och fakturor, istället skannar han bara en kod och svarar på en uppmaning.
• LNURL-Återkalla: Det här är det omvända scenariot: du vill betala användare för att interagera med din webbplats, men du vill bespara dem besväret med att skapa en faktura. LNURL-Withdraw låter användare skanna en kod eller klicka på en länk som kommer att uppmana deras plånböcker att generera lämplig typ av faktura och skicka den till din nod för betalning.
• LNURL-Auth är ett annat coolt LNURL-verktyg. Det genererar en offentlig-privat nyckeluppsättning baserat på frönfraserna i användarnas plånböcker för att låta dem logga in på webbplatser pseudonymt. Det är lika privat som själva fröfrasen och svårare att brutal än "lösenord123" eller "correct_horse_battery_staple.” Det bästa av allt är att den använder data som redan finns i användarnas plånböcker, redo att användas med lite input.

Lightning adresser

E-post är kanske så bekant att vi tar dess fördelar för givna. E-postadresser är strikt unika (till skillnad från fingeravtryck), och e-post gör det extremt enkelt att skicka och ta emot information till exakt rätt person. Lightning adresser har samma format xxx@yyy.zzz som e-post, men de tillåter användare att överföra pengar utan att behöva bråka med en QR-kod.

För närvarande är LNURL-Pay det mest populära sättet att implementera Lightning Addresses men Lightning Address-protokollet är öppet för innovation. Till exempel kan Lightning-adresser utökas till att använda statiska fakturor eller BOLT12 (Bas of Lightning Technology; Lightning-motsvarigheten till specifikationerna för Bitcoin Improvement Proposal [BIP]), när dessa har antagits.

Även i sin nuvarande form baserad på LNURL är Lightning Addresses mycket populära och lätta att integrera. Faktum är att flera appar inkluderar Lightning-adresser inbyggt, men det finns också bryggservrar som inte är förvarsbara för de med sina egna noder som inte har något emot lite konfiguration och det finns instruktioner för en helt egen värd installation med ditt eget domännamn.

För att verkligen göra Lightning Addresses till en framgång måste vi ta reda på hur vi gör det möjligt för mobila plånböcker att ta emot när du är offline.

WebLN

WebLN utgår från en enkel utgångspunkt: för det mesta när vi interagerar med webben gör vi det via en webbläsare. Webbläsare är praktiskt taget små operativsystem i sig, som kan köra alla möjliga typer av cool programvara i sina egna miljöer.

Med tanke på att Lightning bara är mjukvara och att vi vill integrera den med webben kommer det att räcka långt med att lägga till Lightning i webbläsare.

Detta är precis idén bakom WebLN, som är ett enkelt JavaScript-verktyg för att bygga Lightning-aktiverade webbläsartillägg med makePayment och sendInvoice — återigen de två kärnfunktionerna för alla slags pengar: skicka och ta emot. Med andra ord tillåter WebLN webbappar att interagera med Lightning-plånböcker.

WebLN erbjuder några fördelar. För det första är JavaScript nästan universellt och nästan trettio år gammalt. Vi är ganska säkra på att det fungerar. För det andra är WebLN enkelt. Hur enkelt? Michael Bumann från Alby kan ställa in den och demonstrera hur man använder den på fem minuter och trettioåtta sekunder.

Länk till YouTube-video här.

För det tredje levererar WebLN en mycket bättre UX än QR-koder, till att börja med att du inte behöver använda en andra enhet. Det känns naturligt, inte som en lösning. Du har också tillgång till alla webbläsarhändelser, så en knapptryckning, ett musklick, ett rullningsläge, etc. kan alla utlösa en betalning. Den QR-fria UX är särskilt praktisk på mobilen där WebLN också fungerar.

Ändå är WebLN inte ett universellt webb-till-Lightning-gränssnitt. Det kräver en WebLN-aktiverad miljö. På en stationär webbläsare kan ett enkelt tillägg, som Alby, skapa den miljön. På mobilen kan utvecklare antingen arbeta fram sin egen WebLN-lösning eller hitta ett hem i en Lightning-app som redan erbjuder en inbyggd WebLN-miljö, som t.ex. Breez och BlueWallet. Kanske det faktum att WebLN inte är inbyggt i webbläsare har förhindrat eller bromsat dess utbredda användning. Jag kan se en framtid där WebLN-värdar implementeras inbyggt på webbplatser som använder WebAssembly, ta bort sömmarna för slutanvändare.

För många enkla webbläsarbaserade transaktioner, som dricks och engångsköp, är WebLN allt du behöver för att integrera våra två favoritnätverk. Det fungerar så bra att många av de bästa Lightning-tjänsterna har använt det framgångsrikt i flera år. Det inkluderar bitrefill, LNMarketsoch Kollider.

API: er

När det gäller att integrera en webbtjänst och en Lightning-tjänst sömlöst är det svårt att slå ett applikationsprogrammeringsgränssnitt (API) designat för att göra just det. API-integration ger utvecklare den största kontrollen över användarupplevelsen och gränssnittet.

Så bra som det låter, API:er kommer också med kompromisser. Den första är att valet av ett API är ett ganska seriöst åtagande. Det finns ingen övergripande integrationsstandard, så varje Lightning-tjänst definierar sin sida av API:et som den vill, och webbtjänsten kommer att behöva bygga sitt användargränssnitt kring API:et. Att byta till ett annat API kan vara mycket kostsamt och medföra betydande förändringar av UX och den övergripande arkitekturen.

Ett viktigt övervägande när man väljer vilken Lightning-tjänst och vilket API som är rätt för vilken webb- eller mobilapp är om man ska välja en självhostad lösning som BTCPay-server, LNPay or LNbits, eller en frihetsberövande lösning som ZEBEDÉ or Strike. Återigen gäller avvägningar.

• Självhostade lösningar ger dig full kontroll över dina pengar men de kräver underhåll i form av hantering av kanaler, saldon, anslutningar, regelefterlevnad, serverupptid, etc.
• Förvaringslösningar tar en hel del av underhållet från dina händer, men du måste lita på att vårdnadshavaren håller dina pengar (och om du är villig att göra det behöver du egentligen inte Lightning i första hand). Dessutom verkar vårdnadstjänster endast i vissa jurisdiktioner för att de ska kunna uppfylla kraven och dessa geografiska begränsningar gäller naturligtvis även för tjänster som använder dem nedströms.

Men oavsett deras förtjänster i Bitcoiner-filosofin fungerar båda tillvägagångssätten. Fontän tillåter användare att streama sats tillbaka till sina favoritpodcasters medan de lyssnar och de är värd för sin egen nod med LNPay. På samma sätt, Blixtsidan av Twitters tipsfunktion fungerar på Strikes API, så jag antar att ett stort publikt företag (eller är det bara Elon?) är bekväm med sin vårdnadstjänst.

Välj det som är rätt för dig.

LNC

Nodhanteringen som är inblandad i en självvärderad lösning kan låta som ett drag. Men tänk dig att du skulle kunna göra det i ett praktiskt webbläsargränssnitt och hantera kanalerna och saldot på din Lightning-nod precis som du skulle hantera dina räkningar och konton på en internetbankswebbplats. Tänk dig nu att erbjuda den typen av funktionalitet till dina användare. Världen blir ditt blixtaktiverade fintech-ostron. Och Lightning Node Connect (LNC) är pärlan.

Som jag sa ovan är webbläsare i grunden sandlådeoperativsystem. LNC tillämpar WebAssembly för att utnyttja det attributet för Lightning. LNC tillåter i princip fullständig, fjärrstyrd nodhantering via en webbläsare. Att låta användare komma åt och kontrollera sina noder via sin webbläsare ger webbutvecklare fantastisk flexibilitet i hur de skapar sina webbplatsers UX och öppnar dörren till en rad potentiellt lukrativa applikationer.

LNC tillåter åtkomst till nodens gRPC (grpc remote procedure call) gränssnitt, så att operatörer kan öppna, stänga och balansera om kanaler utöver andra avancerade funktioner. Lightning Web Terminal är ett bra exempel på hur det kan se ut i praktiken. Denna terminal är i grunden en fjärrkontroll för avancerade användares noder som de kan komma åt var som helst.

Vad är haken? Det finns två. För det första är LNC idén från Lightning Labs och fungerar bara med LND för tillfället. För det andra, ju mer kontroll du har över din nod utifrån, desto fler behörigheter måste du ge det externa gränssnittet; och ju fler behörigheter du ger, desto större kan din attackyta bli. Lightning Labs listar ett antal potentiella hot sig själva, inklusive människor med tillgång till demonen, nätfiskeförsök, webbläsarsårbarheter och tredjepartstillägg. Medan teknikerna på Lightning Labs är seriösa ingenjörer, kan alla appar med så omfattande behörigheter vara en inbjudan att bli "pwned".

LSAT

Lightning Service Authentication Tokens (LSAT) är det sista sättet att integrera Lightning med webben som vi kommer att diskutera. Nej, de är inte ett sätt att kolla vem som är irriterande nog att bli en advokat. Grundtanken bakom LSATs är att använda noggrant definierade macaroons för att autentisera användaren och definiera deras betalningsmöjligheter på webbplatsen.

Skickligt, LSAT-protokollet använder HTTP-kod 402 som är en felkod på klientsidan som betyder antingen "betalning krävs"Eller"reserverad för framtida bruk", beroende på vem du frågar (Lightning Labs LSAT-specifikationen häpnadsväckande, men paradoxalt nog, säger "det här dokumentet antar att framtiden har anlänt"). Den 402-koden används för att anropa en "biljett" - en makron som samtidigt identifierar användaren och definierar hur den användaren kan interagera med tjänsten.

Den första fördelen med LSATs är att autentisering och betalningsbehörigheter sker i ett enda steg. Tjänsten känner igen användaren och hur betalningar till och från den användaren ska fungera så fort de dyker upp. Inga användarnamn, lösenord eller inställningsbelopp vid varje besök. Ibland är det bara trevligt att bli bekant.

För det andra kan dessa API:er specificera mätade betalningar, precis som streamingsatsen i Breez podcastspelare (fast vi använder nyckelsänd istället). Detta är ett annat sätt att undanröja prenumerationer. Användare kan betala för vad de använder – oavsett om det är poddljud, strömmande video, spel, textbaserad media – oavsett enhet eller intervall, ända ner till andra.

LSATs har stor potential och kan kanske till och med förvisa bots från sociala medier genom att ta ut mikrobetalningar för mikrointeraktioner som skulle vara triviala för användare men oöverkomliga för bots.

Låter bra! Revolutionerande teknik som förbjuder bots och integrerar Lightning och webben! halleluja! Vad är haken? Jag vet inte, men jag kan inte lista ut hur LSAT har funnits i några år och ändå kan jag inte nämna en enda större tjänst som har implementerat dem. Är det bara en fråga om nätverkseffekter och alla väntar på att alla andra ska ta steget? Eller finns det någon djupare, mer påtaglig hämning? Kanske du, kära läsare, kan utbilda mig om det.

Framtiden är en förlängning av nuet

En del säger att web3 är framtiden, och det verkar ha något att göra med krypto... och ett nätverk... och det finns förmodligen en del DeFi-foolery där någonstans också. Jag vet inte och jag är inte säker på att någon annan gör det heller. Vad jag vet är att framtiden tillhör Bitcoin, att Lightning är tekniken som gör bitcoin flytande och att vi har en fungerande World Wide Web som alla älskar och vill behålla.

Är det inte uppenbart att Lightning är avsett att penetrera webben och att webben är avsett att använda Lightning som sin ledande betalningsteknik? Eller är det bara jag?

Att integrera Lightning och webben var en gång en skrämmande möjlighet, men inte längre. Vi har en rad teknologier för en rad olika användningsfall, en blomstrande gemenskap av utvecklare som förnyar och fulländar tekniken, och en värld som redan älskar webben och som blir allt mer förtjust i bitcoin.

Kanske bäst av allt, vi behöver ingen central standard för att berätta hur vi integrerar Lightning och webben. Alla kan välja den teknik som bäst passar deras lokala behov och arbeta med utvecklingsgemenskapen för att hjälpa den att förbättras. Den nya Lightning-aktiverade webben kommer att växa organiskt från grunden, som den ska.

Detta är ett gästinlägg av Roy Sheinfeld. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis BTC Inc. eller Bitcoin Magazine.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://bitcoinmagazine.com/technical/how-lightning-can-integrate-with-the-web