Web Monetization for Solid based Data Spaces — Grant Report #1

Joep Meindertsma — Fri, 30 Apr 2021 12:21:53 +0000

Grantee FAQ - Web Monetization Community
Uphold payment API does not support interledger payments
Web Monetization for Solid based Data Spaces — Grant Report #1

Project Update

A lot of data is not being shared because there are technical or legal barriers to do so. At deXes we want to make sharing data easier while having respect for data ownership and privacy.

We are working on providing data marketplaces to groups of users that want to share data. One of the marketplaces we are working on is the Amsterdam Data Exchange (AmdEX). We’re building services to help people share data conditionally. This means that a data owner can set various requirements before someone gets access to and can use the data. For example, the data owner might require a valid email address, or an age check, a verifiable credential or some payment (we’ll get to that soon enough).

Facilitating a data marketplace means providing a couple of services: a secure place to store data, a way to make conditions and agreements transparent and the findability of the data.

First, data storage. One of the core values that we have is data ownership. Those who own data should retain control, and service providers (including us) should not manage or even have access to the data that individuals or organizations own. In order to accomplish such a decentralized level of data ownership, we need a high level of standardization. This is why we’ve decided to implement the Solid specification, and build a Personal Online Datastore (POD). We call this the deXPod, and we’ve open sourced it just a couple of weeks ago. The goals of this Pod is to manage data and provide identification services.

The second service that we’ll provide is service to be transparent on conditions and store agreements in data deals. A Data Deal is a legal agreement between two (or more) actors about some virtual resource. Generally, a data deal describes who gets to access which resource, under what conditions. Before an Offer turns into an Agreement, the various conditions have to be met. This is where a new service comes into play: the TrustBroker. The TrustBroker is an API that validates and manages Offers and Agreements, and checks conditions and signatures. It is a trusted third party, similar to a notary.

It is our goal to describe these Offers and Agreements in a standardized, interoperable and open manner. We are conforming to the W3C ODRL specification, a spec that makes legal policies machine-readable. One of the Conditions that will be described, are payments - and this is where Payment Pointers will come into play. Describing these payment requirements means specifying the shape of these Payment Requirement Conditions in RDF and JSON-LD. The protocol of how these payments will be verified will need to be compatible with the Solid ecosystem, which means compatibility with HTTP. Although ILP over HTTP does exist, it does not specify how requirements regarding payment resources should be described.

Progress on objectives for Grant for the Web

We’re not the only ones working on integrating webmonetization with the Solid ecosystem. We’ve spoken to the other individuals and organizations working on this topic, have had meetings and discussed issues in a new repository.

We’ve built and open sourced our Solid Pod server implementation, called the deXPod. This provides WebID-OIDC authentication, RDF content-type negotiation, and data management tools similar to Dropbox / Google drive.

A first draft of the DataDeal spec has also been created, but we’re currently aiming to replace this with the already existing ODRL specification.

The actual implementation of Interledger / Web monetization is where things are getting a bit more complicated. We initially aimed to use the Uphold API for transactions, since Uphold is one of the primary Wallet providers that have a powerful API and Interledger / Payment Pointer support. Unfortunately, getting the SDK to work failed, and when we ultimately got the API working, we noticed that payment pointers are not yet supported there. We got in touch with Uphold and luckily, the Uphold developers and support employees have been very helpful. Turns out there is in fact an API for interledger payments, but it wasn’t documented yet.

Key activities

Spec design, research, collaboration
Solid deXPod implementation
Uphold API / SKD / Interledger setup

Communications and marketing

We’re focussing our marketing efforts primarily on the Netherlands. We’re proud to have been featured on BNR (business news radio), and a couple of newspapers. This is partly due to our collaboration with the Amsterdam Economic Board and University of Amsterdam.

What’s next?

In the coming months, we’ll describe Interledger / WebMonetization transaction requirements using the aforementioned ODRL specification. We will also implement this in the aforementioned broker. We’ll also add the PaymentPointer handle form to our deXPod, using the newly created Payment Pointer namespace.

What community support would benefit your project?

We think one of the major hurdles in adoption of webmonetization is the wallet set-up if you want to have a payment pointer. There’s a limited number of options - and setting up one takes quite a bit of time. Setting up an Uphold account means verifying my phone number, taking pictures of my drivers license and filling in a bunch of forms. I understand that these are necessary due to regulations on banking, and Uphold has done a great job at complying to these regulations with a nice UX, but still it feels like this is a bit of a sore spot. I don’t have an answer on how to improve upon the current situation, though.