Gib (Round 1) — Final Grant Report

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:

1. Alice (the link sender) and Bob (the link receiver) install the Gib extension to their browser.
2. Alice generates a link using the browser extension and shares it with Bob.
3. Bob enters the link in the extension's input field and submits the input.
4. 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).
5. 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! 🥂