 Ja, gut. Willkommen zum Vortrag Workshop zu GNUTALA. In dem Workshop hier wollte ich drüber gehen, wie man TALA in Web-Anwendung integriert. Wir machen zwei Teile. Ich mache einen kurzen Überblick über die Ressourcen, die zur Verfügung stehen. Den zeichnen wir auf und dann kann man sich in kleinen Gruppen hinsetzen und gucken, ob man so eine Integration macht. So, fangen wir an mit der Architektur, wo wir sind. Das ist schlecht mit der Kamera wahrscheinlich. Soll ich einfach hierbleiben? Wir haben das normale bestehende Bankensystem. Das kann jetzt nicht was auf SEPA basierend sein, sondern was auf Bitcoin basierend. Wo der Kunde seinen Bankaccount hat, der Bezahldienstreist hat seinen Bankaccount und der Händler hat seinen Bankaccount. Und das Geld fließt dann eben vom Kunden zum Bezahldienstreister zum Händler. Und was dann eben passiert ist, wenn der Kunde das Geld an den Bezahldienstreisten überwiesen hat, kann er elektronische Münzen abheben, die landen an seiner elektronischen Geldbörse, kann die beim Händler ausgeben. Der Händler gibt dann die Münzen weiter an den Bezahldienstreister und der Bezahldienstreister sagt, ah, du bist bezahlt worden. Also überweiß ich dir das Geld und natürlich kann am Ende der Händler gucken, dass er sein Geld auch bekommen hat. Und wir reden also jetzt heute hauptsächlich darüber, wie das hier bei der Händler Integration ablaufen. Da haben wir also verschiedene Komponenten. Auf der einen Seite haben wir den bestehenden Webshop, wo der Kunde irgendwie sein Shopping Card zusammenbaut, sich seine Artikel ausfällt und so weiter. Dann sollte es irgendeine Business-Logic geben, was weiß ich, ich schick dem Kunden sein Produkt. Dann haben wir ein kleines SDK für einige Programmiersprachen, wo man eben sozusagen die Tade Integration mitmachen kann. Das geht sowas wie den Vertragstext zusammenbauen. Und dann gibt es das Tala-Backend, was sozusagen die Kryptografie macht. So, wir gehen jetzt mal davon aus, dass der Frontenteil, wo der Benutzer eben seinen Shopping Card ausfällt, das muss schon da sein. Das Backend ist ein Stück Software, was man einfach installiert hat, da gibt es ein Manual zu. Und wo es also im Wesigenum geht, ist eben zwischen den Fronten im Backend ein bisschen zu kommunizieren, wenn notwendig. Was macht das Backend? Das Backend macht zum einen, wenn ich den Vertragstext habe, muss ich ihn ja in das Wallet schicken. Das Wallet erwartet, dass der Vertragstext vom Händler unterschrieben wurde. Also die erste Funktion ist, das Backend unterschreibt den Vertragstext. In der elektronischen Signatur. Dann, wenn der Kunde bezahlt, gibt man sozusagen die Münzen, die man aus dem Bezahlvorgang bekommen hat, anders Backend weiter. Und das Backend sagt, hey, war das jetzt korrekte Bezahlung? Redet mit der Exchange, sagt hey, Exchange, ich bin bezahlt worden. Und dann sagt die Exchange, ja, okay, ist akzeptabel, ist okay. Das Backend speichert das ab und sagt an deinem Frontend, jawohl, du bist bezahlt worden. Und wie gesagt, speichert die ganzen kryptografischen Beweise, aber es speichert auch den Vertragstext ab, der abgeschlossen wurde und so weiter. Und dann kann man später auch von seinem Backoffice, also wenn man jetzt der Händler ist, möchte sehen, okay, was ist. Wie sieht es jetzt meinen Transaktionen aus? Kann eben gucken, ich habe hier in meinem Kontoauszug irgendwelche eingehenden Transaktionen von der Bank bekommen. Und dann fragen, welche Geschäftsprozesse wurden denn jetzt damit beglichen? Und umgekehrt kann ich mir sagen, ich habe hier diesen Vertragstext nicht abgeschlossen mit irgendeinem Kunden. Wo ist denn bitte mein Geld geblieben? Das nehmen wir als Tracking-API, das heißt, ich kann nachgucken, wo ist mein Geld? Oder ich habe Geld bekommen für welche Vertragslinger wirklich bezahlt worden. Und das sind alles Funktionen, die das Backend so bereitstellt, eben diese Anfrage beim Bezahldienstleister. Aber man muss natürlich mit dem Backoffice das dann auch wieder integrieren, dass man die entsprechenden Sachen bekommt. So, Überblick über die Dokumentation. Also wir haben einmal, haben wir die API.tallard.net-Webseite, wo uns dann die ganzen APIs beschrieben sind. Da sind die APIs beschrieben sowohl für das Backend bei Merchant als auch für die Exchange, als auch was jetzt eben das Fundent machen muss, sehr viele APIs. Dann gibt es die Git Repositories. Was dann noch wichtig ist, wir haben sozusagen zum Testen für die Testintegration öffentliche Dienste. Das heißt, man kann wirklich sich ja einen Bank, wir haben eine Bank am Laufen, wo man sich sozusagen eine Testwährung Geld abheben kann. Man kann sich einen Konto anlegen, was sozusagen auch als Händlerkonto nutzen könnte. Wir haben eine Exchange am Laufen, das heißt, man kann einfach gegen die, seinen Webshop-Testweise fahren und alles ausprobieren. Und wir haben auch ein öffentliches Backend. Das heißt, wenn ich jetzt zu Vorbilden mir als Händler mein eigenes Backend erstmal aufzusetzen, weil da brauche ich nichts programmieren, kann ich einfach auf dieses Backend drauf zugreifen und so tun, als ob das jetzt meins wäre. Dann geht das Geld zwar nicht auf mein Konto, sondern auf das Tutorial-Konto, aber der einzige Grund, dass ich mir auf welches Bankkonto geht, ist dann am Ende, das Geld. Und es gibt eben den Job, wo man auch einfach Sachen mit testen kann. Dann soll ich sagen, man kann alle diese Demos, also Bankport-Demo, Exchange-Demo auch durch Test ersetzen. Die Demo-Version sagen die aktuelle stabile Version von Tala. Die Test-Version ist die aktuellen Entwicklungsversion von Tala. Das heißt, da gibt es sozusagen mal zwei Varianten. Demo benutzt als Währung Kudos, Test benutzt als Währung Kudos. Und wenn wir in Produktionen sind, hoffen wir natürlich als Präverierung dann, Euro oder so was zu haben. So, was mache ich aber als erstes normalerweise, wenn ich als Händler da bin, muss ich erstmal feststellen, hat der Benutzer überhaupt Tala installiert? Das ist jetzt ein Kunde, bei dem ich Tala anbieten sollte. Da gibt es zwei Möglichkeiten. Die eine ist, ich möchte es wirklich im Anzeigen sagen, hier, Mitte, du kannst jetzt mit Tala bezahlen. Das könnte ich einfach prüfen, indem ich ein bisschen JavaScript reinschreibe. Dann habe ich diese Tala walletlib geschrieben. Wenn man die einbittet, kann man dann eben sagen, Tala on present mache irgendwas oder Tala on absent mache irgendwas anderes. Damit kann ich uns sagen, Elemente in meinem User-Interface ein- und ausschalten, je nachdem, ob Tala da ist. Das wäre jetzt die JavaScript-Variante. Wir unterstützen das gleiche auch mit CSS. Das heißt, wenn ich ein Website habe, wo ich sozusagen der Benutzer JavaScript ausgeschaltet, geht auch, da muss man einfach CSS-Text setzten. Dann kann man Elemente mit sichtbar oder unsichtbar schalten. Zumindest das. Komplizierter geht da nicht mehr. Andererseits, ich kann es auch einfach ignorieren, ob der Kunde installiert hat. Und wirklich erst beim Bezahlvorgang das machen. Das heißt hier, wenn jetzt der Kunde sozusagen auf Checkout geklickt hat, schicke ich ihm eine 402 zurück. Das muss ich eh immer machen. Und in der 402 schreibe ich rein X-Tala-Contract URL und dann eine URL, wo er den Vertragstext herbekommt. Was passiert jetzt hier? Wenn der Kunde das Tala-Vollet installiert hat, sagt das Tala-Vollet, da ist ein 402-Statuscode. Ah, der möchte die Webseite sich bezahlen und schaltet um auf Bezahlvorgang. Wenn kein Tala-Vollet installiert ist, ignoriert der Browser der 402, behandelt es genauso wie eine 200 OK und rendert den Dokumententext dahinter. Das heißt, da kann ich da meine Kreditkarrenformular oder sonst oder PayPal oder sonst irgendwas anzeigen. Das heißt, wenn der Kunde Tala hat, kriegt das Tala-Vollet, wenn der Tala nicht hat, kriegt er den Standardbezahlvorgang mit der Methode. Das ist eine Frage. Wir zeichnen auf, deswegen Mikro. Wir zeichnen in zweichen Zweitenteilen nicht auf. Du bist später reingekommen, deswegen. Also das ist, wie ich das initiieren kann. Es gibt auch die Möglichkeit, ohne einen weiteren HTTP-Request zu initiieren mit JavaScript, aber normalerweise, der Benutzer klickt auf, ich möchte Checkout machen, der Browser geht auf irgendeine Webseite und da gebe ich von 402 zurück, um den Bezahlvorgang zu initiieren. So, wenn jetzt Tala installiert ist, wird das Wallet diesen Shops-Generalcontact 42 herunterladen und der war es dann eben von da den Vertrachtstext. Insofern sieht der Vertrachtstext so aus wie sowas. Das ist einfach ein JSON-Dokument. Wo die entscheidenden Vertrachtsdetails drin sind. So, auf der einen Seite, ich sollte das in der Maus machen, ist mir gesagt worden. Hallo, wo ist meine Maus da? Ganz oben habe ich dieses Haarwire. Das ist im Wesigen der Hash über die Bankinformation vom Händler. Mit Salt. Das heißt, ich übertrage dem Kunden nicht mein Bankkonto, das steht nicht im Vertrachtstext, sondern das Hash von meinem Bankkonto steht drin. Das heißt, später kann ich dem Händler sagen, der Kunde wollte mir das Geld bezahlen. Das wird sozusagen auch vom Backend hinzugefügt. Dann steht natürlich sowas drin, wie viel soll der Kunde mir bezahlen? Wie hoch sind die Gebühren, die ich als Händler bereit bin zu übernehmen? Welchen Auditoren vertraue ich? Der Kunde sagt mir am Ende, ich habe folgende Bezahldienstleister gewählt. Und ich als Händler sage vorher, ich akzeptiere, dass Bezahldienstleister, die von folgenden Buchbrüfern geprüft werden, die sind für mich und Verlässlich usw. Also das sozusagen, da könnte jetzt die Bar finden, aber eben mit Public Key. Oder ich kann explizit auch sagen, folgende Bezahldienstleister akzeptiere ich. Und dann gibt es eben die Vertrachtstetails. Wer bin ich? Was sind meine Schlüssel? Welche, was für ein Produkt wird verkauft? Aber eben noch ganz wichtig, diese Fulfillmenturl hier. Das ist sozusagen, wo der Browser hingehen soll, wenn der Kunde sagt, ich möchte das Produkt kaufen. Und da wird dann der eigentliche Bezahlvorgang abgewickelt. So, dieses Jason rennet dann das Wallet für den Benutzer. Wir machen das ganz bewusst, dass du uns kein HTML schicken kannst für sowas, weil wir eben kontrollieren müssen, dass das richtig gerendert wird und nicht, dass die Webseite mal so, mal so rendert. Und deswegen im Jason Format. So, ja, das brauche ich nicht so. Bezahlvorgang mit Taylor. Insgesamt hier im Überblick. Wir haben eben am Anfang, dass ich mit dem Kunden den Vertrachtstext verhandle. Dann wird Taylor als Bezahldienstbesuch ebenfalls irgendwie ausgewählt. Der Kunde bekommt dann eben den Vertrachtstext, wird zu dieser Fulfillmenturl hinnavigieren und auf der Fulfillmenturl kommt dann nochmal der Hash vom Vertrachtstext, wird zurückgeliefert an ihn. Der Kunde schickt per HZP Post die Bezahldienstleist, also die Münzen sozusagen unterschrieben, die werden dann an den Bezahldienstleiter weiter gereicht vom Bake-End. Der Bezahldienstleister sagt, ja, Bezahlung war okay. Und dann sage ich sozusagen im Wallet, jawohl, der Bezahldienstvorgang war erfolgreich abgeschlossen. Und wenn das dann der Fall war, dann, das ist jetzt hier wichtig, dann wird die Fulfillmenturl nochmal reloaded vom Wallet und dann gibt es sozusagen die eigentlichen Inhalte. Es ist ein bisschen komplizierter, als was ich das vielleicht vorstellen würde. Das hängt mit verschiedenen Sachen zusammen. Also hier habe ich sozusagen per 402 den Kunden dazu gebracht, den Vertrachtstext mit Confirm Payments zu bestätigen. Jetzt geht der Kunde auf, geht das Wallet, navigiert den Browser auf die Fulfillmenturl hin und ich habe sozusagen diese Cross-Origin-Policy-Probleme. Ich kann als Wallet nicht auf eine beliebige Webseite posten und so was, deswegen muss jetzt hier, vom Händler kommt dann erstmal eine Seite, du hast noch nicht bezahlt, zurück. Da kommt nochmal ein 402 zurück vom Händler an das Wallet und sagt, hey, du hast noch nicht bezahlt. Dann sagt das Wallet, ah, hier ist mein Beweis, dass ich bezahlt habe. Und dann sagt das, sagt die Webseite, Jack, okay, akzeptiere ich, dass du bezahlt hast und dann mache ich einen Reload, um das Wallet zu bekommen. Das Ergebnis ist, dass, wenn ich später nochmal auf die Fulfillment-Seite gehen sollte, ich kann ja vielleicht per Bookmark oder sowas nochmal zurückkommen, dann sagt der, okay, Browser geht auf die Webseite und dann hat die Webseite sagt, okay, ich weiß, du hast schon bezahlt, kann direkt das ausliefern oder er sagt, hey, du hast noch nicht bezahlt, weil ich habe es irgendwie vergessen, okay, expired, was auch mal, oh, aber der Kunde hat doch schon bezahlt, hat schon bestätigt, dass du bezahlt hast und schickt einfach den Bezahlbeweis nochmal. Das heißt, aufgrund dieser Konstruktion geht es auch mit Bookmark sehr gut. Ich kann also diese Webseite, diese Fulfillment-Seite auch als Kunde Bookmark und kommen einfach wieder drauf hinaus. Und umgekehrt, wenn der Kunde seine Webseite mit der Fulfillment-UAL einem anderen Kunden, sag ich mal per E-Mail zuschickt, die URL der andere Kunde greift auf zu, dann kriegt er stattdessen den Vertrachtstext angezeigt und sagt, hey, möchten Sie das gleiche Produkt kaufen? Statt auf direkt auf diese Fulfillment-Sache zu kommen. Sehr verwirrend mit der Maus hier. Ja, was machen wir im Moment? Wir arbeiten auch immer daran, dass im Wallet ein paar Sachen schöner laufen. Im Moment gibt es noch keine Riefans im Wallet. Tata kann im Prinzip, kann man als Händler sagen, ich möchte diesen Kunden sein Geld zurückgeben. Das läuft jetzt im Backend schon drin, aber noch nicht im Wallet, deswegen können wir das noch nicht machen. Und wir arbeiten auch in dieser Auditor-Komponente und versuchen eben bessere Tutorials für diese Webshop-Integrationen zusammenzustellen. Die Tutorials findet ihr alle auf dieser Tata.NET E& Merchants Webseite, die habe ich auch hier irgendwo auf. So, wenn ihr auf diese Merchants Webseite geht, gibt es hier in diesem grünen Beichen, gibt es drei Tutorials. Einmal ist das, wie setze ich dieses Backend auf. Das ist im Wesichen, wo ihr als Händler konfigurieren müsst, okay, das ist mein Bankkonto, das ist meine CPII-Bahn, was auch immer. Da soll das Geld hinüberwiesen werden, das ist die höchsten Gebühren, die ich bereit bin zu bezahlen usw. Und dann gibt es hier eben, wie schreibe ich so ein, wie mache ich eine Frontend-Integration, das ist erstmal für PHP und Python angefangen. Das heißt, hier gibt es sozusagen Schritt-by-Schritt Einführungen, wie man jetzt diese Integration macht. Und wenn man die durchführt, solltet man am Ende einen einfachen Webshop haben, mit dem man Metaller bezahlen kann. Und das sollten wir dann jetzt gleich später gemeinsam machen, wenn Interesse besteht. Ansonsten soll ich noch sagen, bisher eben nur mit Kudos bezahlen, wir müssen eben das ganze legal als Finanzdienstleister aufsetzen, mit einer Bank zusammenarbeiten, dass wir das machen können und wir suchen dafür immer noch Partner und so weiter. Gut, gibt es noch Fragen zum Überblick, was man so hat? Informationsmaterialien sucht da noch irgendwas? Gut, dann würde ich sagen, setzen wir uns zusammen in kleineren Grüppchen und die Videoaufzeichnung ist dann vorbei. Danke schön.