The Interledger Community 🌱: Sultan Eylem Atabay

Freesound Licensing - Grant Report #2

Sultan Eylem Atabay — Sat, 19 Jun 2021 09:37:53 +0000

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.

Freesound Licensing — Grant Report #1

Sultan Eylem Atabay — Fri, 26 Mar 2021 10:42:34 +0000

Introduction

Hi everyone! It's Eylem and Frederic 👋.

This is the first Grant Report about our project "Freesound Licensing". First of all, a little bit about us: We are the Music Technology Group (MTG), a research group of Universitat Pompeu Fabra in Barcelona, Spain. Among many other projects, at the MTG we make Freesound (https://freesound.org), and we're starting now the Freesound Licensing project. Freesound Licensing's goal is to provide a service to users who upload Creative Commons sounds to Freesound that will allow them to re-license the sounds to 3rd parties that need to use the sounds under terms not allowed by the original Creative Commons licenses. The goal is to provide a solution to the typical problem of someone wanting to use a CC-BY-NC sound from Freesound in a commercial project. Freesound Licensing will mediate between that someone and the sound author to generate a new license in exchange for a payment. This will benefit both uploaders and downloaders, but also, by keeping a small share of the license payments, Freesound Licensing will contribute to the sustainability of Freesound. As grantees from Grant for the Web, we have been able to dedicate some resources to the development of the platform and integration of Web Monetization technologies.

Progress on objectives

During the first phase of GftW, we moved step by step.👣

1️⃣ Get Familiar with Web monetization and related technologies

Currently, the Freesound platform only supports Creative Commons licensing and since we propose to establish a new licensing system via Web monetization, we carefully went over the documentation of Web Monetization, Coil, and Interledger.

2️⃣ Design the requirements of the Freesound Licensing platform

We love any sound and so do the users of the Freesound platform! Hence, we cautiously thought about the requirements of the platform to deliver a smooth and hassle-free experience to the users. We categorized our user profiles as sound author, sound user, and platform owner. We puzzled our heads and started to think about the needs of these user types.

3️⃣ Build the first prototype

After studying our case, defining the fundamental requirements, and getting clued on Web monetization and the features it provides, we rolled up our sleeves and dived into the technical part!

Here are some examples from the current implementation, v0.1:

Welcoming page:

License Purchasing:

Key activities

SRS
As a first step, after a brain-storming session, we came up with the possible user stories and how we can technically implement them. We mainly focused on the simplicity of the Freesound Licensing platform and how it can be integrated or be reusable for other scenarios.

Web Framework Selection

Since the Freesound platform is built with Django, we decided to move further with Python's Django Web Framework in this project and for Database, our choice was PostgreSQL. Currently, the licensing platform is not connected to the main platform, Freesound, but after finalizing it, we aim to integrate it to operate with the current Freesound platform.

Payment Method via Web Monetization

One of the problems we faced during the prototype implementation was the core functionality; payment via Web Monetization. In the Freesound Licensing platform, the transaction amount is larger than the amount that can be sent via Web Monetization (the minimum amount we have in mind is ~5$). Also, the notion of payment amounts depending on time spent is not a suitable idea for our use case because the sounds are consumed outside the Freesound Licensing platform. Therefore, we have been looking for a more optimal and suitable option such as working directly with Interledger protocol and STREAM.

What’s next?

📌 Our next and crucial step is to solve the license purchasing issue mentioned above via Web Monetization or implementation with Interledger protocol. For this, we will need input from the Web monetization community to see what is the best solution given our requirements. We'll investigate the work by @roelfjan and @sid because they might have already gone through some of the steps we need to follow now.

📌 One of the requirements we defined in SRS was to visualize the statistics of the purchased licenses to platform owner and sound author. We will implement a data visualization system for this purpose.

📌 Since it is the first prototype, we aim to transform the template of the Freesound Licensing platform to be suitable with the Freesound platform.

What community support would benefit your project?

As it was mentioned in one of our What's next? part, we are looking for a proper solution to our one-time-payment case.

We opened a discussion on this: https://community.webmonetization.org/ffont/comment/1ao and we recently received some relevant input. Thanks!