The Interledger Community 🌱: Web Monetization for Moodle

Web Monetization for Moodle - Final report

Andrew Hancox — Wed, 15 Dec 2021 16:25:54 +0000

Project Update

This is the final formal project update, we are grateful for having had the opportunity to take part in this programme and excited to share a complete picture of all the work undertaken.
While our formal involvement is now complete, we will advocate for the standards and philosophies this programme has brought together as well as maintain the work we have done through it.

The two major pieces of recent progress have been:

Supporting receipt verification in the Moodle plugin - more on that here

Launching and populating with content a web monetized learning management system for Bettercare - Bettercare Courses

Progress on objectives

Develop tooling

Moodle plugin

A plugin for Moodle sits at the core of this entire project, this has now been published on and is available for anyone to use:

moodle-local_webmonetization

The plugin has been submitted to the Moodle plugins databaseand has gone through it's first round of review and feedback.

Moodle plugins DB

Interledger PHP

Currently this library provides functionality to verify receipts and parse out the information contained within them but it is hoped that over time it will grow to offer more functionality.

InterledgerPHP

We have also suplied documentation in the form of a recent blog post:

Building and using a Receipt Verifier Service

Deliver a reference site

Throughout the project we have been maintaining a publicly available reference site, this has been used as a resource for people to see the Moodle plugin in action during demos. This site will remain available for the foreseeable future.

http://examplesite.opensourcelearning.co.uk

Building awareness, Communications and marketing

Online

Various conversations have been seeded throughout the Moodle forums and related sub-reddits and facebook groups.

In person

Many conversations have been had during the duration of this project with various decision makers with a particular focus on those delivering learning to marginalised groups and in areas porrly served by current main-stream payment solutions.

The conclusions

There are several key issues that came up in all conversations.

Awareness of the technology - Very few people have heard of the Interledger protocol and web monetization standard, where moving money around is concerned organisations tend to be highly risk averse and so look for options with visible track records.

Suspicion of block chain based solutions - There is a huge amount of hype around web3 and associated technologies which generates suspicion around their stablity and longevity. High profile hacks such as compromises of exchanges etc., while not directly related to this project create a climate of fear.

Browser support - The lack of support for Safari (mobile and desktop) and Chrome (mobile) is a major blocker. Desktop Safari is used by between 10% and 20% of users, on mobile Safari and Chrome combined have 95% market share. It's very dificult to expect publishers to rely on an income stream that cannot be generated from such a large proportion of their audience and making it mandatory for any element of the service would be impossible.

Lack of web monetization providers - A great deal of the benefits of working with an open standard become irrelevant where it's use is entirely dependent on one service provider, in this case Coil. Many of the benefits of non-traditional payment technologies around facilitating cross border transactions and allowing those with limited access to traditional payment solutions (e.g. credit cards) are undermined by the fact that the only option to monetize a browser is via a web-site which is only available in English and only accepts payment via credit card.

The next steps required to allow this technology to gain further adoption are for issues around browser support to be addressed and further options around monetization providers to emerge to create a truly global and accessible eco-system.

Partnerships

The most exciting output of this project has been the launch of a web monetization enabled learning management system for Bettercare.

Bettercare design learning programmes for healthcare professionals that are widely used by government and private hospitals, non-profit organisations and training institutions in South Africa and other countries. The learning programmes bring the latest developments in child, perinatal and HIV care to healthcare professionals working in challenging circumstances.

In building this platform we took the existing chapter quizzes and assessments included in the publications and brought them into a fully featured and configured LMS in order to centralise assessments, issue certificates and track completion. The hope is that as this platform becomes established it will motivate learners to build their skill sets by covering more content and progress their careers by acquiring certificates of completion.

The tool has webmonetization enabled throughout and it is hoped that as adoption of the technology grows a steady income stream will emerge.

The site is in the process of being rolled out to users and is now publicly available - Bettercare Courses

What’s next?

We have reached the end of the funded period but not the end of our engagement with the project.

For the next 12 months and foreseeable future beyond we will continue to:

Maintain the Moodle plugin and reference site
Maintain the InterledgerPHP library
Support and host a webmonetized learning management system for Bettercare
Advocate for the web monetization and interledger technologies

What community support would benefit your project?

We hope the community will engage with us in a few ways.

Reach out if you are interested in using the Moodle plugin and have any questions
Contribute to the InterledgerPHP library
Build new plugins using the InterledgerPHP library, current solutions for Wordpress and Drupal could benefit from functionality around receipts
Get in touch if you want help implementing receipt validation in your solution

Relevant links/resources

Building and using a Receipt Verifier Service

Andrew Hancox — Wed, 15 Dec 2021 16:20:32 +0000

Introduction

In order to monetize a web-site it is likely that the publishers of the content will need to deny access to some or all content to users who are not working with a web-monetized browser.

The concepts behind this are out-lined in the webmonetization documentation here and in the interledger specification here, however the documenation is quite abstract and the examples are all based on JavaScript single page application so we felt it worth sharing our experience achieving the same goals with backend PHP in the stack.

Detecting browser monetization

You can see the javacript code in context over in GitHub here.
This file is an AMD module and the init function is run once the dom is fully loaded and Moodle core Javascript has been bootstrapped.

The first thing the init function does is look to see if the document.monetization object exists, if it does not then it will re-driect the user to a page directing them instructions on setting up a webmonetized browser.

        init: function (requiremonetization, wantsurl) {
            if (document.monetization) {
                DO SOME STUFF
            } else if (requiremonetization) {
                var redirecturl = M.cfg.wwwroot + '/local/webmonetization/failed.php?contextid=' + M.cfg.contextid;
                window.location.href = redirecturl;
            }
        }
    };

If the browser does support web monetization then it binds a function to the monetizationprogress event that sends the receipt to a web service for validation, if the receipt is valid then the user is allowed to continue, otherwise they are redirected to an interstitial page where the user will wait until a valid receipt is submitted.

document.monetization.addEventListener('monetizationprogress', event => {
    var req = ajax.call([
        {
            methodname: 'local_webmonetization_handlereceipt', args: {
                receipt: event.detail.receipt,
                contextid: M.cfg.contextid
            }
        }
    ]);

    if (requiremonetization) {
        var redirecturl = M.cfg.wwwroot + '/local/webmonetization/interstitial.php?contextid=' + M.cfg.contextid;
        req[0].done(function (result) {
            if (result !== true) {
                window.location.href = redirecturl;
            } else if (wantsurl) {
                window.location.href = wantsurl;
            }
        }).fail(function () {
            window.location.href = redirecturl;
        });
    }
});

The code for the web service can be found here.

$verifier = receiptverifier::get_receiptverifier();
$result = $verifier->verify($receipt);

receiptverifier::set_lastsessionverificationresult($result);

You can see all it's doing is validating the receipt (more on this later...) and updating a property of the session that tracks the latest result. This gets checked before every page gets returned in the local_webmonetization_before_standard_html_head function contained in lib.php - if the user's most recent receipt failed to validate then the will get sent to an interstitial page to wait for a valid one, if their last page view detected that the browser is not web monetized then they will get sent to the page with instructions on how to proceed we mentioned earlier.

$forcepayment =
        !empty($paymentpointer->get('forcepayment'))
        &&
        !has_capability('local/webmonetization:ignoreforcepayment', $PAGE->context);

$lastverificationresult = receiptverifier::get_lastsessionverificationresult();
if (!$monetizationsetuppage && $forcepayment && !isset($lastverificationresult)) {
    redirect(new moodle_url('/local/webmonetization/interstitial.php', ['contextid' => $PAGE->context->id]));
} else if (!$monetizationsetuppage && $forcepayment && $lastverificationresult == false) {
    redirect(new moodle_url('/local/webmonetization/failed.php', ['contextid' => $PAGE->context->id]));
}

Building a local receipt verifier

The reference implementation in the webmonetization documentation supplies a node application that will verify receipts however it has a few drawbacks:

Privacy or deployment issues as it requires you to either deploy an additional web application or proxy all of your webmonetization related webservice calls through a third party service
Scaling issues as it adds additional webservice calls to various parts of the process and so increases latency, bandwidth etc. on something that will be happening every few seconds for every active user on your site
Functionality compromises as it does not surface all of the information contained within the reciept, e.g. amount transferred

In order to avoid these limitations we have provided a receipt verifier within the Moodle plugin.

There are two components to this:

The proxy that sits in front of the payment pointer proxy
The receipt verifier

The proxy

The job of the proxy is to generate a nonce and secret and then add them to the request headers of the call to the payment pointer.

$rawnonce = $receipthandler->generate_receipt_nonce();
$nonce = base64_encode($rawnonce);
$secret = base64_encode($receipthandler->generate_receipt_secret($rawnonce));
$webmonetizationid = $_SERVER['HTTP_WEB_MONETIZATION_ID'];

$curl = new curl();
$headers = [
        'accept: application/spsp4+json',
        'content-type: application/spsp4+json',
        "Web-Monetization-Id: $webmonetizationid",
        "Receipt-Nonce: $nonce",
        "Receipt-Secret: $secret"
];

$curl->setHeader($headers);

$result = $curl->get($paymentpointer);

It does this using the InterledgerPHP library:

public function generate_receipt_nonce(): string {
    return random_bytes(16);
}

public function generate_receipt_secret(string $nonce): string {
    $keygen = hash_hmac('sha256', utf8_encode(self::RECEIPT_SECRET_GENERATION_STRING), $this->receiptseed, true);
    return hash_hmac('sha256', $nonce, base64_encode($keygen), true);
}

The receipt verifier

Ealier on we described JavaScript code that registers an event handler to catch the monetizationprogress event that is fired by the browser and forward the receipt the browser plugin supplies to a web service for validation. It is here that the receipt verifier gets used.

The first important thing is does is use the InterledgerPHP library to parse the receipt:

$receipt = $receipthandler->parse_receipt($binreceipt);

The receipt is a binary blob that requires some relatively complex parsing as seen below - due to the potential volume of requests a response format such as JSON would create too much overhead.

$arrayofbytes = str_split($binaryreceipt);

if (count($arrayofbytes) !== 58) {
    throw new receiptexception('incorrect size');
}

$arrayofbinarybytes = [];
foreach ($arrayofbytes as $byte) {
    $arrayofbinarybytes[] = sprintf("%08b", ord($byte));
}

$version = bindec(array_slice($arrayofbinarybytes, 0, 1)[0]);

if ($version !== 1) {
    throw new receiptexception('unsupported receipt version');
}

$receipt = new receipt();
$receipt->nonce = implode('', array_slice($arrayofbytes, 1, 16));
$receipt->streamid = bindec(array_slice($arrayofbinarybytes, 17, 1)[0]);
$receipt->totalreceived = bindec(implode('', array_slice($arrayofbinarybytes, 18, 8)));

The next step is to validate the receipt, since it was generated by the browser it could have been spoofed so we need to ensure that it corresponds to an actual open payment stream. The receipt consists of two parts, the first portion is the body, the second portion is a hash of the body created using the secret we shared with the system that runs our payment pointer (and the user's browser is unaware of). We can validate the receipt by calculating our own hash of the receipt's body with the share secret and confirming it matches.

$arrayofbytes = str_split($binaryreceipt);

$arrayofbinarybytes = [];
foreach ($arrayofbytes as $byte) {
    $arrayofbinarybytes[] = sprintf("%08b", ord($byte));
}

$nonce = implode('', array_slice($arrayofbytes, 1, 16));
$receiptbody = implode('', array_slice($arrayofbytes, 0, 26));
$receipthmac = implode('', array_slice($arrayofbytes, 26, 32));

$receiptsecret = $this->generate_receipt_secret($nonce);

$calculatedhmac = hash_hmac('sha256', $receiptbody, $receiptsecret, true);

if ($receipthmac != $calculatedhmac) {
    return false;
}

return true;

Thanks for reading!

Building this element of the project was by far the most complicated aspect and we really hope this documentation will save other some time.

Web Monetization for Moodle — Grant Report #1

Andrew Hancox — Tue, 09 Feb 2021 16:18:42 +0000

Project Update

The focus for us to date has been to get an understanding of the web-monetization protocols and standards, their use-cases, use the tool for ourselves and built a basic proof of concept within Moodle.

Progress on objectives

Plugins

The first objective of the project is to build the plugins that will enable web monetisation within Moodle. We have built a basic Moodle plugin to manage 'monetization' meta tags across a Moodle site that is now available on GitHub
The next step for this plugin is to implement a receipt verifier so users can be prevented from viewing monetised content unless they have a Web Monetization agent present and enabled.

Reference site

As the use cases for web monetization within Moodle become clearer the plan for the reference site is evolving... Watch this space! In the mean time the plugin is installed and working on the OSL Example site

Partnerships

We are in the early stages of talking to a few organisations and looking at how they could use the web monetization tools within Moodle to generate income from their content.

Communications and marketing

The grand plans for conference presentations are on hold right now for obvious reasons but we're really excited about this project and have been pushing awareness across a number of channels including LinkedIn, Twitter, Reddit, the Moodle forums.
Expect to see a lot more noise when the plugins are completed (support receipt verification) and a reference site is launched.

The most exciting pieces of publicity are expected to come out of two developing partnerships which should really show the potential of this platform.

What’s next?

The key next steps are:
Finish building the plugins:
implement a receipt verifier
create a counter block

Build and launch a reference site

Engage with a partner to deliver a chunk of real world, web monetized, learning content

Generate buzz around all the above...

What community support would benefit your project?

A plugin for any content delivery platform is only as good as the content it's used for. Please reach out if you need help building, hosting or monetising e-learning content.

Hello world

Andrew Hancox — Tue, 26 Jan 2021 14:28:33 +0000

It's been a really interesting few days immersing myself in the Web Monetization specification and documentation. Having been building traditional e-commerce solutions for 15 years culminating in recently launching my own product I had to revisit a few pretty fundamental assumptions about how things should work - more on that in my next post.

I've always believed that the best way to learn any technology is to get hands on and build so I have gone straight ahead and built a basic but usable Moodle plugin up and pushed it to GitHub. As you can see from the todo list there are a lot of very obvious next steps I'll be working through in the immediate future.

Cracking on

Andrew Hancox — Thu, 21 Jan 2021 10:48:29 +0000

It's been an interesting three months at Open Source Learning, having got over the excitement of winning a grant the focus was on clearing the decks in order to start work culminating in a few new client sites and two product launches:
ECommerce
Version Control
At this point the twin forces of the pandemic and Christmas derailed things further but with business as usual work under control and having hit our stride with home schooling we're now excited to get down to business.