The Interledger Community 🌱: Alexander Mozeak

Gib (Round 2) — Grant Report #1

Alexander Mozeak — Wed, 18 May 2022 16:13:05 +0000

Hello Web Monetization Community!

Project Update

We’re back with the second interim report for our project, Gib. When we started working on Gib during the first round of Grant for the Web back in 2020, we had one mission: make sharing prepaid links to web monetized content as easy as possible. Though our initial implementation did not prove to be viable given the available technology, we persisted and ended the first grant period with a vision for how Gib could take shape. Incidentally, Interledger also announced the Rafiki toolkit around the time of our final grant report. Fast-forward to the middle of the current grant period and we have been able to make substantial progress toward that vision.

This time around, we have focused intensely on building the product. We have set up the hosting infrastructure to support our prototype launch, delved into the brand-new Rafiki project as a backend architecture, spun up some of the front end components that will make the prototype a success, and begun consulting with legal teams about the fiscal compliance of our product. Enabling all of this are some truly fantastic collaborators that we were able to bring on thanks to our Grant for the Web funding.

Progress on objectives

Before the grant period started, we set out to create a development environment that could be used to onboard teammates as quickly as possible. First, we conducted a preliminary security audit of our envisioned architecture, and found that the backend components of Rafiki would require a Dockerized environment running with root privileges. As a hedge against security pitfalls we generated an Ubuntu sandbox running inside of a VirtualBox VM, which we then used to successfully execute a running test instance of Rafiki from its GitHub repository. Rafiki’s test suites are exceptional, and we felt a real sense of wonder when we saw them run to completion on our test box.

In month 1 of the grant period, we continued work on our onboarding environment, with the aim of using GitHub Codespaces as a safe and shareable place for future collaborators to work on Gib. Unfortunately, Codespaces was running on a Microsoft Azure host that was not set up with the latest Linux kernel, which is required for some of Rafiki’s components to function. We raised discussions within the Codespaces community on GitHub and StackOverflow, but did not receive a response before we decided to change tack and go with a more configurable infrastructure provider.

At the same time in month 1, we began working on a different kind of infrastructure: the legal kind. We approached and onboarded Tamir Haddad, founder of Legal & Ops P.C., to provide us with General Counsel services. Tamir has helped us with tools and advice for hiring as well as open source licensing. Just as well, we met with with Kimberly Holzel – a Partner and expert in Fintech compliance from Goodwin Procter LLP – to figure out how we can navigate Gib through the various money licensing hurdles that face it. Through Kim, we discovered that we can potentially partner with an established financial institution that will act as the custodian of our Interledger-enabled digital wallets.

In month 2 we landed on Linode as our shared development environment and prototype hosting service. We were able to spin up an Ubuntu-based server running the latest Linux kernel and set up all of the other dependencies required to run Rafiki. This came together just in time for us to engage with our first developer contractor, Tyler Altenhofen. Tyler came to us through The Recurse Center (where Alex is also an alumni), with several years of programming experience under his belt.

Month 3 saw us complete onboarding Tyler, which was a learning experience for all of us trying to gather the various blog posts and pieces of documentation around the “money sender” side of the Web Monetization spec and reassembling them in a way that someone who is completely new to the project could hit the ground running with. We set up a project board on GitHub and took off from there. Tyler has since put together excellent implementations of our link generating browser extension, the Payment Manager installer, and part of the Payment Handler service.

Most recently, we have begun the work of implementing an API around Rafiki on our Linode server that will be used by our Payment Handler service to transfer money from a Gib wallet to a content creator’s payment pointer. We have also begun engaging with a motion graphics expert to bring the promise of Gib to light for content sharers of all stripes.

Lastly, Alex gave a lightning talk on Web Monetization to an audience of over 70 software developers at the Recurse Center’s annual Never Graduate Week! Slides from that presentation are available here.

Key activities

Money Transmitter Licensing (MTL) Partnership

Discussion is ongoing. On our own, getting licensed as a money transmitter in all 50 U.S. states (as a start for us) would be a long journey, so we are working to bring on an institutional partner that can expedite our compliance.

We spent the first half of the grant learning about the legal resources that would be most helpful for our project. We intend to spend the second half of the grant period engaging with said legal resources for specific and viable solutions.

Building the Prototype

Several of our internal components have been built out (e.g. the link database, the link generator extension, and the payment manager installation proxy).

A front end mock-up is being used as a waypoint to guide focused development of the prototype.

We have also secured the domain gib.gives to link to our project.

Integrating Rafiki

We have the Rafiki backend running with a passing test suite on our Linode host, and are defining endpoints based on the API contained therein for our Payment Handler service to interact with.

Communications and marketing

We are working with Kris Castro, a motion graphics expert, to develop a short animated explainer video of Gib and how it is enabled by the draft Web Monetization specification. Our goal is to have this media ready by the launch of the Gib prototype in July.

As previously mentioned, Alex spoke about Web Monetization at Recurse Center’s Never Graduate Week 2022 event. The slides from that talk are available here.

What’s next?

We will continue to work with Rafiki and aim to contribute to their open source codebase in the coming weeks. Early on, we contributed an issue to the Rafiki repository regarding GitHub Codespaces, but closed it without an attached PR as Codespaces configuration at the necessary level is out of our hands at this moment.

Furthermore, we will continue to work with our legal counsel to produce a viable and compliant financial partnership for our project.

We are also planning to host a launch event where we will debut our prototype to the public, along with our short edutainment video. Stay tuned for details!

What community support would benefit your project?

We would love to hear how other people have spun up Rafiki and what their experiences and takeaways from it have been. We would also love to consider more potential use cases for Gib from the community.

If you are in the NYC area and are interested in attending our video launch event, or are interested in watching our video when it goes live, drop us a line at hello@astar.app

Relevant links/resources

Web Monetization Presentation Slides

Gib (Round 1) — Final Grant Report

Alexander Mozeak — Tue, 13 Jul 2021 03:02:17 +0000

Introduction

Welcome to our final grant report for Gib! 🎊

Though this is the final report for our grant period, we certainly do not intend to stop working. Gib has turned out to be more challenging and much more layered than we had initially expected. Throughout our research, we've had to adapt our initial implementation to better fit available web platform features. In this report, we will discuss where we have taken things since these adjustments.

Project Update

We set out to build a demo based on the following flow from our whitepaper:

Alice (the link sender) and Bob (the link receiver) install the Gib extension to their browser.
Alice generates a link using the browser extension and shares it with Bob.
Bob enters the link in the extension's input field and submits the input.
Bob's browser redirects to the web monetized site, meanwhile the Gib Payment Handler service (hosted on a separate server) begins streaming payment to the specified payment pointer (i.e. to the website's content creator).
When Bob finishes his session, the extension signals to the Payment Handler service that it is time to cease streaming payments.

Although the user flow seems relatively straightforward on paper, it has been challenging to set up in practice. There is no publicly visible precedent for how to set up a streaming payment handler with an interactivity layer (a precedent that we aim to contribute to). Thus, there were plenty of occasions where we were stumped trying to adapt documentation for other, adjacent implementations to our needs.

We have not yet completed our prototype implementation, however, we have built out the architectural foundation of the "Web Monetization Provider" workflow as it currently stands. We look forward to collaborating with more stakeholders to overcome some of the challenges that we faced and aim to improve the process for future developers.

Progress on Objectives

First Attempts

When we first set out to work on Gib, we approached it using the product thinking process that we usually use to provide solutions to our general clientele. That is, we laid out a product roadmap, undertook a feasibility analysis, devised user personas, and diagrammed the user flows. Even as we carried out our work, though, we came to the realization that this project was like none either of us had worked on before.

Refactoring Our Approach

Normally, we build software for clients using existing tools and technologies that can directly address their needs, think PWAs with offline functionality or integrations with data APIs. In light of the fact that much of the proposed web monetization toolkit has not been implemented in major browsers, we had to reevaluate our approach (see our post about this here). This left us in a weird position, trying to choose between a web component-based and extension-based prototype implementation. Luckily Dominique, from the World Wide Web Consortium, generously offered his time and met with us to discuss the status of the proposed specification, providing guidance that informed our decision to settle on the extension-based approach that we are using for our prototype.

Building and Blockers

We began our build process by setting up the following architecture:

A Chrome extension to act as the user's Web Monetization Agent.
A service worker to be registered as the user's Payment Manager.
A hosted endpoint that implements the Gib Payment Method and streams payment to the desired payment pointer.

Quickly after this, however, we began encountering roadblocks. One of the main ones was that trying to construct a new PaymentRequest was not possible using our endpoint. Despite our payment method identifier being a valid URL, our extension threw the following error:

This could be related to the scope and permissions of our under-development extension, but we were unable to find relevant documentation to guide us toward a solution.

In any case, we believe that we can continue with a custom implementation of the PaymentRequestEvent per the proposed specification, since we don't need the full checkout UI that PaymentRequest provides.

Another blocker for us was that we weren't sure if some of the experimental features that we were trying to build around were behind existing feature flags. Though we are able to use the PaymentManager feature specified in ServiceWorkerRegistration, the experimental flag #service-worker-payment-apps does not currently exist in-browser. However, a seemingly related flag is available: #enable-web-payments-experimental-features.

Expected

Available

Lastly, there are gaps in our knowledge regarding how to build payment streams that work with the Interledger Protocol. Specifically, things like the condition entry in the proposed MonetizationRequest dictionary, which we have not figured out how to properly generate:

dictionary MonetizationRequest {
    required DOMString destination;
    required DOMString condition;
    required DOMString expiry;
    DOMString data;
  };

We are continuing to build our prototype despite these and other roadblocks, though, as we are committed to discovering new and more robust solutions.

Key activities

As stated above, we are currently working toward building our prototype. Our codebase (which has been pared down to reduce cruft from draft implementations) is viewable on our GitHub repo.

What’s next?

Though this is our final Grant Report, we will continue to work on our prototype, give feedback on the standard, and engage with the community.

We are excited to reach a point where we can announce the launch of our prototype to the Web Monetization community and, hopefully, help other potential Payment Handlers build interactive solutions.

What community support would benefit your project?

We appreciate any guidance we can get for our development process. If you have any feedback on the issues that we outlined above, or if you can foresee any other implementation quirks that we may encounter, please reach out to us in the comments or via staff@astar.app if you would like to help or collaborate!

Additional comments

We would like to thank the Grant for the Web founding collaborators (Coil, Mozilla, and Creative Commons) for providing us with the infrastructure and inspiration to embark upon this journey.

Just as well, we would like to thank Ayesha Ware and the Grant for the Web Program Team for helping us with program onboarding and logistics, and Dominique Hazael-Massieux from the W3C for his help with figuring out the mechanics of how to bring Gib to life.

Lastly, to the Web Monetization community at large, we look forward to engaging with you all more in the future; here's to our combined efforts to make the web a better place for everyone! 🥂

Gib (Round 1) — Whitepaper

Alexander Mozeak — Sat, 01 May 2021 18:49:34 +0000

Hello Web Monetization community!

Today we mark the end of the grant period for Gib! 🎉
It has been a long and remarkable journey for us here at A*, due in large part to our attempts to innovate during one of the most pressing times our society has endured in recent memory. To all of those that encouraged us, guided us, and even just listened to our maddened technology rants, we cannot thank you enough. We press on by the grace of your generous support.

As a marker to end our research, we have released a Whitepaper on our public Git repo, where you can also find design diagrams and other published work on Gib. We will be following up with a final report on our work over the grant period in the coming weeks.

Cheers,
Alex & Adelya

Gib (Round 1) — Web Monetized Gift Cards

Alexander Mozeak — Fri, 26 Feb 2021 19:44:19 +0000

Project Update

For the two of us here at A*, Gib is both a product and a research project. That is - as we research deeper into the Web Monetization specification, we discover new techniques and technologies that will help the product come to life. New lines of inquiry are also raised, through which we find new paths and opportunities.

Since our last blog post, we have crystallized the core implementation of Gib around the Payment Handler and Payment Method APIs. In order to reach our goal of providing a simple and elegant way for content producers to enable gift cards for their content, we must implement this subset of the Web Monetization specification. Let’s take a look at how things have moved in this direction.

Progress on Objectives

Overall, the Architecture and Design Phase has been extended as we have learned more about the tools available to us. Some items are due to be revised, but others have been affirmed as compatible with the Web Monetization specification:

Functional Specification

We are updating our functional specification to reflect an architecture more attuned to the Payment Handler and Method APIs.

Dataflow Diagrams

We have completed our Level 0 diagram, which encompasses a high-level overview of the capabilities for each Gib user type. We have also produced a series of Level 1 diagrams, which go into more detail about the processes that enable Gib to work as a system.

Design Specification

We are discussing the relative merits of having Gib embodied in a browser extension, versus a web component. We have lowered the priority on this decision in order to focus on implementing the Payment Handler and Method APIs.

We have also enabled monetization on our homepage at astar.app!

Key Activities

The last A&D phase task that we must tackle is updating the Functional and Design Specifications to account for implementation of the Payment Handler and Method APIs.

After that, we will begin implementing and testing the Gib Payment Handler and Gib Payment Method interfaces.

Communications and Marketing

We are committed to maintaining a transparent design and implementation process for Gib. These blog posts are one way to achieve that. Further, we have published our specification documents, product thinking materials, and dataflow diagrams to Gib’s GitHub repo; and will continue to do so with our materials as they are developed.

It is our hope that this documentation will allow other Web Monetization developers to understand the principles and methods that comprise Gib. Once we have finalized the publication, we will invite other developers to view and comment, which will help us establish an open-source community around the software.

What’s Next?

We have caught strong tailwinds from our research into the Web Monetization specification, and look forward to having much of our implementation of the Gib Payment Handler and Gib Payment Method completed and shareable in our next blog post.

What Community Support Would Benefit Gib?

We would love to hear from developers who have experience implementing W3C specifications (and especially testing against their provided suites). If you have such experience, please feel free to reach out to us at dev@astar.app.