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.
Oldest comments (6)
That's very interesting – thank you. Did you get the sense that the Uphold API team would update their docs, or can you document your processes? Or do we each need to communicate with them directly to learn how to get Payment Pointers / ILP working with their API?
Interested also to hear to you chose ODRL. I have been looking at Accord wrt machine+human/Ricardian contracts; and while there's lots interesting there in making contracts execute code; it seems to miss that strength of a semantic framework, such as RDFa in CCRel.
Thanks for your reply, Nic! So far, the uphold team seemed very responsive and helpful. The part that's missing from the docs right now boils down to this:
Thanks alot Joep, that's great to know, especially as it appears straightforward enough to add cards.
Just a heads up: I've got some bad news about Interledger support in Uphold. Turns out it's currently receiving only, not sending. So we'll have to find a different way of doing payments.
That is bad news - thanks for the update. I guess we have to wait for Rafiki? write.as/coil/introducing-rafiki-a.... Tho "we will spend most of this year on the implementation" sounds like it could be a bit of a wait.
This is exactly what Rafiki is looking to fix, and yes won't be immediate but its an open project and will have incremental releases. It should be worth the wait considering how many of these issues are now bottlenecked. Our collective work in Web Monetization has help drive these updates to the ILP. We are discussion it as a community here: community.interledger.org/grantfor...