The Interledger Community 🌱: Joep Meindertsma

Solid based Data Spaces — Grant Report #2

Joep Meindertsma — Thu, 30 Dec 2021 13:54:30 +0000

Most of the people reading this will be at least a little interested in decentralizing the web. At Dexes, we're building software that help to achieve this. We write tools that give people more control over their data, and promote interoperability. One of our core objectives, is to make it easier to monetize data without losing control. Thanks to the Grant for the Web, we were able to add webmonetization to two open source data servers: Atomic Server and the DexPod (a Solid server).

Project Update

In our previous report, we shared a bit of our struggle. When we saw the Grant for the Web for the first time, we had the idea of using Interledger to facilitate transactions for data. We wanted users to be able to set a price for any arbitrary digital resource, and use payment pointers to handle the transaction. We basically learned that the things that we wanted to do with Interledger were not yet possible using the existing wallet implementations, since these focused on streaming payments, and not one-off payments. First, we tried solving this usecase by diving quite deep in the Interledger protocol, but we didn't manage to get our usecase working. We got in touch with the developers of Interledger, and learned that a new library was being made that will enable one-off transactions: Rafiki. We reached out to the Interledger Foundation and asked if we could perhaps pause our project and wait a bit longer, until december 1st 2021, to let Rafiki mature a bit. We regularly checked in to see if Rafiki could be used for our case, but we came to the conclusion that it's still a bit too early. We discussed an alternative approach to reach our goal of enabling payments, which is probably far more similar to how most other projects implemented Interledger: through Webmonezitation! We implemented this for two of our open source servers, the DexPod and Atomic Server.

Atomic Server: open source graph database for personal data, now with Web Monetization

For the past two years, we've been working on building a new open source database: Atomic Server. It's written in Rust, which helped make it a very performant, small, yet flexible application. It's a personal server that has been designed to run on low-end hardware, such as on a Raspberry Pi. This allows you to host your own Personal Online Datastore at a low cost. We've built the server and wrote the specification to help make the web more interoperable, and enhance data ownership.

We've implemented WebMonetization for Atomic Server. This means that you can Monetize any type of content, such as documents, webpages, videos or anything else straight from your Atomic Server. All you have to do, is add your payment-pointer property to a resource, and the client (Atomic-Data-Browser) will take care of the rest.

If you want to do this, follow these steps:

Set up an Atomic Server. The easiest is probably to run the docker one liner `or by runningcargo install atomic-server
Create some resource, or upload a file, and open the Edit panel.
Click add another property, and enter https://atomicdata.dev/property/paymentPointer.
Now, enter your payment pointer in the new field.
Press 'save'
That's it! You can now share your premium content URL, and it will only be shown if the client has Coil installed.

Open my example Premium Document here.

Check out the video below to see some of the other features in Atomic Server:

DexPod: open source Solid Pod implementation

The Solid project is an initiative by the inventor of the World Wide Web, sir Tim Berners-Lee. It's goal is to re-decentralize the internet, and give users more control over their data. We're building an implementation for this new Solid specification, called the DexPod.

We've added WebMonetization to this application, too. In the DexPod, users can upload files, and optionally add a PaymentPointer to them if they want to monetize that content. Similar to how this works in Atomic-Server, access is only given when a payment is succesful, and otherwise users will be shown instructions on how to get a wallet installed.

You can create a monetized resource by creating a DexPod on dexes.eu, then going to your pod (press menu -> go to pod), uploading a file, and adding your payment pointer.

Communications and marketing

Dexes has been in various media outlets 1, 2, 3, and I've given a radio interview on Atomic Data.

What’s next?

For one, we'll keep investing in Atomic Server and DexPod.

For the DexPod, one of the next steps is to further integrate with our Broker service. This will enable data owners to create custom machine readable agreements for sharing data. For example, a data owner may require that a data user is of a certain age, has a valid e-mail, and has made a succeful payment. We're collaborating with the Amsterdam Economic Board to find usecases for conditional data sharing. Payments are one of the most important conditions for us.

For Atomic Server, we've just released a desktop-build, and plan to release more libraries, tutorials and tools for developers to make apps for this ecosystem.

What community support would benefit your project?

We'd still like to implement one-off payments for data. The UX that we'd like to achieve, is one that is similar to conventional online payments - the user explicitly agrees to paying some amount of money, and is shown the content after the payment is transferred.

Additional comments

Thanks to the Interledger foundation for investing in the future of the web, and thank you to the GftW team for enabling all of this!

Relevant links/resources (optional)

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.