Greetings from the Freesound Licensing team!
We hope that all of you are healthy & safe during this hard times.

As we mentioned in our previous report, we run into some conflicts between the requirements of our use case and the design principles of Web Monetization. Since we published that report, we have been doing research on how to overcome these issues and trying to find a method to be able to do one-time payments of larger amounts that the usual Web Monetization payments, mimicking standard online purchases. In this post, we explain the outcomes of our research hoping that this can be useful to others having similar issues. We also give a quick overview of other improvements we've been adding to the platform and end with some final conclusions.

One-time payments with Web Monetization?

Our requirements

The Freesound Licensing platform is expected to allow Freesound users to purchase sound licenses when they need usage rights that go beyond the Creative Commons license of the sounds in Freesound. For example, if a content creator wants to use a CC-BY-NC sound in a commercial project. This process only needs to be done once per user that wants to purchase a license, and the sound itself is consumed before or after purchasing. Therefore the Web Monetization model based on micropayments that are streamed while users consume content is not very suitable. In fact, this is states quite clearly in the Web Monetization non-goals definition:

Non-goals#
Online purchases#

Web Monetization is intended to enable very small payments. This distinction is important because very small payments can be performed with different levels of user consent, unlike larger payments, such as those used in traditional e-commerce.

Should pay continuously as the user consumes content.

We are not the only ones facing this situation and therefore we settled ourselves to look for alternatives and see if there's a way to match Web Monetization technologies with our use case.

Where to begin?

As the first step, we started reading every specification, documentation and similar projects published and related to our use case. At first glance, we had an intuition that STREAM transport layer is where we should look into and understand better, but as we dived deeper in the context of Web Monetization we saw that it would not be simple at all.

These are some of the resources we checked to learn about STREAM and related concepts:

• Deep Dive into Interledger
• SPSP tutorial by Ben Sharafian
• STREAM tutorial by Evan Schwartz

Coil streaming limitation

We realized that the problem arising in our case initially occurs at Web Monetization provider. Coil, the sender, streams micropayments as the user consumes the content on a web monetized site and the rate is fixed to $0.0001 USD/second. We can see it as a classic pool problem in math: if the volume of dripping water never changes, the time required to fill a larger pool takes much more time. Since our limitation is time and the price of a sound license in our platform is expected to be around $5, the user should stay on the same page nearly 13 hours to pay for a license! This makes it hard to find workarounds that suit our use case and, even if Coil allowed to increase the rate per second, the model does not seem to fit very well to our needs.

Possible Solutions & Similar Projects

When trying lo look for solutions to our problem, we came across a number of projects/ideas that could be useful for our case:

Micrio

A couple months ago, we opened a discussion in the community about whether an implementation for a use case similar to outs exists. We were directed to Micrio, a platform for creating interactive stories from ultra-resolution images.

The team of Micrio faced a similar issue as we did, and they came up with a really clever solution which mocks extra features into the Web Monetization API. The Web Monetization API spec suggestions can be found here. They offered users the ability to set a maximum rate per hour which compensates the fixed hour rate of Coil. For the ones that would like to try the extension, here it is. Continuing with the example from the previous section, with this solution, the pool can be filled more quickly than in the regular way. Still, this feature does not fix our one-time payment requirement which should not depend on the time that users spend on the licensing site.

In addition, there are some security concerns with the Micrio solution that were raised by @sid and that should be addressed.

Open Payments

Open Payments is a standard built on top of the Interledger protocol for interactions between wallets without requiring a Web Monetization provider. In this protocol, digital wallets can be anything varying from a bank account to a mobile money provider, and it serves for cases such as peer-to-peer, Web Monetization and so on.

The peer-to-peer case adopts an invoice-based approach. As in the Web Monetization API, both parts present each other their payment pointers and the invoices API is used to create an invoice which is shared to the client/sender to share the amount that needs to be transferred. Although Open Payments seems to be a problem solver with its peer-to-peer support, Coil is not a part of this solution. Therefore, we excluded the possibility of using Open Payments in our case.

Our experiments of a custom solution

After analyzing and reading the approaches, documentations and everything we could find, we started thinking about implementing a custom solution built on top of Micrio's idea. This solution includes using ILP SPSP Invoice server.
In Micrio’s solution, the website defines the amount, scale and code tags which are used to calculate the rate. In this case, the user pays as much as the web monetized website requires during the time spent on it. But to have a strict beginning and end of the payment time, after user decides to purchase an item (in our case, a sound license), a SPSP invoice can be sent. SPSP invoice API includes the amount, assetCode and assetScale fields which basically replace the meta tags in Micrio’s solution. After the amount stated in the invoice is paid, the STREAM connection can be closed. This idea may prevent the edge case in Micrio, the manipulation from the website to get the maximum amount that can be paid. Even though the idea sounded great to us, due to technical issues, we were not able to implement a proof of concept for our solution. And in any case, this would still be a hacky workaround to circumvent the core issue which is that our use case does not fit well with the concept of time-based payments.

Rafiki

A couple of weeks ago, the Coil team announced a new connector that could really bring a sensible solution to our use case: Rafiki. Rafiki is an ILP connector promising to unlock features that the current Web Monetization API cannot cover, including one-time large payments like the ones our use case requires. We reached to the team via Interledger Slack channel and as far as we know, the testnet instance and Rafiki won't be ready until late 2021. This is great news, but unfortunately for us this is too late as our Grant for the Web project has just ended.

Although the beta version is not yet available, there is a demo wallet and a system for discret payments. If you would like to learn more about Rafiki, here is an amazing video of the workshop at ILP Summit 2019 by Adrian Hope-Bailie.

Other work done in the Freesound Licensing platform

In parallel to the research of how to implement our payment requirements with Web Monetization, we continued further developing the platform. We updated a bit the design and added features for data visualization so the future users of the platform can visualize the purchased licenses to the sound authors according to some criteria such as the countries of the sound users who bought the license for their sound, the dates of the purchased license and so on. Here are a couple of screenshots:

Our current prototype of the platform has already implemented a number of features which bring the whole Freesound Licensing idea one step closer to reality:

• User account management
• Data visualization system for sound authors, platform owners and sound users
• Linking of sounds from Freesound database with sounds offered in the licensing programme (so sound authors can choose which sounds to be available in the licensing programme)
• License purchasing page (with no payment method implemented so far as the Web Monetization-based strategies did not fit well out purpose)

Summary of the report and our final comments...

Here in this post, we shared the outputs of our research and gave some information about protocols and solutions that can be useful for use cases similar to ours. Unfortunately we have concluded that Web Monetization technology in its current development state does not suit the requirements of our platform, but very soon once Rafiki is deployed and established this could change. For the development efforts of our Grant for the Web award this will unfortunately be too late, and therefore we won't be able to publish a prototype of the platform using Web Monetization technologies as we initially expected to do.

Nevertheless, thanks to the Grant for the Web award we've also been able to spend efforts into the development of Freesound Licensing, a platform that wants to implement a business model on top of Creative Commons licenses and to demonstrate that business on top open content is possible, can be beneficial for both creators and consumers and is better aligned with the open nature of the internet that we envision for the future.

We'd like to finish this report by thanking the team behind the Grant for the Web and the Web Monetization community for their support.