¶ Intro
Nodesignal, deine Bitcoin-Frequenz. Herzlich willkommen beim Nodesignal TechBoost, eurer Bitcoin-Frequenz. Wir haben ein paar spannende Nodes im Netzwerk gefunden, oder ich habe ein paar spannende Nodes im Netzwerk gefunden. Das ist auf der linken Seite der liebe Calso. Hi Calso. Hallo und Abend. Hi hi. Und der Jan-Paul ist noch nicht da, der kommt vielleicht gleich noch nach.
Aber wir haben einen wundervollen Gast bei uns im TechBoost und das ist der Bumi, der ganz kurzfristig heute eingesprungen ist. Hallo Bumi, schön, dass du da bist. Hallo zusammen, freut mich hier zu sein. Grüß dich. Super. Bevor wir anfangen, wie es üblich ist, der Gast kann uns gerne die Blockzeit nennen, sofern du sie hast. Die Blockzeit ist die 857655. Das sehe ich genauso. Ich glaube, wir schauen auf denselben mempool.space. Keiner hier eine eigene Node am Start, um das zu verifizieren.
Wie sieht es bei dir aus? Ja, bei mir auf meiner lokalen Node sieht es super aus. Da ist genau die gleiche Blockzeit wie bei euch. Also scheint es doch zu funktionieren mit der Synchronisation. Ja, da haben wir einen Konsens. Alrighty, ja, wir sind beim TechBoost. Wir haben schon länger keine Folge mehr gemacht, aber wir hatten uns ursprünglich heute auf die Agenda gesetzt, wieder so ein buntes Sammelsurier an einem Thema zu machen. Mal gucken, ob wir die im Nachgang noch nachschieben.
Aber wir haben uns gedacht, wir wollen mit dem Bumi zusammen mit dir heute mal ein bisschen über die Neuerungen, die bei Albi generell so in der letzten Zeit passiert sind, was jetzt kürzlich neu angekündigt wurde. Hier namentlich Albi Hub, dass wir da mal tiefer reingehen und wir gucken einfach mal, wie weit wir kommen, wie viel wir damit abdecken können. Und dann schauen wir im Nachgang einfach, ob wir noch mehr Themen machen oder sagen, wir machen die Folge komplett nur über Albi.
Und ja, dann würden wir jetzt einfach an das Thema mal rein starten. Ansonsten, Karl, hast du noch was zum Thema Value for Value zu sagen? Das habe ich tatsächlich. Mal wieder der kurze Werbeblock. Wenn ihr uns unterstützen wollt und euch die Arbeit gefällt, wir einen Mehrwert bieten für euch. Und wenn es nur Entertainment ist, dann sendet uns doch gerne ein paar Satz. Ihr findet unsere Lightning-Adressen und On-Chain-Adressen auf Nodesignal.space.
Und ihr könnt uns auch über Podcast 2.0 Player hören und direkt Satz zu streamen oder einen Boost senden und damit auch mal einen Kommentar mit Feedback geben. Und wir werden hoffentlich bald mal wieder auch ein paar davon vorlesen und darauf eingehen. Und ja, Verbesserung gerne darüber. Vielen Dank dafür. Dann gehen wir einfach direkt mal ins Thema rein. Bubi, ich habe eben mal in Vorbereitung auf die Folge mal geschaut, wann du das letzte Mal hier bei uns bei Nodesignal warst.
Du warst, glaube ich, im Februar 2022 bei uns da. Das war sogar relativ in unserer Anfangszeit eine der ersten 10, 15 Folgen, glaube ich. Da warst du da und hast damals was über die Albi Web Extension für den Browser erzählt. Das waren ja so eure Anfänge. Vielleicht kannst du die Leute, die die Folge damals nicht gehört haben, die jetzt erst in den letzten Jahren zu uns gekommen sind, nochmal so einen Überblick geben. Was ist Albi überhaupt? Beziehungsweise wie seid ihr gestartet?
Und ja, was war eure ursprüngliche Intention damals, diese Extension zu starten? Und dann können wir gerne dann im Folgenden dann über die weiteren Sachen, was so passiert ist in der letzten Zeit, noch mal weiter eingehen. Verrückt, wie die Zeit vergeht. Das war auch so richtig die Anfangszeit von dem Albi Projekt. Und ja, ist eigentlich spannend zu sehen, was in der Zeit alles passiert ist, wie sich das Ökosystem insgesamt weiterentwickelt hat.
Und ja, zu Albi. Ich meine, wir sind gestartet als Projekt mit dem Ziel, Lightning als Protokoll zu verwenden, um neue Monetarisierungsmöglichkeiten im Web zu ermöglichen. Prinzipiell mit der Idee, dass wir jetzt ein Protokoll haben, um einen Wert zu übertragen in einer digitalen Form. Und dass das war, was eigentlich im Internet immer gefehlt hat.
Wir konnten Informationen übertragen, ich konnte mit jedem Browser jede Webseite aufrufen, aber es war nie möglich, eigentlich von dem Besucherwert in die andere Richtung zu schicken. Also von dem Besucher von der Webseite an den Publisher was zu schicken. Und ja, unsere These ist und ist immer noch, und hat sich ja auch entwickelt, und wir wollen mal sehen, wie sich es in den nächsten Jahren noch entwickelt, ist so, dass mit dem Lightning-Netzwerk wir das jetzt endlich machen können.
Und als erstes Projekt, was wir dafür gemacht hatten, war eben die Albi Browser Extension. Und die Albi Browser Extension hatte das Ziel, eben dem Browser Lightning beizubringen. Sprich, dass der Nutzer, wenn er eine Webseite aufruft, dann auch Satz direkt an die Webseite, an den Webseitenbetreiber schicken kann. So, das war der erste Schritt.
Und dafür gab es dann auch eigentlich so ein JavaScript-Protokoll, WebLN, mit dem die Webseite mit der Browser Extension interagieren kann, und sozusagen Payments von dem Nutzer anfordern kann. Und ja, damit waren jetzt halt auf einmal native Lightning-Anwendungen möglich. So Lightning-tief in die Webseite integriert war.
Mit tief integriert meine ich, dass man eben nicht mehr durch irgendeinen Checkout-Prozess durchgehen muss, wo man dann irgendwie zum Beispiel eine Kreditkarteninformation eintragen muss, oder auch im Lightning-Bereich ein QR-Code scannen muss, sondern dass ich zum Beispiel auf einer Webseite rumsurfen kann, und statt einem Like kann ich auf einmal eigentlich irgendwie, ja, in Noster-Welt ist das dann viel, haben sie es Subs genannt,
aber statt einem Like-Button kann ich eigentlich auch direkt Satze mitschicken. Und genau, das war so der Anfang, das war auch das Thema, was wir, glaube ich, damals so besprochen haben, was Lightning dann ja auch möglich wird. Was du jetzt anfangs auch schon meintest, das ist so dieses Konzept von Value for Value, noch mal viel mehr, weil wir einfach die Peer-to-Peer-Möglichkeit haben, um diesen Wert zu übertragen.
Ich weiß nicht, ich kann da auch gleich mal weitermachen, weil da hat sich natürlich viel getan, aber das ist so das Grundkonzept, mit dem wir eigentlich gestartet sind. Wir wollen Tools bauen, um das möglich zu machen.
Wir wollen Tools bauen für die End-User, damit sie die Möglichkeit haben, an dieser Bitcoin-Economy sozusagen teilzunehmen, aber wir wollen auch Tools bauen, eben für die andere Seite, für Publisher, für Developers, um dieses Protokoll, dieses Lightning-Protokoll zu integrieren, um das eben dann möglich zu machen.
Und seit wir damals gesprochen haben, hat sich das Ökosystem, das Albi-Ökosystem dann auch weiterentwickelt, sind ein paar mehr Tools dazugekommen, sind ein paar mehr Ideen dazugekommen, weil es ist halt eigentlich alles immer noch sehr früh, das ist immer noch eine sehr frühe Phase und es geht noch sehr viel ums Experimentieren. Es geht noch sehr viel ums Experimentieren, was ist eigentlich möglich, was kann man tun, was wird vom Nutzer angenommen, was ist dem Nutzer noch zu kompliziert?
Technisch ist es noch sehr kompliziert, aber wir müssen eigentlich auch Use Cases finden, die sinnvoll sind und die Spaß machen eigentlich mit Lightning zu benutzen. Und es ist dann so, dass ihr die Use Cases findet und für beide Seiten entwickelt? Das klang jetzt so ein bisschen so, weil du sagtest, ihr macht das für die Websitebetreiber, für die Hosts und ihr macht es aber auch für die Endnutzer.
Das heißt, ihr versucht, beide Seiten abzudecken oder gibt es mittlerweile Player im Markt, die sich konzentriert haben auf Partnerschaften mit euch oder generell auf einen Standard, den es vielleicht gibt, den ihr nutzen könnt? Die Annahme ist eben dadurch, dass es ein offenes Netzwerk ist, führen Ideen nur zu mehr Ideen.
An sich wird es so sein, dass nicht eine Firma oder ein Projekt irgendwie Use Cases entwickeln kann, sondern eben irgendwie die Kreativität der Entwickler und der Leute da draußen. Das ist das Entscheidende. Und das ist ja das Gleiche, auch was man eigentlich im Internet gesehen hat. Am Anfang gab es vielleicht ein paar oder man hat ein paar Firmen gehabt, die dann Dinge tun.
Aber das Spannende da draußen ist ja eigentlich die tausenden, Millionen von Entwicklern, die auf einmal Dinge tun können, die sie vorher nicht machen können. Und ähnlich sehen wir es mit dem Lightning-Netzwerk. Und unser Ziel ist es halt eigentlich eher, Dinge möglich zu machen.
Also für die Entwickler und für die Publisher, sind das dann irgendwie zum Beispiel Entwicklertools, APIs, die wir anbieten, oder wo wir auch in den Standardisierungsprozess mitarbeiten, dass es eben standardisierte Protokolle gibt, die eben Anwendungen möglich machen. Aber es sind natürlich immer so die beiden Seiten.
Die Browser Extension ist eigentlich so das sehr schöne Beispiel dafür, weil die User brauchen eine Interface, die Browser Extension, um mit Webseiten interagieren zu können, die Lightning integrieren. Und die Webseiten integrieren dann bestimmte Entwicklertools, um Lightning-Zahlungen zum Beispiel anzunehmen. Und da gibt es auf jeden Fall viele spezialisiertere Player, die eigentlich darauf aufbauen. Also ich sehe das immer so ein bisschen in so Ebenen. Wir sind auch nicht ganz unten.
Wir sind eher auch so zwischen der Ebene. Es ist jetzt nicht ganz so Hardcore-Lightning-Protokoll, sondern es ist schon näher am User dran. Aber es ist immer noch so, dass da dann zum Beispiel noch Apps drauf aufbauen, die dann zum Beispiel dann speziellere Tools für Podcasters bauen oder noch speziellere Tools für Entwickler bauen oder Ähnliches.
Das ist jetzt ja, wenn man nochmal die zwei Jahre zurückblickt, wo ihr ja dann an der Extension primär gearbeitet habt, da habt ihr ja eigentlich primär nur an dem Frontend für Endnutzer gearbeitet. Und mein Gefühl ist jetzt auch so mit den Sachen, was ich so in den letzten Jahren und Monaten mitbekommen habe, dass ihr euch ja immer mehr auch in diese Schnittstellen dann rein bewegt habt mit den Sachen, die ihr entwickelt habt.
Dass ihr mehr, wie könnt ihr es Entwickler einfacher machen, Tools zu integrieren, dass die dann einfacher miteinander kombinieren können. Da ist jetzt dann auch das Stichwort hier das Nostr Wallet Connect, was glaube ich letztes Jahr gestartet ist oder Anfang diesen Jahres irgendwie. Nostr ist ja auch so ein Phänomen, was glaube ich auch vor zwei Jahren auch noch nicht in der Breite jetzt so in der Bitcoin-Community angekommen ist, wie es jetzt mittlerweile der Fall ist.
Vielleicht kannst du noch mal ein bisschen was zu dem Nostr Wallet Connect sagen, was ihr da gebaut habt. Also die Theorie ist die gleiche oder die Fragestellung ist die gleiche. Wie kann man Lightning in Anwendungen integrieren? Im Browser haben wir das dann eben mit der Browser Extension und dem WebML-Protokoll, diesem JavaScript-Protokoll gemacht. Aber es reicht natürlich nicht. Wie ist es mit nativen Anwendungen? Wie ist es mit Server-Anwendungen?
Wie ist es dann auch vielleicht, dass es gar keine Interaktion zwischen dem Nutzer geben muss? So Stichwort Subscriptions ähnliches oder so was, oder dass eine Einzahlung und Auszahlung ohne einen Klick von dem Nutzer stattfinden soll, sondern komplett von einem Server gemanagt, programmiert.
Und da kam eigentlich, Stichwort Nostr kam dann dazu, als auch ein verteiltes Protokoll für, kann man sagen unter anderem eine Anwendung davon ist dann Social Media, wo es ein paar Nostr-Clients gegeben hat. Und dadurch, dass es von ein paar Bitcoinern auch war, war die natürlich da auch die Bitcoin- und Lightning-Affetivität sehr groß und dementsprechend auch das Interesse nativ Lightning-Payments zu integrieren, ziemlich groß.
Sodass man sagen kann, okay, es wird möglich, dass ich einen Post auf Nostr, ein Event auf Nostr zappe. Will hatte das eigentlich damals erfunden, dass man sagen kann, okay, ich schicke direkt Satz, wenn ich einen Poster toll finde, direkt an den Autor. Aber die User Experience ist natürlich ziemlich schlecht, wenn ich dafür zum Beispiel eine Anwendung wechseln muss.
Ich bin jetzt auf einem Mobile-Client, scrolle dadurch meine Timeline durch, finde da irgendwie ein paar spannende Posts, wo ich vorher vielleicht Like geklickt habe, will ich jetzt zappen. Und wenn ich dafür jetzt irgendwie dann eine andere Mobile-App aufmachen muss und Daten in Payment confirmen muss und dann wieder zurückgehen muss, dann ist das natürlich viel zu kompliziert.
Man sagt auch bei diesen Micropayments ist ja immer so, dieser Mental Overhead, die Mental Transaction Costs, die sind eigentlich viel zu hoch dafür. Und das hat man da eigentlich ziemlich genau gesehen. Und so war da das Interesse dann ziemlich groß, eigentlich eine Lösung zu finden, wie man eben das programmatisch direkt in die Anwendung integrieren kann.
Und mit Nostar haben wir ein neues Ökosystem mit den Nostar und Nostar Relays, um Events, um Nachrichten an unterschiedlichste Stellen zu schicken. Und wir haben dann einfach dieses Nostar Ökosystem, dieses Relay Ökosystem verwendet, um Nostar Events an den Wallet zu schicken.
Und so war es dann möglich, oder so war die Idee, und so wurde es dann möglich, dass eben der Nostar Client, statt eine andere Anwendung aufzumachen, um eine Zahlung auszuführen, eine Nostar Nachricht an das Wallet von dem Nutzer schicken kann. Im Hintergrund, das funktioniert alles komplett automatisch. Und das Wallet von dem Nutzer die Zahlung dann ausführt und sozusagen die Antwort dann zurückkommt.
Und dadurch war es dann auf einmal möglich, dass eben der Nutzer nicht mehr die Anwendung wechseln muss zum Bezahlen. Und es war aber trotzdem möglich, dass unterschiedlichste Wallets mit verbunden werden konnten. Das ist nämlich auch immer ein ganz wichtiger Punkt. Das macht auch keinen Sinn, zum Beispiel ein Albi API zu integrieren, wenn es nur Albi ist, weil das Spannende ist ja eigentlich das offene System, weil dann könnte ich auch ein PayPal integrieren oder eine Visa oder so was.
Das heißt, es ist ganz wichtig, dass es offene Protokolle sind und dass die Nutzer entscheiden können, welches Wallet sie benutzen. Und das wurde dann eben mit dem Noster Wallet Connect möglich. Da ist dann der Standard entstanden, um eben dieses Noster-Event zu beschreiben, wie ein Noster-Client die Anfrage an den Wallet schickt, um die Zahlung auszuführen. Das war so die erste Anwendung. Amethyst war der erste Noster-Client, der das implementiert hat.
Und inzwischen hat sich das auch dann weiterentwickelt, dass es jetzt nicht nur darum geht, Zahlungen auszuführen, sondern dass man auch zum Beispiel Invoices erstellen kann, Balances abrufen kann, die ganze Transaktion-Action-List abrufen kann und so weiter und so fort. Da können wir gleich noch irgendwie dazukommen. Aber so war eigentlich der Anfang. Wie war das bei den Wallets?
Mussten die das auch sukzessive dann bei sich integrieren oder habt ihr den Standard so gebaut, dass jedes Wallet das... Also konnte ich das direkt an meinen eigenen Node senden oder gab es dann erst mal nur ein, zwei Wallets, mit denen das funktioniert hat? Oder wie habt ihr das gelöst? Ja, das ist eine sehr gute Frage und eine wichtige Frage. Und es sind immer noch zu wenige Wallets, die das eigentlich auch implementieren.
Das ist halt immer so dieses Henne-Hi-Problem eigentlich auch, das man da hat. Es gab zwei Sachen. Zum einen, das Schönste ist natürlich, wenn das Wallet das eigentlich nativ implementiert, also auch wirklich den Standard direkt implementiert. Aber es gab auch verschiedene Brücken eigentlich. Es gab einen LNBits-Plugin zum Beispiel, der sich dann sagen kann, okay, mit einem LNBits-Node kann ich jetzt dieses Noster Wallet Connect verwenden. Mein LNBit spricht dieses Noster Wallet Connect.
Und da gab es ein paar. Ein Core Lightning Plugin gab es, eine LND-Möglichkeit gab es. Da hatten wir eine implementiert. Wir hatten das als erstes implementiert als Anwendung, die auf LND aufbaut und als Anwendung, die auf einem Aldi-Account aufbaut, was auch, glaube ich, am Anfang die meisten verwendet hatten. Aber eigentlich müssen es die Wallets schon auch mit implementieren. Also entweder braucht man so eine Brücke, die das übersetzt eigentlich, oder die Wallets implementieren es nativ.
Ich kann mich auch daran erinnern, dass so ein relativ populäres, oder was wir zumindest bei uns benutzen, was auch meines Erachtens Noster Wallet Connect verwendet, ist dieser, das ist auch, glaube ich, so ein Workaround, so ein Showcase von euch gewesen, dieser Lightning-Dauerauftrag, den man dann auch über den Lightning-Web-Account einrichten kann. Das macht zum Beispiel der Maulwurf.
Bei dem wissen wir, dass er das macht, dass er einmal in der Woche uns einen kleinen Satzbetrag zukommen lässt, automatisiert über diesen Lightning-Dauerauftrag in irgendeiner Form, wo das Ganze dann auch so läuft, dass er einmal in der Woche dann, ja, automatisiert von einer Wallet, die dann über dieses Noster Wallet Connect angebunden ist, dann an eine Zieladresse, an eine Lightning-Adresse, dann eine Zahlung dann sendet.
Ich weiß nicht, willst du dazu noch ein bisschen mehr, noch ein bisschen mehr Details erzählen? Ja. Also ich finde das ein super Thema, Einfauer. Das beschreibt das eigentlich auch ziemlich cool, weil wir hatten ja jetzt Lightning, sind sie eigentlich immer Push-Payments. Und das ist auch das Coole, ich gebe dem Nutzer die Kontrolle.
Das ist nicht so wie bei einer Kreditkarte, dass ich irgendwie dem Händler meine Kreditkartennummer gebe und vertraue, dass der halt nur den Betrag einzieht, den er einziehen kann. Und gut, ich weiß, dass ich zu meiner Kreditkarte, zu meiner Bank gehen kann und sagen kann, okay, der hat da zu viel eingezogen, so das stimmt nicht, ich war das gar nicht, gib mir die Geld zurück und dann, whatever, gibt es Versicherungen, die das irgendwo machen.
Aber in Lightning, gerade, wenn man es jetzt halt so Self-Sovereign sieht, dann ist ja, das ist eigentlich ein Push-Payment, so was. Ich muss als Nutzer ja an den Händler was schicken, der kann nichts einziehen. Was ja eigentlich, ja, ein richtig großer Vorteil ist. Auch der Punkt ist, dass ich eben halt Self-Sovereign, Self-Custodial, das alles verwalten kann. Ich die Kontrolle als Endnutzer darüber habe.
Aber das hat natürlich zur Folge, dass wir Dinge nicht tun können, wie, ja, so eine Art Daueraufträge. Oder dass der Händler eben jetzt nicht hingehen kann und so eine Subscription abbilden kann, so ein Abonnement abbilden kann. Das müsste eigentlich das, auch vielleicht das Wallet implementieren in der Form.
So, aber das Interessante ist jetzt mit NWC, mit Nostalr Wallet Connect, ist ja eben so, dass wir ein Nachrichtenprotokoll haben, zwischen einer Anwendung, zwischen was auch der Händler zum Beispiel ist, und dem Wallet selber. Und so kann dann der Händler jetzt sagen, ich schicke eigentlich die Nachricht an das Wallet von dem Nutzer mit der Bitte einer Überweisung, sozusagen, mit der Bitte, bezahl doch mal diese Invoice.
Und das Wallet von dem User kann dann hingehen und sagen, okay, ja cool, diesen Händler kenne ich schon oder diese Anwendung kenne ich schon. Dort wird ja auch ein bestimmtes Budget hinterlegt und der darf jetzt irgendwie einmal in der Woche darf der irgendwie 10.000 Satz abrufen oder so was. Oder wenn diese Anfrage kommt, dann über einen Betrag von 10.000 Satz beispielsweise, dann führt das Wallet diese Zahlung automatisch aus.
Und so kann man jetzt natürlich solche Daueraufträge implementieren und ein Showcase, das ist der Subpliner von uns, macht eben genau das, wo der Nutzer einstellen kann, okay, ich möchte jetzt jeden Monat, jede Woche ein paar tausend Satz an den Empfänger schicken. Und ja, dann wird einfach periodisch sozusagen diese Nachricht an das Wallet geschickt. Das Wallet checkt die Permissions und führt diese Zahlung aus und that's it. Und so ist es eigentlich ziemlich cool.
Und technisch gesehen, was ich daran eigentlich auch spannend finde, ist, dass wir eben als, das ist sozusagen eine Ebene über dem Lightning-Netzwerk. Wir müssen nicht alles in das Lightning-Protokoll implementieren, was das Protokoll eigentlich nur kompliziert macht, sondern wir können jetzt eben halt so ein Communication-Layer draufsetzen. Aus der Wallet Connect, um diese Anfragen hin und her schicken zu können.
Das muss nicht nativ im Lightning-Protokoll sein, weil wir haben ja eigentlich Technologien, um Kommunikation, um Nachrichten hin und her zu schicken im Internet schon genügend. Und ja, somit ist es halt eigentlich ziemlich einfach zu implementieren. Das ist schon krass, wie du beschreibst. Du hast am Anfang gesagt, dass wir, oder wir alle, wir sind noch recht zeitig mit dem, was wir machen. We are all early, wie man das immer so liest.
Und ihr ja vor allen Dingen, also so wie du das alles beschreibst, ihr seid ja wirklich immer an der Grenze dessen, was möglich ist. Und darüber hinaus, also dann mit so Lösungen quasi um die Ecke zu denken, um etwas abzubilden, was gerade gewollt ist oder was man vielleicht gerade braucht. Und du sagst immer wir, wie ist das für dich, für euch? Wer seid ihr? Wie viele seid ihr? Also kannst du dazu mal kurz ein bisschen was sagen?
Also Albi ist als Open-Source-Projekt gestartet, ist auch alles Open-Source, was wir implementieren. Die Extension war das erste eben, was ich meinte. Und da hat sich dann eigentlich relativ schnell ein paar Leute, ein paar so Core-Member drumherum gebildet. Einige haben auch ziemlich viel Support von der Bitcoin-Design-Community am Anfang bekommen. Und irgendwann waren wir an dem Punkt, wo wir gesagt haben, okay, cool, jetzt müssen wir überlegen, okay, wie geht das weiter?
Wie machen wir das sustainable? Wie machen wir das Projekt sustainable? Und da war dann der Plan oder die Annahme, dass wir es schaffen werden, ein Unternehmen aufzubauen, was Services in dem Bereich anbietet. Das haben wir dann gegründet. Da sind wir jetzt gerade so, ja, weiß gar nicht genau, müssen wir so sieben, acht, neun Leute verteilt, nicht alle Full-Time, aber genau, sind verteilt auf der ganzen Welt eigentlich, die als Core-Team an den Projekten arbeiten.
So die Tools selber wie die Browser-Extension, ich glaube, weiß gar nicht, die letzte Zahl weiß ich gar nicht, aber das sind ein Haufen Open-Source-Contributor, die da mitarbeiten. Ich glaube, es waren über 100, die da mitcommitted haben. Und Tools und sowas, also das ist alles standing on the shoulder of giants. Aber wir als Core-Team sind ein Unternehmen mit dem Ziel, irgendwann Services in dem Bereich anzubieten. Was das genau sein wird, wissen wir noch nicht.
Kommen wir gleich noch zum Albi Hub, da ist es das erste Mal, dass wir eigentlich auch ein Produkt anbieten oder ein Service anbieten, für den wir berechnen.
Bekommt ihr einige, also vom Core-Team, habt ihr irgendwelche Grants von irgendwelchen Foundations oder sowas, die euch jetzt, dann wenn du sagen, dass ihr jetzt mit dem Albi Hub, kommen wir gleich nochmal drauf zu, dass ihr da irgendwie eine Unterstützung bekommt, dass ihr weiter an den Tools arbeiten könnt, jetzt ohne quasi jetzt durch das Unternehmen selber einen Einkommensstrom zu generieren, stand jetzt? Ich weiß nicht, wie viel du das sagen kannst.
Wir haben das ganz am Anfang, aber wir haben auch eine Seed-Finanzierung Anfang des Jahres bekommen, genau mit dem wir gerade arbeiten können. Ah ja, okay, cool. Also, das ist eigentlich ganz cool, das ist halt immer so das Thema. Ich glaube, dieses Lightning-Thema, Bitcoin-Thema, wir sind sehr früh, das wird sehr groß, das wird verändern, wie wir Online-Transaktionen ausführen. Es wird aber noch ein bisschen dauern.
Wir müssen noch sehr, sehr viel Research machen und sehr, sehr viele Tools bauen und so weiter. Wir sind eigentlich immer noch so ein bisschen Mitte der 90er, wenn man es im Internet vergleicht, so dieser typische Vergleich immer. Es ist noch ziemlich schwer, auch, glaube ich, in dem Bereich Projekte zu bootstrappen. Das glaube ich auch. Weil das Ökosystem noch sehr klein ist.
Und die wahrscheinlich dann in irgendeiner Form auch zu monetarisieren, dass man davon als Unternehmen quasi einen nachhaltigen Einkommensstrom hat, der auch in der Lage ist, Mitarbeiter zu bezahlen, die damit dann ihr Leben bestreiten können. Also, ich glaube, das sind ja die Summen, die dann da fließen müssen, müssen ja schon sehr, sehr groß sein.
Und das bei einem kleinen Lightning-Nutzerschaft im Kontext von der Gesamtbevölkerung oder vom Gesamtökosystem ist es ja schon auf jeden Fall eine Herausforderung, das stimmt schon. Ja, aber dann lass uns doch mal mit Hinblick auf die Uhr, weil du zeitlich heute ein bisschen hinten raus, ein bisschen limitiert bist, über euer neues Projekt, oder es ist gerade schon mal kurz angesprochen, dass wir über Albi Hub sprechen.
Lass uns da einfach mal reingehen, vielleicht dann auch so aus dem Aspekt, was ist das und warum habt ihr das eingeführt, beziehungsweise vielleicht auch so ein bisschen im Vergleich dann dazu, ihr hattet ja vorher, beziehungsweise auch im letzten Jahr oder vorletzten Jahr diese Albi Web Wallet als Custodial Service angeboten, beziehungsweise eingeführt und gerade jetzt dann auch im Vergleich dann dazu, wo ist der Unterschied und warum sollte man darauf wechseln? Ja, genau.
Also wir hatten über die Extension gesprochen, wir haben über so die Idee gesprochen, dass wir Lightning-Tief in Anwendungen integrieren möchten, so wie dieses Likes und Subs in Noster und gerade bei der Extension, am Anfang war es ja so, dass man auch dort eine LND-Node verbunden hat. Und ich weiß noch, damals hatten wir auch ein paar Sessions immer, wo man noch gesehen hat, wie kompliziert das eigentlich auch war. Oh ja, ich erinnere mich. Aber mit Tor dann häufig das Problem?
Genau, mit Tor, man muss über Tor verbinden und dann kann aber der Browser nativ nicht Tor und wie funktioniert das? Und dann braucht man irgendwie Macaroons und Zertifikate und so weiter. Und das war natürlich eigentlich fast unmöglich, wenn man nicht wirklich richtig Lust drauf hat und weiß, was man tut.
Und um es den Nutzer auch einfach zu machen und auch viel zum Auszuprobieren, auf dem Podcasting-Bereich zum Beispiel haben wir ja viel ausprobiert, hatten wir dann eben gesagt, okay, es gibt den Albi-Account, wo wir das den Leuten abnehmen. Leute können sich registrieren, haben einen Wallet, haben einen Account, können das benutzen. Wir lernen auch dann, was an Use Cases funktioniert, was wird angenommen.
Damit kann man starten und sozusagen eigentlich weiter wachsen, sage ich jetzt mal im Sinne von, okay, wenn es wirklich cool ist, was ich da benutzen kann, dann kann ich, dann lohnt es sich auch, die eigene Node aufzusetzen. Wir hatten auch immer die Annahme, dass eigentlich, wir sind immer so ein bisschen vom Nutzer gekommen eigentlich, und da hatte ich immer die Annahme, muss ich jetzt im Nachhinein sagen, dass die Entwicklung, was die Wallet-Seite angeht, schneller stattgefunden hätte.
Dass ich jetzt erwartet hätte, dass es zwei Jahre zurückschauend schneller, einfacher wird, eine Node aufzusetzen, einen Wallet aufzusetzen, Legitimität zu managen und so weiter. Also wir hatten damals auch über so Lightning-Service-Providers schon gesprochen. Und es ist aber heutzutage eigentlich immer noch so ein bisschen kompliziert, oder es war lange kompliziert. Deshalb hat eigentlich auch der Account natürlich immer mehr einen Anklang gefunden. Das hat an sich super gut funktioniert.
Wir mussten auch irgendwann mal, weil es zu viele User wurden für den Account, haben wir dann Invite-Codes einführen müssen, mussten wir das stoppen. Und gleichzeitig hat sich zum Beispiel mit LDK, mit Greenlight, was so Tools sind, um Wallets zu bauen, die Möglichkeit gegeben, ja, Self-Sovereign, Self-Custodial, neue, andere Lightning-Wallets zu bauen.
Und so sind wir dann hingegangen und haben gesagt, okay, cool, wir wissen jetzt, was wir da eigentlich in dem Podcasting-Bereich mit der Extension, mit der Lightning-Adresse und so weiter alles machen können.
Jetzt, und es wird auch angenommen, die Leute haben Bock drauf, es wird, die Community wächst, jetzt müssen wir hingehen und sagen, okay, wie kriegen wir es jetzt hin, dass wir das, was wir dort sehen, in einem Self-Sovereign-Way möglich machen können, dass die Leute ihre eigenen Nodes betreiben können, aber in einer einfachen Art und Weise und auch drauf optimiert, auf die Art, auf den Use-Case optimiert, dass ich es eben halt in Anwendungen integriere.
Und das ist dann, was IB Hub wurde, das ist eigentlich jetzt unser neues Wallet, und zwar ein Wallet, Lightning-Node, was die Leute installieren können. Wir sind da hingegangen und haben gesagt, okay, einige der Sachen, die noch kompliziert sind, zum Beispiel auch technisch kompliziert sind, lassen wir einfach weg. Zum Beispiel, um so Sachen zu machen, wie wir jetzt auch hatten, mit Podcasting, beziehungsweise auch mit dem Dauerauftrag, muss die Lightning-Node immer online sein.
Und wir haben gesagt, okay, wir optimieren jetzt nicht für eine Mobile-Anwendung, da gibt es einen Haufen ganz gute, aber die haben das Problem, dass die ja nicht mehr online sind, sondern wir sagen, okay, der Nutzer wird eine Connect-Node haben, die wird immer online sein, und er wird dann mit dem Noste-Wallet-Connect-Protokoll unterschiedliche Anwendungen damit verbinden, um mit dieser zu interagieren.
Der Vorteil ist dann eben, ich muss es nur einmal aufsetzen, und ich habe nicht irgendwie fünf Wallets und fünf Nodes, die ich irgendwo betreiben muss, auf dem Handy, auf dem Computer, in meinem Noste-Klein und so weiter, sondern ich habe die, ich setze die einmal auf und kann die dann überall verwenden, und wir optimieren genau darauf, dass man sie einmal aufsetzt, und dann eben halt mit Noste-Wallet-Connect in die Anwendung integriert.
Und da haben wir jetzt die letzten sechs, acht Monate fast daran gearbeitet und sind jetzt gerade so in der Beta-Phase, wo wir das gelauncht haben. Und ich glaube, das Feedback ist bisher ganz cool. Wir sind hingegangen und haben gesagt, es gibt zwei Arten, wie man es betreiben kann. Entweder betreiben wir es in der Cloud, in unserer Infrastruktur. Das ist dann ähnlich wie Voltage, wie vielleicht einige kennen.
Voltage, die LND-Nodes und Bitcoin-Nodes für Leute betreiben und Tools gebaut haben, um das zu deployen. So haben wir unsere Infrastruktur, in der Leute dann die Albi, den Albi Hub deployen können. Oder Leute können es auf dem Desktop betreiben, auf dem eigenen Server betreiben. Wir versuchen, die möglichst in allen Environments möglich zu machen, dass man den Albi Hub betreiben kann.
Ich habe es hier auf einem Raspberry Pi Zero laufen, was ziemlich cool ist, weil ich auf einmal mit einem 20-Dollar-Device eine Lightning-Node betreiben kann. Ich brauche nicht mehr irgendwie einen Raspberry Pi mit einer SSD-Festplatte von einem Terabyte und sonst was, sondern es ist nur noch ein kleines Device. Aber wie kann so etwas gehen? Was ist jetzt der Unterschied zu dem Modell mit der Speicherkarte, also mit einer SSD und einem großen RAM?
Du musstest ja schon immer noch den neuesten Raspberry Pi besorgen und das wurde ja auch doch immer teurer. Man brauchte einen Bitcoin-Core-Client, dass man ja die Blockchain irgendwo bei sich dann irgendwie mal, das war ja jemals das, warum man eine dicke SSD hatte. Weil die Blockchain ja quasi immer parallel mit einem Core-Client parallel läuft. Das ist ein wichtiger Punkt. Die Idee ist dort, dass man halt in die Cloud Dinge auslagert, die nichts mit den eigenen Keys zu tun haben.
Also ich muss jetzt nicht die Blockchain selber synchronisieren. Zum Beispiel. Die Daten sind in der Cloud und die kann ich wiederverwenden. Also wenn ich jetzt natürlich wirklich alles selber validieren möchte, dann ist das immer noch der Fall, dass ich natürlich irgendwie meine Full-Node laufen lassen möchte und da alles drauf aufsetzen.
Aber für jetzt mal so Lightning-Anwendungen muss das nicht unbedingt der Fall sein und ich nehme einfach die Daten, die ich einfach aus der Cloud abrufen kann.
Das Wichtige ist aber, dass ich meine Keys selber habe und die Anwendung selber habe und das ist dann natürlich viel einfacher, weil ich jetzt nicht mehr irgendwie die ganze Chain synchronisieren muss, die Bandbreite braucht, den Speicher braucht und so weiter und so fort, die Ressourcen auch braucht, um alles zu validieren, sondern es ist halt viel, viel kompakter. Aber ich besitze halt eigentlich immer noch die Keys, worauf es ankommt.
Man muss auch immer noch sagen, Raspberry Pi Zero ist ein bisschen experimentell, was natürlich schon so ein bisschen extrem ist, aber auch in der Cloud ist es halt so, dass ich dann nur einen kleinen virtuellen Server brauche mit 512 MB RAM zum Beispiel oder so was. Und ja, das hat dann schon einen großen Unterschied.
Ich hatte jetzt überlegt, macht es Sinn, dass ich meine Core-Node dann eben separat auf diesem Raspberry Pi laufen lasse, die SSD habe und dann aber vielleicht mehrere von euren Anwendungen, also von dem Albi-Hub laufen lasse, um, weiß ich nicht, verschiedene Wallets zu bedienen oder verschiedene Dienstleistungen zu nutzen. Macht das Sinn oder führt das ad absurdum die Idee, die du gerade beschrieben hast? Habe ich das richtig verstanden?
Das ist auf jeden Fall eine Möglichkeit. Also es verbindet sich gerade nicht direkt mit einer Bitcoin-Core-Node, sondern mit so einem Esplora-Blockchain-API an sich. Die kannst du selber betreiben natürlich. Kann man machen, ist halt die Frage, was du für ein User bist. Wenn du das hast, ist das cool, kannst du das machen. So wie du auch ein LND laufen lassen kannst. Ich habe funktioniert auch mit LND weiterhin, sozusagen auf einer Ebene drüber. Das kann man alles machen.
Das Ziel ist aber natürlich für viel, viel mehr User, das zugänglich zu machen und die Eintrittsbarriere viel zu senken, dass das halt möglichst einfach ist, möglichst ein One-Click-Deployment zum Beispiel in der Cloud zu haben. Oder dann eben halt auch, wenn ich es selber zu Hause laufen lassen möchte, dass ich jetzt nicht ein paar hundert Euro ausgeben muss, sondern nur noch 20, 30, 40 Euro ausgeben muss für so eine Hardware.
Dadurch macht es natürlich für viele Leute einfacher, das zu betreiben. Aber wenn jemand das hat, ist das natürlich cool und kann man tun, auf jeden Fall. Ich glaube, vielleicht um das nochmal so ein bisschen aufzudröseln, du sprichst gerade die ganze Zeit, das für Leute einfacher zu machen. Ich glaube, dass dieses Deployment auf einem Server, ist glaube ich für sehr, sehr, sehr viele Leute, gerade die technisch nicht versiert sind,
trotzdem immer noch ein großes Problem. Das ist wahrscheinlich jetzt nicht die Lösung für den Wald- und Wiesen-Bitcoiner, der mit Technik sehr wenig am Hut hat, ohne jetzt irgendwem zu nahe zu treten. Aber ich glaube, da ist ja dann wahrscheinlich wieder diese Convenience-Lösung, die ihr ja damals, oder die jetzt ja in der Lösung von dem, was ist es nochmal, Albi Wallet? Also quasi der Web, der Albi Account. Genau, der Albi Account, was ja quasi da dann die Convenience-Lösung war.
Ich muss mich nicht drum kümmern, aber ich habe natürlich das große Problem, es ist eine Custodial-Lösung. Das heißt, ich habe wieder irgendjemanden, in dem Fall ihr, der dann die Sats für mich verwaltet oder die Schlüssel an der Stelle. Und du hattest gerade eben schon mal das Thema eingeführt, dass ihr jetzt so eine Art quasi Subscription-Service oder einen Service jetzt quasi als erstes Business-Model für euer Unternehmen entworfen habt, der wahrscheinlich genau diese
Convenience-Lösung bereitstellt. So habe ich es zumindest, oder würde ich es jetzt erwarten, dass das jetzt kommt? So als Ziel, genau. Ja, genau. Also es ist natürlich, wie du sagst, schon noch ein bisschen kompliziert, auf einem Server mit SSH irgendwas zu deployen, obwohl wir da auch das Skripte anbieten und so weiter. Aber man muss trotzdem immer noch was tun, wissen, was man tut. Man sollte auch eine Firewall aufsetzen und so weiter und so fort.
Also das ist schon noch ein bisschen so ein Task. Und um das einfacher zu machen, bieten wir eben mal auch die Cloud-Lösung an, die Cloud-Infrastruktur-Lösung an. Das sind sozusagen so One-Click-Deploys. Das heißt, man mit der Subscription ziehen wir bei uns einen Server hoch und darauf wird der Hub deployed und unsere Cloud kümmert sich um das Networking und alles Mögliche drum und dran.
Wer wären potenzielle Kunden oder Nutzer? Also wo denkst du, ist so der größte Markt, die Zielgruppe für euch? Ist es dann eher der Hoster von der Webseite, weil der die Dienstleistung anbietet und dann gleichzeitig die Services hosten muss? Oder ist es der heavy User, der auf vielen Seiten Satz spenden will? Ja, also wir hoffen natürlich schon, dass es für viele End-User auch interessant ist. Dass das Interesse da ist, auch in einer self-sovereignen Art und Weise
Lightning zu benutzen. Für den Webseitenbetreiber oder Merchants oder sowas natürlich da auch, um es zu empfangen. Da hat es natürlich Vorteile, aber es ist jetzt nicht unbedingt, dass wir uns auf Merchants fokussieren. Es ist jetzt nicht ein BTC-Pay-Server oder sowas. Es ist eher dann möglich zu sagen, okay, mit dem Albi-Hub kann auch das Wallet für den BTC-Pay-Server zum Beispiel dann sein.
Und der BTC-Pay-Server hat dann Invoice-Management drin und alles Mögliche, was man als Händler dann benötigt. Okay. Bevor wir jetzt weiter in das Thema Castoglie gehen, da würde ich nämlich sehr gerne jetzt noch mal weiter reingehen, weil wir ja trotzdem immer noch eine Abhängigkeit haben. Ihr als "Cloud-Betreiber" habt ja trotzdem immer noch eine gewisse Möglichkeit, auf den Knopf zu drücken, das Ding abzuschalten.
Würde ich ganz liebend Herrn Jan-Paul begrüßen, der ist nämlich jetzt zu uns gestoßen. Hi Jan-Paul! Was für eine Überleitung. Hi, grüß euch. Ich habe euch jetzt die letzten zwei, drei Minuten zugehört. Und also freue mich schon darauf, den Rest der Folge, die ersten 40 Minuten, die ich verpasst habe, zu hören, weil ich jetzt echt Schwierigkeiten hatte, euch zu folgen. Ihr seid schon ganz schön tief drin. Aber es freut mich, dass sich das so ein vertieftes Gespräch entwickelt hat.
Ja, aber schön, dass das auch noch geklappt hat. Oder du es auch noch geschafft hast. Ja, für ein paar Minuten, für die letzten Minuten. Ja, kein Problem. Ja, genau. Dann, Boom, wir lassen uns doch mal darüber sprechen.
Selbst wenn ihr jetzt so einen Cloud-Infrastrukturservice dann für die Leute dann gegen entsprechende Bezahlung anbietet, habe ich aber trotzdem ja immer noch eine Abhängigkeit gegenüber euch dann, dass ihr sagt, oder irgendjemand vielleicht dann auch einen Regulator sagt, im Zweifelsfall, das, was der Thorsten da als Service bei euch betreibt, das gefällt uns nicht. Bitte, lieb Albi, schaltet mal die Lightning-Node vom Thorsten ab. Da habe ich ja trotzdem eine Abhängigkeit euch gegenüber.
Was kann man dazu sagen? Natürlich ist es immer so ein bisschen so ein Scale, ne? Weil das kannst du bei, nimm eine Handy-Anwendung auch. Da hat man ein bisschen die Annahme, ein bisschen mehr, dass das ja mein Handy ist, das bei mir in der Tasche ist und die Anwendung da drauf, die gehört mir, aber ich hänge ja trotzdem ein bisschen von Apple ab.
Oder ich hänge von dem Entwickler ja trotzdem ab, weil ich dort irgendwie ein Update reinbekomme, ein Update eingespielt wird und so weiter und so fort. Also da vertraue ich einem gewissen Betriebssystem, da vertraue ich dem App-Store, da vertraue ich auch irgendwo was. Und so ist es natürlich jetzt in dem Fall auch. Wenn ich jetzt irgendwie einen Serverboost hoste, dann steht der, wenn der nicht jetzt irgendwie bei mir zu Hause steht.
Und wie gesagt, da muss ich auch dem Betriebssystem, wenn ich es nicht unbedingt selber kompiliere und selber entwickle, dann muss ich dem auch ein bisschen gewissen Vertrauen. Aber wenn ich den Server dann irgendwo in einem Rechenzentrum habe, dann steht der halt in einem Rechenzentrum. Oder der wird dann von irgendeinem virtuellen, von Amazon betrieben oder so was. Und so kommt man natürlich dahin, dass man gewisse Abhängigkeiten, Star-Abhängigkeiten gibt.
Und man muss für sich selber dann entscheiden, okay, was ist cool, was ist convenience, und was möchte ich selber haben. Möchte ich es selber zu Hause betreiben, und dann muss ich aber halt den Pi mir aufsetzen und das Ubuntu selber oder das Debian besser darauf selber kompilieren und installieren. Oder ich bin okay damit und sage, okay, ich habe es in der Cloud laufen und ich muss mich um die Infrastruktur nicht kümmern. Das Entscheidende ist aber, dass du trotzdem die Keys selber hast.
Also dieses Beispiel, was du gerade hattest, du würdest halt einfach deinen Backup nehmen, deinen Daten nehmen und woanders weitermachen. Also klar, Lightning ist da immer noch ein bisschen schwierig mit dem Backup, mit dem State. Und in dem Fall wäre es praktikabel wahrscheinlich so, dass deine Channels irgendwie geforce-closed werden und du dann wieder anfängst. Aber das sind deine Channels, die werden geschlossen und dann kannst du weitermachen.
Also das ist nicht so, dass dir irgendjemand was wegnehmen kann. Egal, wer das ist. Also wenn es uns nicht mehr gibt oder auch wenn es den Hoster nicht mehr gibt oder auch wenn irgendjemand kommt und sagt, diese Domain darf es nicht mehr geben, dann musst du halt hingehen und sagen, okay, ich muss woanders betreiben. Wie habt ihr das gelöst an der Stelle mit der On-Chain?
Also wir haben ja immer bei einer Lightning Wallet immer eine korrespondierende On-Chain Wallet, die dann im Zweifelsfall, wenn ja Channels geclosed werden, wo ja dann die Funds wieder On-Chain gehen. Wenn ihr sagt, dass quasi die Core, also der Bitcoin Core Client, ja irgendwo zentral für alle von mehreren genutzt wird.
Wie ist das damit in Keys gelöst, dass ich dann auch hier, wenn die Channels dann wieder geschlossen werden, dass ich da auch wieder Zugriff dann auch an die On-Chain Funds komme, wenn das quasi so ausgelagert ist? Mir fällt das ein bisschen schwer, das nachzuvollziehen, weil ich immer nur dieses wirklich Full-Node-Setting bei mir zu Hause kenne, wo alles quasi direkt unter meiner Kontrolle ist. Wie funktioniert das? Ja, ich meine, das sind nur die Blockchain Daten sind ausgelagert.
Die sind nicht bei dir gespired. Das ist wie, wenn du zum Beispiel Elektrum ja verwendest, dann hast du auch einen Light-Client an sich, der von einem Elektrum-Server fragt, gib mir mal die Transaktionen, die für mich relevant sind. Und so ist es in der Form auch. Du hast, der Albi-Hub baut auf LDK und BDK auf, also dem Lightning Development Kit und dem Bitcoin Development Kit. Und da hast du eigentlich eine ganz normale On-Chain Wallet drin.
Die ist jetzt nicht optimiert, ein On-Chain Wallet zu sein, sondern die ist optimiert eigentlich, das grundlegende Bitcoin Wallet zu sein für das Lightning Wallet, was da drauf aufbaut. Aber du hast da ganz normal deine Keys, du hast ein Seed, du hast On-Chain-Adressen, wo du was reinschickst und auch wieder rausziehen kannst. Du kannst auch den Seed irgendwo in ein anderes Wallet importieren. Und wenn derselbe Derivation-Pass verwendet wird, dann siehst du die Funds dort.
Du kannst natürlich auf dem Seed, das Seed reicht jetzt nicht aus, um die Lightning-State zu haben, aber die On-Chain-Funds sind auf dem Key. Und du kannst es wirklich nur so vorstellen, dass halt einfach die Anwendung Cloud fragt, gib mir mal die relevanten Informationen, welche Transaktionen für mich relevant sind. Ich muss jetzt nicht von jedem die Transaktionen sehen und von jedem die Transaktionen validieren, sondern eben nur die, die für mich relevant sind.
Das sind also diese typischen Light-Clients, die wir eigentlich aus der Bitcoin-Welt ja auch kennen, wie Electrum zum Beispiel. Was ist der aktuelle Status zu dem Ganzen? Also kann ich das jetzt schon nutzen? Du hast gesagt, ihr hattet überlegt, das als Business-Case eben auch mit Kosten zu verbinden. Gibt es da schon ein Pricing? Ja, also all die Accounts sind gerade noch immerhin unter Invitation. Aber jeder, der ein Albi-Account hat, kann Freunde einladen.
Oder jeder, der auch hier zuhört, bekommt auf jeden Fall einen Invite. Cool. Und da kann sich registrieren. Und man geht durchs Onboarding durch, klickt auf einen Button und der Hub wird deployed. Das funktioniert. Das Pricing da ist gerade, also wir haben einen Einführungspreis von 10.500 Satz, weil der normale Preis wird 21.000 Satz sein. Da sind wir gespannt, wann wir den noch zerstören. Sorry, 21.000 pro Monat als Subscription-Basis. Das ist für die Cloud.
Der Hub an sich ist aber natürlich Open Source. Findet man auf GitHub. Und da sind auch ein Haufen Installations-Skripts und -Beispiele, wie man es selber installieren kann. Wie man es auch als Desktop-App zum Beispiel laufen lassen kann. Du kannst dir einfach eine Windows- oder Mac-App runterladen, dann hast du genau das Gleiche. Das kannst du dir aufsetzen, kannst du ausprobieren. Hat halt den Nachteil, dass die Wallet nicht always online ist.
Das heißt, wenn du Dinge tun möchtest, von einer anderen Anwendung dazu oder so, dann muss die App auf deinem Desktop laufen. Und das nimmt die Cloud halt eigentlich ab. Da die sagen, okay, das läuft da automatisch immer und ich muss mich nicht drum kümmern. Aber ich kann es auch auf einem Server deployen, ja? Hab's richtig verstanden, diesen IBHub. Genau, das sind die drei Möglichkeiten, die ich habe.
Entweder ich nutze euren Cloud-Service, ich installiere es mir selber auf dem Server, dann habe ich auch Always-on-Funktionalität. Oder ich installiere mir halt eine App auf Desktop, Windows, Android, Mobile, hier iOS oder was. Aber dann ist die Always-on-Funktionalität nicht gegeben, sondern da musst du halt manuell dann die App immer laufen lassen. Da musst du die App laufen lassen, genau.
Das heißt, wenn du dann zum Beispiel über die Lightning-Adresse eine Zahlung reinbekommst, dann muss die Anwendung halt online sein. Sonst würde es nicht funktionieren. Das ist halt so dieses Lightning-Thema. Oder Nostr selbst, oder?
¶ Zusammenhang mit Nostr
Nostr selbst ist ja, genau, das ist ja für mich, oder nicht für mich, aber das ist ja einer der Anwendungsfälle, wo du tatsächlich, wenn du, ist es so, mit Nostr Wallet Connect deinen Nostr-Client verbunden hast mit deinem IBHub-Account, das wird jetzt bei IBHub genauso sein. Ich werde quasi das verknüpfen über Nostr Wallet Connect mit meinem Nostr-Client und dann bekomme ich selbst die reinkommen, die kann ich dann ständig empfangen. Genau.
Also nur, wenn der always on ist, also im Offen-Server, oder tatsächlich die App läuft, oder bei euch in der Cloud gehostet ist. Genau. Cool. Das ist halt so das Ding mit Lightning. Lightning ist halt ein Kommunikationsprotokoll. Das heißt, der Sender und Empfänger müssen gleichzeitig online sein. Das heißt, wenn jetzt jemand Geld schicken möchte, muss der online sein. Das ist meistens nicht das Problem, aber der, der empfängt, muss halt auch online sein.
Dann ist die Frage, wie bekommt der das mit? Das ist natürlich ziemlich kompliziert. Wenn das auf dem Handy ist, dann könnte es theoretisch sein, dass du halt einen Push-Notification bekommst und jemand sagt, hey, du bekommst gerade Geld, bitte mach mal die App auf, in der Form. Aber wenn du jetzt Dinge tun möchtest, wie auch Podcast-Payments, diese Value-for-Value-Payments. Satz-Streaming. Satz-Streaming, dann ist das natürlich nicht praktikabel und du musst halt eigentlich immer online sein.
Und wir sagen halt, okay, das nehmen wir jetzt nicht als Nachteil, sondern als Vorteil. Und sagen, okay, du setzt dir einmal irgendwie in der Cloud oder auf einem Server dein Wallet auf und es ist always online. Und damit kannst du halt all die Dinge tun, die du machen möchtest. Habt ihr mal darüber nachgedacht, im Hintergrund vielleicht Cashu einzubauen? Weil bei Cashu gibt es ja unter anderem so dieses Pay-to-Endpub-Prinzip, sodass quasi die Cashu-Token gebunden sind an deinen Endpub.
Das ist natürlich jetzt ein Nostal-Spezialfall. Aber damit kannst du ja auch eine quasi eine Offline-Empfangs-Funktionalität sicherstellen. Also der Empfänger bekommt an seinen Endpub halt die Satoshis und holt sie sich dann ab, wenn er online geht. Fragt dann halt einfach, okay, ist da was für mich gekommen? Ist vielleicht ein sehr spezieller Case jetzt, ich weiß nicht, ob der außerhalb der Nostal-Welt auftritt. Ich meine, Cashu ist ein super spannendes Ökosystem.
Was man halt da sagen muss ist, es sind halt E-Cash-Tokens. Ich habe die Satz nicht selber. Es ist in der Form halt eine andere Form von Custody. Die ist verteilter, was cool ist. Und ich kann mir die auch mehr aussuchen. Und sind auch operable und whatnot alles. Also es gibt schon spannende Dinge. Und auch solche Anwendungsfälle, wie du sie jetzt gerade beschrieben hast, ist glaube ich schon ziemlich cool. Aber es ist trotzdem klar, dass ich halt eigentlich die Satz nicht selber besitze.
Und da sind schon das Überlegungen gibt. Ich habe immer noch eine Node drunter. Und ich kann darauf sozusagen dann ein Cashu-Mint aufsetzen. Und dann kann ich irgendwie so Friends and Families Sachen machen. Und da sind bei uns auch ein paar Features drin, wo man das machen kann. Aber ja, genau, das sind immer so ein bisschen Pros und Cons. Also ich meine jetzt einen ganz speziellen Fall.
Also jetzt für den User, der jetzt die App auf seinem Windows-Rechner installiert hat, aber dann natürlich nicht gegeben Always-On ist. Für den wäre das natürlich ein nettes Feature, wenn ihr im Hintergrund das anbietet. Wir locken das für dich an deinen Endpub. Da kommen wir nicht dran. Also ihr habt keine Custody. Das ist garantiert.
Und sobald er online geht und sagt, okay, ich möchte dieses Satz jetzt haben, dann wandelt ihr das direkt um in Lightning und zahlt ihm das Lightning auf seine Wallet. Nur um quasi dieses Feature anzubieten, offline Satz empfangen zu können. Ja, ist auf jeden Fall interessant. Custody gibt es trotzdem, weil erstmal wird der beim Sender, beim Mint irgendwie verschickt. Also ja, aber der User bekommt dann noch nicht direkt die Satz. Er bekommt einen eCash-Token, was er dann spenden kann.
Genau, aber es kann niemand anders spenden. Also weder der Sender noch die Mint kann ja diesen Token ausgeben, weil es halt die Signatur des Empfängers benötigt. Ja, das ist auf jeden Fall spannend. Also wir müssen auf jeden Fall auch mal Kalle nochmal sozusagen... Ja, apropos Kalle, eCash Hackday in Berlin, bist du da am Start, Boomi? Wäre ein guter Grund, ne? Ja. Wir wollen ein bisschen Werbung machen. Ich glaube, das ist irgendwie 20. bis 22. Oktober oder so.
Also wir werden dafür nicht bezahlt, sorry. Ich habe das jetzt hier reingeschmissen, nicht weil wir Werbung dafür machen sollen, sondern... Ne, das solltet ihr aber auch. Das ist auf jeden Fall ein richtig gutes Event, ne? Also wir sollten alle hingehen. Ja, ja, ja. Gut, sorry, jetzt habe ich hier das Gespräch an mich gerissen. Thorsten, Karlsson, zurück zu euch beiden. Nein, alles gut. Du bist ja reingekommen. Du hattest gerade über diese Desktop-App, da hatten wir gerade gesprochen.
Wie ist denn die Anbindung da nach extern? Also geht das dann alles über Tor dann? Wie kann, wenn ich das bei mir lokal laufen lasse, muss ich ja eigentlich nur über Tor, kann ich ja nur über Tor extern quasi kommunizieren, außer ich gebe halt irgendwelche Ports auf meinem Router frei, was jetzt sicherheitstechnisch nicht unbedingt das gäbe vom IS+. Dass ich auch noch meine öffentliche IP von meinem privaten Zugang zu Hause doxe, das kommt dann auch mal mit dazu.
Also wie läuft das dann, wenn ich das quasi bei mir lokal auf einem Computer laufen lassen würde? Ja, sehr gute, wichtige Frage, ne? Weil das Tor haben wir eben nicht mehr und wollen wir nicht mehr, in Anführungszeichen, weil es halt langsam ist, ne? Und oft nicht funktioniert und so weiter und so fort, ne? Und was die Alternative dazu ist, ist eben halt sozusagen das Noster-Protokoll, die Noster-Relays.
Und du kannst jetzt, was passiert ist, dass deine Anwendung eine Verbindung zu einem Relay aufmacht und sagt, okay, hier ich bin, das ist da noch irgendein Noster-Pup-Key, der ist random generiert, gib mir mal alle Nachrichten, die für mich sind. Und das Relay kannst du dir vorstellen wie so ein Postbox eigentlich, ne? Ich subscribe bei einem Relay auf all diese Events, die für mich, für das Wallet an sich dann sind.
Das ist ganz wichtig, dass es nicht der User-Endpup ist oder irgendwie sowas, nicht mein Noster-Key, das hat eigentlich damit überhaupt gar nichts zu tun, das verwendet nur dasselbe Protokoll und dasselbe Relay. Das ist einfach ein random neuer Private-Key, den neuer Noster-Key, den das Wallet beim ersten Mal, beim ersten Starten generiert und dann sagt zu dem Relay, guck, ich bin der, gib mir mal alle Nachrichten, die für mich sind.
Und jetzt gehe ich zu irgendeiner Anwendung, ich habe einen SAP-Planner vorhin erwähnt oder meinen Noster-Client oder meine Podcasting-App oder auch getiby.com selber mit der Lightning-Adresse und sage, hier, das ist mein Pup-Key, schick mir, darüber kannst du mir Nachrichten schicken.
Jetzt geht die Anwendung hin, erstellt ein Noster-Event, wo verschlüsselt für diesen Pup-Key der Payment-Request zum Beispiel drin ist oder also diese Anfrage drin ist und dann dieses Event wird an das Relay geschickt, was ja öffentlich zugänglich ist. Das Relay bekommt das, weiß aber gar nicht, was da drin ist. Das ist auch wieder dann nur ein Noster-Event, wo dann draufsteht, okay, das ist für diesen Pup-Key, das ist der Empfänger davon,
leite das mal bitte an den weiter. Dann bekommt das Wallet das von dem Relay eben, weil die Subscription vorher aufgemacht wurde und kann das entschlüsseln, sieht, dass es von der Anwendung ist, wo vorher das Pairing stattgefunden hat, wo vorher die Keys ausgetauscht wurden, kann das entschlüsseln, kann es verarbeiten und so geht die Nachricht dann wieder zurück. Und dadurch muss eben die Anwendung nicht mehr selber auf dein Wallet verbinden. Das ist das, was man immer hatte.
Wenn ich jetzt zum Beispiel Zois mit meinem LND verbinden möchte, dann muss ja irgendwie Zois direkt mit meinem LND-Node sprechen. Und da sitzt jetzt eben halt dieses Relay dazwischen und sozusagen als Mailbox-Server und tauscht das aus. Und deshalb ist es nicht mehr so, dass Verbindungen von außen zu dir reingehen müssen, sondern du machst nur eine Verbindung von dir nach außen auf, zu dem Relay und lässt die Verbindung offen und sagst, okay, gib mir mal alles, was für mich relevant ist.
Also ist das Relay im Endeffekt ja dann der Kommunikator zwischen Sender und Empfänger an der Stelle, dass das dann der Austauschpunkt ist darüber? Genau. Und das ist halt eigentlich ein ganz cooles Konzept. Da sind natürlich auch ein paar Privacy-Themen, Vorteile mit drin. Das Relay sieht natürlich deine Verbindung. Da könnte man jetzt sagen, okay, das ist vielleicht doof. Da könntest du theoretisch auch da eine Tor-Connection
machen, wenn du das unbedingt haben möchtest. Aber das Relay weiß halt eigentlich nichts von dir. Du musst da nicht registrieren. Das ist halt irgendwie einfach ein random Relay, das du austauschen kannst, weil sie eben das Nostar-Protokoll verwendet. Theoretisch kannst du das auch selber laufen lassen, wenn du möchtest. Aber das ist halt eben ein Standard. Du hast ja eben kurz erwähnt, weswegen ihr ja von Tor weggehen wollt, weil es halt sehr langsam ist, weil es unzuverlässig ist.
Manchmal gehen Nachrichten gar nicht durch. Es ist natürlich die Frage, wenn wir uns auf so eine Infrastruktur mit Nostar-Relays verlassen, gibt es da schon Untersuchungen, Analysen, wie fair performant das Ganze ist? Gibt es da Benchmarking, dass man das mal vergleichen könnte? Wo wollen wir da eigentlich hin? Also ich habe zum Beispiel eine dritte Lösung mit einem Private VPN von meinem Telefon auf meine Node.
Weißt du, gibt es da irgendwie Untersuchungen? Gibt es da Leute, die sich mit dem Thema beschäftigen? Weiß ich jetzt konkret nichts. Aber da ist das Band. Du hast natürlich jetzt, erstmal geht es um den Anwendungsfall. Das VPN funktioniert für dich ganz gut, wenn du wirklich beide Devices natürlich kontrollierst. Das funktioniert jetzt aber nicht cool, wenn du jetzt irgendwie eine Online-Web-App irgendwie damit verwenden möchtest, weil diese Web-App nicht in deinem VPN ist.
Und die kannst du damit nicht reinbringen. Also das funktioniert mit deinem Handy ist im VPN und dein Homeserver ist in dem VPN, da funktioniert das. Aber wenn du jetzt sagst, diesen Z-Planner zum Beispiel verwenden möchtest oder auch getid.com als die Lightning-Adresse verwenden möchtest, dann wird das nicht funktionieren, weil die Services sind ja nicht in deinem VPN drin. Die werden nicht auf deine Node zugreifen können. Das heißt, da wird es nicht möglich sein.
Wenn du das nicht brauchst, wenn du das nur so machen möchtest, wie du es jetzt gerade hast, dann ist das super fein. Dann gibt es da jetzt kein anderes. Dann kannst du es nicht besser machen. Benchmarks glaube ich jetzt nicht so, dass das jetzt eigentlich ein großes Problem ist, weil es basiert halt eigentlich so, Websocket-Connections, das sind abgehangene Standards, die funktionieren ziemlich gut.
Und das, was bei dem Tor das Problem war, dass es halt durch, naja, einmal durch die Welt, durch verschiedene Onion-Routings irgendwo gegangen ist und da halt irgendjemand vielleicht irgendwie auch nur einen Raspberry Pi laufen lässt am anderen Ende der Welt und dadurch jetzt dein Traffic geroutet wird.
Und das ist natürlich dann irgendwie langsam oder diese Tor-Node dann gerade unter, weil die ja öffentlich auch zugänglich ist und unter Attack ist und die Nile-of-Service-Attacke hat, dann hast du das Problem. Ich glaube, das Problem hat man halt bei diesen Nostal-Relays an sich weniger. Na, aber Benchmarks kann ich dir da jetzt gerade nichts dazu sagen. Aber das ist eigentlich Realtime-Kommunikation. Okay, vielleicht kommt meine Frage doch aus der ganz anderen, oder aus der falschen Ecke.
Ich meine, so aus dem Nostal-Umfeld so ein bisschen wahrzunehmen, dass das Thema Relays ja noch nicht so ganz, keine glückliche Lösung ist. Man ist ja quasi auf einen Dritten angewiesen, der einen Relay für einen betreibt. Wir bräuchten eigentlich sehr viele Relays. Man bräuchte eigentlich auch Paid-Relays, um halt sicherzustellen, dass das Service auch wirklich sicher und vielleicht auch redundant läuft.
Genau, insofern, das hat für mich so ein bisschen sich danach angehört, als wäre das Thema, die Relay-Infrastruktur von Nostal ist noch nicht so ganz sicher. Sicher im Sinne von, es ist noch nicht gegeben, dass das wirklich beständig ist, dass es performant ist. Daher kam meine Frage jetzt. Genau, also ich wollte jetzt nicht irgendwie quasi den, ich verstehe schon den Vergleich jetzt mit einem Private VPN, das ist nicht möglich.
Mit Tor ist das wieder eine ganz andere Geschichte, weil es ja eine andere technische Lösung ist. Aber die Frage bleibt halt trotzdem, also besteht da ein Risiko, also insbesondere bezüglich Performance, glaube ich, da geht es ja hier drum, hauptsächlich mit diesen Nostal-Relays, wenn wir die als Infrastruktur benutzen. Ein wichtiger Punkt hier ist, dass man, glaube ich, Relay nicht gleich Relay setzen darf.
Und das ist auch insgesamt mit dem Namen vom Protokoll auch ein bisschen teilweise unverständlich, weil Nostal-Wallet-Connect, ja klar, das hat was mit Nostal zu tun und so weiter. Aber viele Leute meinen dann, ich brauche ein Nostal-Profile für, ich muss Nostal-Anwendungen benutzen und so weiter. Das stimmt eigentlich nicht, so was. Sondern es benutzt nur irgendwie die Nostal-Spezifikation und die Idee von den Relays als Kommunikationsweg.
Und so sind auch die Relays, ja, du könntest einen Standard-Public-Relay verwenden, mit dem auch irgendwelche Social-Media-Messages ausgetauscht werden, weil die das gleiche Format an sich haben und das gleiche Kommunikationsformat haben. Aber es gibt dann viel spezialisierte Relays, wie zum Beispiel wir betreiben einen Relay, das ist aber kein normales Nostal-Relay.
Wir akzeptieren dort keine Events, keine Social-Media-Events, die du verwendest, wenn du jetzt irgendwie dein censorship-resistant Messages publischen möchtest, sondern wir sind eigentlich nur ein Relay für die Wallets, für die Nostal-Wallet-Connect-Messages. Und das ist natürlich so ein bisschen ein anderer Ansatz. Und ich glaube viel, was das Thema in Nostal schon ist, dass ich abhängig bin von dem Relay, wenn ich jetzt meine censorship-resistant
Messages publischen möchte, so was. Oder auch im Vergleich zum Masterton, wo ich dann sage, ich habe irgendwie einen federated Server und der Server kann das kontrollieren und jetzt können wir sagen, bei Nostal kann das Relay das kontrollieren. Ich habe zwar meine Identität und ich kann woanders hingehen, das ist grandios, ein großer Unterschied oder so was, aber trotzdem hänge ich ein bisschen von dem Relay ab. Aber das ist ein anderer Use-Case, also das ist ein anderer Anwendungsfall.
Das heißt, diese Kritikpunkte passen da nicht so ganz. Und ich glaube auch, dass das Spannen der Nostal ist meiner Meinung nach gar nicht unbedingt das Social-Media-Aspekt davon, sondern all die anderen Dinge, die man noch drumherum machen kann, so wie jetzt das. >> So die Kleinigkeiten drumherum, so wie AlbiHub-Launch. >> Genau. >> Sehr schön. Ja cool, ich habe es auf jeden Fall jetzt besser verstanden. Ich glaube, da hatte ich auch noch, also ich bin Nostal irgendwie Neuling,
immer noch, musste noch echt einiges lernen. Also vielen Dank für deine Erklärung, es hat mir auf jeden Fall noch mal ein bisschen in meinem Verständnis geholfen. >> Aber das ist ganz, ganz wichtig, weil das ist halt eigentlich hier, wie HTTP oder so was. Also das hat jetzt nichts mit dem Nostal-Social-Media zu tun, sondern okay, das ist das Nostal-Protokoll und so wie HTTP, ja, hat man mal gehört, muss man aber auch nicht verstehen.
Man kann eine Webseite aufrufen und so funktioniert das halt hier auch. >> Cool. Du hattest eben was von 21.000 Satz für den Subscription-Service.
¶ Kanalmanagement mit Alby Hub
Vielleicht noch ein Punkt, der fällt mir jetzt gerade ein. So mit Channel-Management hatte ich irgendwo, glaube ich, auf der Webseite gelesen, dass ihr das irgendwie als Dienstleistung für diese 21.000 Satz im Monat auch irgendwie macht. Vielleicht können wir da noch mal reingehen. >> Was wir versuchen, ist ein paar gute sensible Defaults anzubieten. Also wir haben verschiedene LSPs integriert, Megalith, Olympus, LNServer, da gibt es irgendwie drei, vier, fünf LSPs per Default, um ja,
Inbound-Liquidity zum Beispiel auch zu bekommen. Und ich habe auch immer natürlich die Möglichkeit, selber Channels aufzumachen. Aber eines der schwierigsten Sachen ist ja immer, mit wem mache ich einen Channel auf? Mit wem mache ich einen Channel auf und wo bekomme ich Incoming-Liquidity her? Wer ist eine gute Node, um einen Channel aufzumachen? Und da sagen wir, wir schlagen halt Default-Nodes vor, die wir finden,
die sind gut. Und wir schlagen Default-LSPs vor, wo wir sagen, okay, das ist ein guter LSP für dich, um Incoming-Liquidity zu bekommen. Und wir versuchen, eine Art Wizard zu haben oder das zu automatisieren auch, dass das halt möglichst ein einfacher, smoother Prozess ist, den du idealerweise auch nur einmal ausführst. Du setzt einmal, connectest du dich mit dem Lightning-Network, indem du einen Channel aufmachst und dann hast du diesen Channel. Und dann kannst du senden und empfangen
und der Channel bleibt möglichst lange offen. Und du kannst dann genau diesen einen Hub mit diesem einen Channel kannst du in deinen unterschiedlichsten Anwendungen verwenden und du musst nicht überall wieder einen Channel aufmachen. Und das ist so der Ansatz. Das heißt, wenn du jetzt den Hub das erste Mal startest, sagt der, okay, hey, cool, willkommen, hast jetzt alles aufgesetzt, jetzt müsst du
dich noch ans Lightning-Network verbinden. Hier, wir schlagen dir vor, mit einem der LSPs eine Incoming-Liquidity zu bekommen. Die kostet was, natürlich. Das ist halt das Ding, muss man einmal bezahlen und dann hast du deinen Channel, dann kannst du loslegen. Und unsere Annahme ist dort auch, zum Beispiel, oder der Stand ist, was ja ein paar machen, ist so, dass die das on the fly machen, Channels aufmachen, wie Breeze zum Beispiel, das er gemacht hat.
Du hast einen Inweis erstellt, über 100.000, dann hast du irgendwie 90.000 bekommen oder 95.000 bekommen, weil irgendwie im Hintergrund ein Channel aufgemacht wurde. Dann hast du den nächsten Inweis gemacht und dann hast du die über 200.000 gemacht, dann musste wieder ein Channel aufgemacht werden, weil Breeze das ja gar nicht weiß, wie viel du eigentlich in der nächsten Zeit
empfangen willst. Und da ist halt eigentlich unsere Annahme zu sagen, okay, der Nutzer weiß das eh am besten, das ist auch das Einfachste zum Implementieren. Der Nutzer macht einmal, macht das Onboarding, muss halt einmal da durchgehen und dann kannst du den aber lange verwenden. Das heißt, ihr fragt dann den Nutzer aktiv, was er erwartet an Geldern zu bekommen oder wie findet ihr das raus? So genau, ja, prinzipiell. Also der Nutzer hat die Wahl.
Ich glaube, gerade bei dem ersten Channel, da kriegst du per Default einen Millionensatz, weil das so eine ganz gute Zahl eigentlich war von vielen Leuten. Aber in dem Flow, du hast so eine Node-Management-Seite, da kannst du auch dann "increase spending capacity" oder "increase spending and receiving capacity" machen. Da kannst du gerade einfach eine Zahl eingeben. Also das wird, ja, vielleicht wird das noch mehr automatisiert, aber der Nutzer hat da die Kontrolle, dass du das eingeben kannst.
Ist das, was du gerade gesagt hast, ist das so wie bei Phoenix und mit "splice in" und "splice out" dann? Oder geht das bei euch, geht das an der Stelle jetzt noch nicht? Nee, wir machen noch kein "splicing". Das kann auch LDK gerade noch nicht. Und da hast du auch immer Interoperabilitäts-Sachen mit den Channels. Und Phoenix macht halt viele Sachen, weil die beide Seiten kontrollieren. Die kontrollieren das Phoenix Wallet, aber auch die Phoenix
Node, wo der Channel aufgemacht wird. Und mit dem Hub ist eigentlich so, dass wir den Nutzern eigentlich auch die Freiheit geben möchten, mit jeglicher Node einen Channel aufzumachen. Du kannst mit einem LND-Node aufmachen, du kannst dir den LSP aussuchen, du kannst irgendwie auch mit deinen Freunden mit einem Core Lightning Node theoretisch einen Channel aufmachen. Und das hat halt den Vorteil, dass du diese Freiheit hast,
dass du das tun kannst, die Wahl hast. Aber das hat halt ein bisschen noch den Nachteil, dass ein paar Features vielleicht nicht so einfach gehen, wie wenn man alles kontrollieren würde. Aber es ist auch ganz klar, Phoenix ist da ein paar Jahre ahead. Die haben da ein paar Jahre Vorsprung, was das angeht. Ich glaube aber, dass das nicht wichtig ist, ehrlich gesagt.
Also ich glaube, dass das aus dem Grund nicht wichtig ist, weil ich setze es einmal auf und dann habe ich diesen Channel und dann muss ich nicht so oft einen Channel aufmachen. Und dann mache ich halt einen Swap-In, wenn ich irgendwie in der Merchant bin und einen Haufen Geld bekomme, dann mache ich nicht einen Swap-In, dann Swap ich es halt irgendwie auf meine On-Chain-Balance oder auf mein Liquid raus. Und vielleicht automatisieren wir das auch mal
noch im Wallet drin. Dann muss ich nicht irgendwie super komplizierte Things theoretisch machen. Vielleicht wird es irgendwann mal einfach. Klar, die Entwicklung wird weitergehen. Aber gerade glaube ich nicht, dass man das unbedingt braucht. Ja, wenn man dann natürlich sagt, der Kanal, der initial aufgemacht wurde, der reicht mir halt einfach, um mit meinem, was ich damit tun will, einfach umzusetzen. Das ist ja das, was Splicing, glaube ich, so ein bisschen
lösen will. Ich habe heute ein Szenario, wo ich die Kanalgröße brauche und zwei Jahre später merke ich dann auf einmal, ich brauche doch irgendwie doch die Doppel-Jet-Kapazität und will aber keine zwei Kanäle gleichzeitig haben, sondern will das alles in einem haben. Das ist ja so ein bisschen eigentlich so, um es einfach zu halten. Das hat sich jetzt ja auch erst geändert. Bis letztes Jahr war Phoenix
ja auch quasi noch so. Wenn der Kanal nicht gereicht hat, dann wurde ein zweiter parallel aufgemacht, so wie es halt eigentlich bei Breeze, was du gerade als Beispiel angeführt hast, ja genau so war. Ja, genau. Und ultimativ ist es so ein bisschen eine Kostenfrage. Eine Kostenfrage, das Kapital bereitzustellen für den Channel und eine Kostenfrage, dann eine On-Chain-Transaktion zu machen. Na gut, bei Splicing war ja auch eine On-Chain-Transaktion nötig.
Ich glaube, das war ja der Unterschied. Vorher waren es, glaube ich, zwei und Splicing hat es auf eine reduziert, um so ein bisschen die On-Chain-Kosten dann zu sparen. Aber gut. Jan-Paul, Karlso, habt ihr noch was? Ich habe keine weiteren Fragen. Das war wirklich sehr umfangreich und technisch teilweise war ich ein bisschen abgehangen, als Jan-Paul dann seine Noster-Fragen gestellt hat. Aber super spannend zu hören. Wir sind ja hier bei Spackgust. Ja, deswegen lobe ich mir auch den Anthomus,
wenn er da ist. Der steigt auch immer schön tief hinein. Deswegen Shoutout an ihn, wenn er zuhört, melde dich mal. Dann können wir da auch mal wieder noch eine Deep Dive-Folge machen zu diversen Themen. Danke dir, Bumi, für deine Ausführungen und Erklärungen. Danke euch, sehr cool. Ich finde, also ein Satz muss ich noch loswerden,
¶ Letzte Worte und Outro
weil ich leider hat das Node-Betreiben immer noch so ein bisschen so ein schlechtes, nicht ein schlechtes Image, aber ein kompliziertes Image. Ja, das stimmt. Ich glaube, dass wir das loswerden und loswerden können. Ich glaube, das ist viel noch in den Köpfen von den Leuten, aber so kompliziert ist es gar nicht. Heute, vor zwei Jahren, ja, super kompliziert, wie wir am Anfang hatten. Aber heute, auch wenn es lange gedauert hat, kommen wir langsam dahin, dass es eben nicht mehr so kompliziert ist
und dass es auch jeder kann. Es wird immer noch Ecken und Kanten geben, es wird immer noch Probleme geben oder sowas, aber der Vorteil ist halt so groß, dass ich eben halt meine eigene Node betreibe, mein Selbst-Sovereign irgendwie Bitcoin benutzen kann und das ist halt eigentlich schon sehr viel wert. Und da sollte niemand irgendwie wirklich Angst davor haben, sondern jeder soll es irgendwie mal ausprobieren. Das waren schon fast perfekte Schlussworte.
Ich stimme zu und würde sagen, gehen wir raus, oder? Ja. Bumi, vielen Dank nochmal, dass du da warst. Focus on the signal, not on the noise. Ciao, ciao. Mach's gut. Ciao. Danke schön. Ciao. Ciao. [Musik] Node Signal. Focus on the signal, not on the noise. [Musik] [Musik]