DEV Community: Coil

Building Payment systems for the World at Hackathons

Uchi Uchibeke — Mon, 07 Feb 2022 17:34:42 +0000

Hello everyone, welcome to 2022.

You probably already know this — because we’ve mentioned it a few times — but Coil champions and supports open-source projects and is privacy-first, by default. Over the years, Developer Relations at Coil has championed and sponsored teams that write Open Web Documentations and projects that empower open-source developers to get paid. Coil has also incubated many open-source projects like Tigerbeetle and Rafiki.

And we have no plans of slowing down. This year, Developer Relations at Coil is hyper-focused on enabling more developers to build open, transparent, and impactful payment systems for the world. We will support Developer events and Hackathons globally, host events and workshops, create mote content, and amplify the work for the Interledger and Web Monetization communities led by the Interledger Foundation. Furthermore, expect us to spotlight more Developers innovating around the Rafiki Project, Interledger, cross-chain Interledger-enabled wallets, open payments, financial inclusion, and inclusive web3.

To enable more developers to build open, transparent, and impactful payment systems for the world, opportunities for rapid prototyping and an enabling environment for rapid prototyping are key. That is why Coil will be at many Hackathons this year. In partnership with Major League Hacking (MLH), Coil will support developers to brainstorm and build payment solutions that connect existing and future rails so that no one is left behind, regardless of their location. Developers participating at 30+ MLH Weekend Hackathons will have an opportunity to build with Interledger, Rafiki, and Web Monetization. They will also get mentorship from developers at Coil, Interledger, and the broader Interledger, Web Monetization, and Grant for the Web communities.


EasyTravel - One of the Winners of the Coil Prize for Best Web Monetization Project

What to expect

Following Coil’s partnership with MLH in 2021, Coil will partner with Major League Hacking (MLH) in 2022 at 30+ Weekend Hackathons and three weeklong global Local Hack Days. In 2021, Coil sponsored the Coil Prize for The Best Web Monetization projects and provided six months of free Coil memberships to all participants at MLH Member events. This year, we are increasing our support with sweeter prizes and swags. Attend one of the Coil-sponsored events to learn more about the swag and prizes. While you wait to attend a Hackathon, see all upcoming events at the Coil Developer site.

Following Stefan’s announcement of Rafiki and the upcoming launch of a Rafiki-powered Interledger Wallet, Developers can expect to build with Rafiki, build Rafiki wallets and integrate with Interledger-enabled wallets. At future Hackathons, post-ILP Wallet launch, developers can expect to experience all the features of Interledger using the APIs that Rafiki exposes. To stay updated about Rafiki and everything Interledger, follow the Interledger Forum for updates, and join the monthly Interledger Community Calls led by Alex, Tech Lead at the Interledger Foundation.

Finally, we will be at Open Source Africa Festival, WordCamp Europe and other developer events in 2022. Follow along in the Developer Events page on the Coil Developer website.

Thank you!

As always, we are immensely grateful to you for supporting Web Monetization and Interledger.

Follow Coil on Twitter and remember to invite Coil to your next Developer event!

Interledger 2022 - The Year of Rafiki

Sabine Schaller — Wed, 26 Jan 2022 18:13:36 +0000

Last week, Microsoft announced that it was planning to acquire Activision Blizzard, which “will provide building blocks for the metaverse" and last year, Facebook renamed its corporation to Meta to reflect its aspirations to build the virtual future where people meet, work, and play. All of these activities will need some sort of payment, whether it is for the virtual meeting outfit, for payroll, or for entering a game. Even if you argue that a virtual currency may be enough for a virtual world, I doubt that there will be one currency that fits all purposes. Hence, an interoperability protocol is needed and that is exactly what Interledger is, connecting all kinds of ledgers from existing financial institutions to cryptocurrencies on blockchains, virtual currencies, and even offline payments systems.

Why are we ready to fly now?

For the first half of 2021, I was on maternity leave and spent 24/7 with my baby boy. When I rejoined the community later during the year, I was completely amazed by how much it had evolved.

In early 2021, Uchi Uchibeke had joined Coil as Head of Developer Relations & Experience, and an Interledger and Web Monetization stream has been part of many hackathons ever since, introducing more and more people to the concept of streaming payments online. He also hosts a bi-weekly Twitter Space targeted towards newcomers to the Interledger Protocol. In contrast to the community call, where members are more likely to talk about protocol specifics, the Twitter Space introduces parts of the Interledger stack or Web Monetization to those that want to get started with the technology.

Speaking of the community call, it has been taken over by Alex, the Technology Lead at the Interledger Foundation. Starting this year, the format changes to monthly calls with dedicated slots for updates from the Interledger Foundation, Fynbos, Coil, and Rafiki. Additionally, they are finally tackling our documentation. We have always had a lot of it, but it is in desperate need of reorganization. They’re making it easier for everybody to find what they are looking for–may it be a broad introduction or a fine-grained specification.

One specification that is currently experiencing a massive update is the Web Monetization specification. The main change is that we are moving away from meta tags and will be using link tags in the future. If you keep in mind that a payment pointer, which is included in the meta tag right now, is resolved to an endpoint URL, you realize that link tags are actually more suitable for Web Monetization. The nice benefit from that change is that you are now able to monetize different parts of your webpage by adding different payment pointers to respective link tags.

We also welcomed a new Interledger related company to the table in 2021. Right when I first opened Slack again to check what’s new after my maternity leave from Coil, I was surprised to learn that most of my South African colleagues were not there anymore.

What happened, did they all quit? Well, in fact they did but it wasn’t to leave the community but to start their own company Fynbos. One reason why Interledger is still so nascent is because money is involved. As soon as that is the case, participants need to be licensed money transmitters. Fynbos has set out to become such a licensed entity that offers Interledger-enabled accounts.

You may now think, “aren’t Uphold and Gatehub offering these already? What is new about Fynbos?’” Currently, your Uphold and Gatehub wallets only enable you to receive payments via Interledger but don’t permit you to send payments. Furthermore, these accounts don’t currently offer Open Payments functionality, namely invoices and mandates (possibly for recurring pull payments). All of this functionality will be unlocked with a Fynbos Interledger-enabled account, which is based on the open source package Rafiki.

What is Rafiki, my friend?

The Rafiki package was introduced in May 2021 by Coil’s CEO Stefan Thomas as the All-in-One solution for Interledger wallets. It is a set of APIs that enables the entire suite of Interledger and Open Payments functionalities like streaming payments (Web Monetization), sending discreet payments (tips and invoices), receiving payments, setting up recurring payments (mandates), and app-based payments.

Thus far, most of these functionalities only existed on paper. Rafiki will be the reference implementation, bundling all of them and hence allowing not just digital wallets but any payment provider to easily enable Interledger functionalities on their accounts. And it is fully open source!

Where is development at?

We got quite far in 2021, implementing sending, receiving, and invoices. Mandates are currently under review. However, the authentication/authorization part is still missing and we are currently discussing which specification to use. Should we stick to OAuth2 or move to GNAP, a relatively new approach to authorization which concentrates on grants. Additionally, we are working on documentation on how to run Rafiki locally using docker, such that early birds can already take a peek.

If you want to check the current progress of the development on Rafiki, check out the Github Project!

What is the timeline for 2022?

Depending on the authorization decision – OAuth2 or GNAP – a Rafiki MVP will be available sooner or a bit later during the year. If we stick to OAuth2, we anticipate having it by the end of Q1 / early Q2 2022. If we decide to use GNAP, we will have to implement it ourselves and won’t be able to rely on already existing OAuth2 solutions like Ory Hydra. Consequently, a fully functional Rafiki will only be available early during the second half of the year.

What else do we have in store for 2022?

Of course there are going to be hackathons again, not just on Web Monetization but also on Interledger and Rafiki to help you familiarize yourself with the new stack. Furthermore, we are planning to hold an ILP Summit again this year. I can’t wait for it to happen!

Please join the Interledger forum to keep updated about the latest news from the Interledger community and to hear about upcoming events.

Thank you, @Uchi, @Tiffany, @Alex, and @Adrian for your valuable feedback and support when writing this post.

Cover picture from Wikifur, modified, CC-BY-SA.

WMS changes part 2: Background information

Peter-Paul Koch — Tue, 26 Oct 2021 09:09:23 +0000

In part 1 we treated two upcoming breaking changes in web monetization. This article looks ahead to potential other changes, and introduces you to the reasoning behind them. It also gives one piece of background.

These changes will not take place immediately, but they will likely come into effect somewhere in 2022.

New events

Currently the Coil extension supports four events; you can read more about them here. These events are going to be revised, in particular because there is no error event that warns you of monetization stream errors.

The changing of the event model may be breaking change; we can't say yet because it's not yet certain exactly what the new events are going to be.

Errors

As with any request over the Internet, a lot can go wrong with web monetization requests. The Interledger protocol (ILP) that underlies web monetization is able to handle some of these problems itself. A payment request or response, or delivery of a receipt, may go wrong. Much like TCP, ILP has some built-in error correction mechanisms.

These corrected errors do not have to be reported to a web page, just as regular JavaScript events do not report TCP problems. It's only when ILP cannot recover from an error and gives up that browsers should be notified and should fire an event. Thus you as a web developer know that something exceptional has happened, and can react appropriately.

You might, for instance, decide to pause access to paid content, or decide to continue giving the user access for a while longer, until, for instance, several error messages have come in.

The problem with errors is that there are so many types. A networking error like the one described above is one of them, and it’s a complicated one. Will the extension fire an error event if a single payment or receipt goes missing? Or only when a whole string of them disappear? That has not been decided yet.

Simpler errors include the inability to connect a certain payment pointer (the pointer is probably wrong), or receiving invalid JSON as a response. Error events should certainly be fired in circumstances like these that prevent normal monetization.

Maybe a property should be added that states the nature of the error; incorrect pointer, invalid JSON, or network error. You'll likely want to do different things in these circumstances. This, too, has yet to be decided.

Monetization as a state machine

A first attempt has been made to define the states a web monetization stream can be in. In the future, the state property will reflect the state of the stream. Currently discussed values include:

error: an error has occurred, as discussed above
active: all's going well
paused: monetization possible, but not occurring right now; maybe the <link> tag has been temporarily disabled
idle: monetization possible, but the stream hasn't started yet.

Maybe the paused and idle values are going to be combined — that depends on how much difference there is between the two states.

pointers

Currently, if you want to access the payment pointer you do this:

document.monetization.pointer

The payment pointer contains the content of the <meta> tag, for instance $url.of.server/myID. Here several changes will take place as well:

document will change to navigator
the payment pointer will be in a <link> tag, not a <meta> tag and will become a valid URL instead of the current $-prepended string
Maybe the internal logic of pointer will change as well.

Part 1 discussed the first two changes. Here we’ll discuss the final change. Changing pointer’s internal logic would probably be a breaking change.

Multiple pointers

Currently a document can have only one payment pointer at a time. Future iterations of the specification might change this — consider, for instance, an article with three authors who split the money evenly. The document would need three payment pointers. But which one of them should be in pointer?

The likely answer is: none of them. Future versions of the spec will likely have a collection pointers that contains all payment pointers in the document. Maybe there will be an activePointer or activePointers property as well to denote payment pointers that are currently active — though it's unclear as yet how 'active pointers' will be defined.

In fact, it's not yet completely clear how to define multiple payment pointers. Multiple <link> tags? One tag with all the pointers? And if the three authors in the example do not split the proceeds evenly but, for instance, 50% / 25% / 25%, how are we going to add that information to the <link>? And to the JavaScript API?

These questions have to be solved before pointer can change.

media queries

Currently web monetization works at the HTML and JavaScript levels. It might be a good idea to bring the third leg of the front-end stool, CSS, into the mix as well. Maybe a monetization media query could be useful. Something like this:

.hidden-content {
    display: none;
}

@media all and (monetization: true) {
    .hidden-content {
        didplay: block;
    }
}

The question is exactly how it's going to be implemented. The current discussion sees two options:

A simple boolean flag: a page is either monetized or not monetized. This is what the simple example code above does.
A more nuanced system where the source of the payment stream is also considered. Examples could be ads, subscription, webmonetization, or other payment options.

The second option is clearly the most forward-thinking one, but also harder to implement. Once they support web monetization natively browsers will know if a page is web-monetized or not, but how will it learn a page is ad-monetized? Or subscription-monetized? We can probably find a solution, but it will take time.

Maybe the media query will be implemented before all these issues are solved. It's possible we'll just start with the webomnetization and none values and add new ones as they are implemented. Thus the example above might become:

.hidden-content {
    display: none;
}

@media all and (monetization: webmonetization) {
    .hidden-content {
        didplay: block;
    }
}

This discussion is still in its infancy, and it will take some time before a monetization media query actually exists.

With that, you are now up to speed on the near future of web monetization. We’ll let you know if new functionalities appear in the extension, or browsers start to support web monetization natively, or if the specification changes significantly.

WMS changes part 1: Breaking changes

Peter-Paul Koch — Tue, 12 Oct 2021 10:00:08 +0000

In this two-part series we will look at recent developments in the Web Monetization specification and the Coil extension. This article discusses two upcoming breaking changes, while the next one treats several planned changes that won’t take effect immediately, as well as one piece of background.

This year, two breaking changes will be introduced in the Web Monetization specification and the Coil extension. The payment pointer will move from the <meta> to the <link> tag, and the JavaScript monetization interface will move from document to navigator. We will discuss those two changes and what you have to do to adjust your code.

`<meta>` to `<link>`

When a user with the Coil extension — or, in the future, a browser that supports web monetization — visits a monetized page the browser has to fetch a JSON file with monetization information. The location of this file has to be defined somewhere. Where?

One of the decisions made in the Web Monetization workshop was to move this definition from the <meta> tag to the <link> tag.

The old situation

The Coil extension currently uses <meta>; for instance

<meta name="monetization" content="$url.of.server/someID">

Browsers now download the JSON file from url.of.server/someID.

In the first draft of web monetization this tag was useful because <meta> tags do not have any default behavior, and Coil's extension could do anything it liked. Since web monetization was a new idea Coil needed to be able to work unimpeded by earlier decisions and functionalities already baked into browsers. Thus, using a neutral tag like <meta> was a good idea.

Why `<link>`?

Meanwhile web monetization is entering a new stage, where it has to be made ready for formal specification and native browser support. Use of <meta> is starting to restrict the future standard and the current implementations. By contrast there are several reasons why <link> is more future-friendly.

<link> specifies a relationship of the HTML document it appears in with an external resource, while <meta> gives more information about the HTML document itself. From the browsers' perspective, web monetization is an external resource. It doesn't have anything to do with the rendering process of the page; it merely defines external functionality. Thus, <link> is the correct tag to use here.

In addition, <link> has some useful functionalities that are already built into browsers:

With <link>, browsers already have a fetching mechanism for downloading external assets such as style sheets and favicons. Adding the monetization JSON file as a new one is fairly easy.
<link>’s referrerpolicy attribute allows you to decide how much information about the page the user is visiting browsers will send while they fetch the JSON.
<link> allows you to decide what to do about cross-origin policies. If browsers fetch the JSON file, what kind of information about the user will be sent to the payment end-point? From a privacy perspective the best answer is None, and the crossorigin="anonymous" attribute makes sure nothing is sent. Still, it allows web developers to define other CORS policies if necessary.
The disabled attribute allows web authors to disable the monetization link if they want to pause monetization.
A <link> tag is equivalent to a Link HTTP header. HTTP headers allow monetization information to be added to non-HTML documents as well — such as a PDF with an article that you'd like to monetize. Right now neither the specification nor the extension support this, but it can be easily added in the future.

Again, the main reason for the switch is that <link> contains these functionalities out of the box. It is possible to add all of them to <meta>, but why bother if browsers already offer a perfectly good alternative? You can read more about <meta> vs. <link> in this discussion.

Changes to your pages

The switch to <link> is a breaking change because you have to add a <link> to your website instead of <meta>. Fortunately that's quite simple. If you have this <meta> tag

<meta name="monetization" content="$url.of.server/someID">

you replace it with this <link> tag:

<link rel="monetization" href="https://url.of.server/someID">

As you see, the content/href of the two is not exactly the same. The current <meta> tag does not use a URL, but the <link> tag is required to — it should link to an external resource, after all, and browsers can only find that resource if you use a proper URL. In this simple example, replacing the custom $ by the standard https:// is all that's necessary.

Unfortunately there are also more complex cases, where <meta content> does not map to <link href> one on one. Be sure to read the payment pointer syntax article in order to convert all your pointers correctly.

The current Coil extension supports both <meta> and <link>, so it should seamlessly switch between the two. Even if it finds both tags in the HTML the extension will make sure only one payment occurs. Once browsers start supporting web monetization natively they will only recognize <link> and ignore <meta>.

Setting the payment pointer

The only minor outstanding problem is the way you change the payment pointer. Up until now the only way to do so was to change the content attribute of the <meta> tag, like so:

<meta name="monetization" content="$url.of.server/someID" id="paymentPointer">

function changePointer() {
    let meta = document.querySelector('#paymentPointer');
    meta.setProperty('content','$url.of.server/myOtherID');
}

It's ugly, but it works. (For more information about the current JavaScript API, see this earlier article.)

Once you use <link>, though, you have to write a slightly different script, and if you use both <link> and <meta> you have to change both of them.

<meta name="monetization" content="$url.of.server/someID" id="paymentPointer">
<link rel="monetization" href="https://url.of.server/someID" id="otherPaymentPointer">

function changePointer() {
    let meta = document.querySelector('#paymentPointer');
    meta.setProperty('content','$url.of.server/myOtherID');
    let link = document.querySelector('#otherPaymentPointer');
    link.setProperty('href','https://url.of.server/myOtherID');
}

This is not impossible, but it's not very developer-friendly, either. What we need is a way to set the payment pointer directly in the API instead of messing about with HTML attributes. Ideally, it would be something like this:

function changePointer() {
    document.monetization.pointer = 'https://url.of.server/myOtherID';
}

Right now the extension supports getting the payment pointer in monetization.pointer, but not setting it. While a settable pointer is under discussion in the standards track, it turns out there are some issues that make it unlikely it will be implemented in the manner shown above. We’ll get back to this problem in the second part of this series.

document to navigator

The monetization interface is a collection of useful properties and events that let you monitor the monetization state of your web pages. The full current API is described here. Up until now it was a part of document, but it’s going to switch to navigator.

This, too, is a breaking change, and it has similar reasons as the switch from <link> to <meta>.

From document to navigator

At the moment the monetization interface is part of the document; for instance:

document.monetization.state

It's going to move to navigator, and this line of code will become:

navigator.monetization.state

Appending monetization to document has never made a lot of sense. Furthermore, document.monetization is a <div> tag, and that has never made any sense either.

In addition, appending monetization to the document could cause problems. It's possible to create a new document in JavaScript, and if monetiztion would be appended to that document it would also be monetized. This could lead to odd situations that it's better to prevent than repair.

Besides, the existence of web monetization is a top-level function of the browser, and not of the page. Moving it to navigator, especially in conjunction with moving the <meta> tag to a <link> tag, makes excellent sense. Also, navigator.monetization will no longer be a <div>.

The Coil extension will add navigator.monetization later this year — right now the road map says November. The Puma browser, which uses the Coil extension, will add it a few weeks later. For now they will also continue to support document.monetization.

Changes to your pages

Although there will be a transition period where the extension supports both, eventually support for document.monetization will end, and by that time this will become a breaking change.

That is, in the future any script that still uses document.monetization will break, since it cannot find the document.monetization interface. It should look for navigator.monetization instead, and you will have to code that explicitly. It’s best to do it right now so that you won’t have to worry again.

I advise you to do the following:

Throughout your scripts, change document.monetization to navigator.monetization.
Add the following snippet at the start of your script:

if (!navigator.monetization) {
    navigator.monetization = document.monetization
}

if (navigator.monetization) {
    // your scripts that use navigatior.monetization go here
}

If navigator.monetization does not exist, make it an alias of document.monetization. If your user’s browser does not support monetization document.monetization will not exist, either, but that’s OK.

Then check again if navigator.monetization exists. If it’s either supported natively or it’s an alias of document.monetization your script will run. If it’s still undefined your script will fail gracefully.

With that we have treated the upcoming changes in the Coil extension. Meanwhile, the Web Monetization standard remains in development, and it will likely introduce more changes. The next part in this series takes a look at a few.

How Coil supports the open-source projects we use

Uchi Uchibeke — Wed, 01 Sep 2021 11:02:02 +0000

For the past three months at Coil, we have started to develop Rafiki, an open-source All-In-One Solution for Interledger Wallets. Throughout the process, we have continued to think more deeply about how we support the open-source community and the packages that we use in Rafiki and at Coil. In this blog post, we are sharing some discoveries and decisions about what we want sustaining open-source to look like at Coil.

Supporting open-source projects and maintainers

Thinking about how we want to support the projects that we depend on, we derived for principles to consider:

Equitably support all projects

Currently, when you want to fund or donate to an open-source project, your contribution only touches the single package you choose. This approach benefits that package but leaves out the numerous packages that it depends on. If those dependency packages are smaller, don't have a very strong community to back them, or do not run promotions to sustain the project, the gap in support grows even more. This is unfortunately built into most systems. With funding options like GitHub Sponsors, Open Collective, Buy Me A Coffee, and others, donations only go to the single package and maintainers, and not packages that they depend on.

Promote transparency for all maintainers

With many open-source projects, we can see the history of maintenance, yet we cannot see a history of where donated funds go. Funds sometimes go to events, travel, and compensation for the core team, but not to the packages that enable the parent package to receive funds.

Fund projects that drive impact for the community and Coil

When we use open-source projects, we want to be able to fund those projects and the projects they depend on. All of the packages used, all the way down the dependency tree
should receive some money from Coil’s monthly donation.

Drive sustainability

We want our contribution to open source to drive sustainability for all projects that we use, not only the extremely popular projects. After all, it’s not just the popular projects that are used in our production codebase: it’s every dependency we have, all the way down the dependency trees, that make Coil as amazing as it is.


Title text: Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble.

Coil supports open-source Projects with Flossbank

As we continue to promote a free and open web, maintainers and communities continue to be a top priority. That’s why we’ve sponsored student Hackathons with Major league Hacking, and MozFest, and W3C’s TPAC, and that’s also why we’re announcing support for project maintainers through Flossbank.

We chose Flossbank as our donation mechanism because of its ability to traverse dependency trees and it's unique way of distributing our donation at each level. It’s by no means perfect, but we’re excited to see the effort being put toward a more equitable distribution of donations.

Some of the benefits of using Flossbank are:

Flossbank is maintenance-free. It’s impossible for us to continuously determine what our top open-source dependencies are, so we’re thrilled that Flossbank can automatically check out our GitHub to determine what packages should receive our donation, and how much of the donation they should receive.
Flossbank supports a wide range of dependencies. We believe our open-source dependences are just as valuable as the code our engineers write, down to each and every line. Why should we not compensate the engineers maintaining the open-source code the same way we compensate our own engineers?
Flossbank only take a fee to keep the lights on. Compared to other donation mechanisms, Flossbank takes only 1% of a donation, which means 99% of our donation hits the maintainers’ bank accounts. Compared to others, which take 10%, this is a huge marginal impact increase.

Donation impact

With Flossbank, we can measure the impact of our donations and see all the packages our donations have been allocated to. Every month, our donation is spread to the current packages that Coil is using. Over the past few months, this is how it’s shaken out:

Total top-level packages supported

During the month of August 2021, we supported 804 top-level Dependencies. These are dependencies we use across all of our organization’s Github repositories that are defined within our package manifests, files like package.json and requirements.txt, and Gemfile

Total packages supported

During the month of August 2021, we supported 2,509 Total Current Package Dependencies. These include our top-level packages, as well as every dependency of those packages, and dependencies of those packages, etc., etc. For example, we use and support node-fetch and, all of the dependencies that node-fetch uses.

Conclusion

As Coil develops more open-source technologies like Rafiki, we think it’s important to compensate developers who have open-sourced their code and actively maintain it. We think Flossbank is the first step to a more equitable and just method of doing so, and we’re excited to see where the open-source community heads from here, and how Coil will play a part in it.

To learn more about some projects Coil supports, see:

Flossbank at flossbank.com
Rafiki at github.com/interledger/rafiki
Tigerbeetle at tigerbeetle.com
Developer events at developers.coil.com

An Update from the Web Monetization Workshop

Uchi Uchibeke — Tue, 24 Aug 2021 14:59:37 +0000

This article shares some highlights and next steps from the recently concluded 2021 Web Monetization Workshop hosted by Coil. Follow along as the Web Monetization specifications see some new changes and updates.

Project Showcase

During the Project Showcase session at the Workshop, participants saw demos and talks from Developers, Designers, Creators, and others who shared their stories and experiences working with Web Monetization. At Showcase, we had 13 pre-recorded presentations by:

Matt Baer, Founder and CEO @ Write.as
Joel Wasserman, Founder @ Flossbank
Erica Hargreave, Immersive & Interactive Storyteller & Educator @ Ahimsa Media / StoryToGo / Roamancing
Michiel de Jong, Founder @ Ponder Source
Matt Mankins, Mozilla Fellow
Hannah Grijns, Concept developer @ Waag
Thomas Visco, Community and Partnerships Manager @ Permanent Legacy Foundation
Fernando Daguanno, Founder @ Alquimétricos
Matthew Henshall, CEO @ room.sh
Andrzej Mazur, Founder @ Enclave Games
Amber Case, Mozilla Fellow
Yuriy Dybskiy, CEO @ Puma Browser
Alex Lakatos, Technical Lead at Interledger Foundation

A replay of the Web Monetization Showcase is available at workshop.webmonetization.org.

Technical Architecture session

The technical discussion featured the following topics and feedback raised on Github, Community forum and Discussion channels.

On some of the discussed items, a consensus was reached about how to proceed and a spec update is currently underway. Below are the top 4 items:

Branding

Because the current Web Monetization logo/icon uses the dollar symbol, a working group is being formed to internationalize the Web Monetization logo and branding.

Furthermore, considerations are being made for a provider-independent Call to Action (CTA) phrase and icon like the Support me with Coil button to be used for the Web Monetization ecosystem.

Meta vs Link tag

After discussing the pros and cons of the vs tag, the tag was selected as the choice for setting payment pointers.

And a pull request has been created by W3C's Marcos Cáceres to update the specification from using to .

For backward compatibility, Providers like Coil will continue to support both the to tag.

Web Monetization Events

The MonetizationStart, MonetizationProgress and Stop events were discussed. And the events will be simplified from 3 events to 2 events in a future specification update. The proposed new events are:

Error
Progress

Document.monetization vs Navigator.Monetization

Currently, Web Monetization is implemented in the Document Object. However, for developer and browser vendor purposes, there was discussion to move the Monetization object to Navigator.

Further discussions on this topic are happening at https://github.com/WICG/webmonetization/issues/24

Future of the Web Monetization Specification

Anyone can contribute to Web Monetization and join the current maintainers to update the specs, build with Web Monetization, or support other maintainers. Some ways to get involved are:

Spec update

Create issues on Github. See issues
Open Pull Requests Pull Requests
Participate in community discussions and feedback. community.webmonetization.org

Implement Web Monetization in Browser

Browser Scholar program. Apply
Collaborate with browser vendors to implement Web Monetization Contact Interledger Foundation
Grant for the Web Apply for a Grant

Rafiki open source project

Contribute to Rafiki github.com/interledger/rafiki

Thank you for reading and watch the Workshop Showcase replay at workshop.webmonetization.org/stage/showcase2

The future of web monetization

Peter-Paul Koch — Tue, 13 Jul 2021 10:02:53 +0000

Part 1 of this series made clear why web monetization is a good thing. Part 2 described the Coil system at high level, while part 3 took a look at all those pesky details you need to know about.

In this article we’ll talk about the future. The immediate future mostly consists of a proper web monetization standard. For the more distant future the crucial question is how much interest there will be in web monetization, and whether the current model will remain intact or will change — and if so, how.

Standard

Coil is working on properly specifying web monetization, including the <meta> tag and API we discussed, with W3C. A draft standard is already available, but, as usual, these things take time.

The proposed draft is currently under discussion in the Web Platform Incubator Community Group, where proposals for new standards from unexpected corners can be discussed and, ideally, groomed for official W3C status.

What a WICG proposal needs most is practical implementation and usage data. Typically, this is easy to do for a browser vendor that can just include the proposal in its browser and see what happens next.

It’s harder for parties such as Coil who do not own a browser. That’s why uptake of the extension and creative use of the API, is so important: not only will user feedback improve the eventual specification, it will also convince other parties (read: browser vendors) that there is a serious use case for web monetization and a specification.

Eventually, web monetization should be supported natively, but that requires buy-in from the vendors. Right now only Puma implemented the proposal. Samsung Internet added the Coil add-on to the curated on-device list, which indicates a solid interest in web monetization — though without a Blink implementation it cannot proceed any further. The other browsers have not yet taken any steps.

Grant for the Web made a technical scholarship available that allowed a Firefox implementation to be written, although it has not yet been added to the browser. They are still looking for someone to port it to other engines.

New features

As soon as a proposal is implemented people start asking about new features, or updates of existing features. This is no different for Web Monetization.

One question is about RSS. If you monetize your blog, but you also offer the full content as an RSS feed, could you monetize that feed? It turns out that Atom already has a <link rel="monetization"> that could be used — provided RSS readers start doing something with this information, most likely transferring it to the page’s <meta> tag. As far as I know no RSS reader actually does so as yet.

Another interesting set of questions was asked around future functionality of the Web Monetization agent (currently the extension, but in the future the browsers). Would users be allowed to decide when they pay and how much? Either on a per-case basis or with block and allow lists?

And what if you have multiple extensions of different vendors installed. (That’s currently not an issue, since Coil is the only web monetization provider, but it might well become a problem in the future.)

What about donating a one-time sum to a specific page? That would be great for newspaper sites, who could decide to open their content to anyone who tips at least, I don’t know, $0.50 or so. One question is how long these users would retain access to that content, and if it’s for more than just the current session, where the fact that they have paid for the content will be stored. There are privacy issues here.

One question I have is if there should be a CSS way of showing extra content in addition to the JavaScript way. Something like this:

@media all and (monetization: monetized) {
    #extraContent {
        display: block;
    }
}

This sounds cool, but exactly when is a page monetized? When monetization has started (and the monetizationstart event fires in JavaScript)? That sounds reasonable, but it may take a few seconds, so it may take a little while before the extra content becomes visible, which could lead to a jagged user experience. On the other hand, the current extra content scripts that use monetizationstart have the same problem. A media query would not make things worse.

I’m not saying that this is the greatest idea ever. Instead, I want to encourage you to think about a broad range of topics in order to figure out whether monetization, or the tools we have at our disposal, can be extended even more, and in which ways. Creative thinking is very useful in this phase of the specification.

The future of web monetization

Still, new features are only part of the story. The other, and perhaps more exciting, part is how web monetization is going to develop in the future and how it will change the web.

Stephanie Rieger wrote a great paper about that future, and if you’re interested in web monetization beyond the details of the current implementation I recommend that you read it.

I won’t attempt to summarize it here, but Stephanie’s main focus is describing three possible futures for web monetization and using these as a a lens to discuss some problems we have to solve.

Will web monetization

allow the web to continue to work as it has in the past, just with more money for independent content creators? This is the most likely short-term outcome.
lead to one or two large monetizers that maintain payment streams from users to creators, leading to tiered access system akin to cable TV that concentrates on in-network content, however that may be defined — but the definition is being done by these large monetizers.
be extended to a complete virtual wallet system, where users may donate whatever they want, and monetization providers allow users to buy gift baskets with various tips. Also, there may be micro-subscriptions for a limited amount of time, or even donations for a specific image, phrase, or other bit of content — something you would retweet today.

Stephanie treats pros and cons of each model without extolling one over the others. It’s possible that one of her models is exactly on the mark, or that the future of monetization is found in a mix of these models.

Above all, reading this paper allows you to think ahead and decide what kind of future you would prefer, and why. And that, more than the details of the current system, is what’s most important in this exciting start-up phase of Web Monetization.

How to participate in the Web Monetization Workshop

Uchi Uchibeke — Thu, 08 Jul 2021 11:36:01 +0000

The countdown is on to Web Monetization workshop! And we hope you'll join us on July 28th at workshop.webmonetization.org.

There are many ways to participate in the workshop, and you can choose one or more of the options below!

1. Attend to watch the project Showcase

To attend the event and watch the project Showcase, RVSP at workshop.webmonetization.org. Only your email is required.

2. Submit topics for discussion

Is there a feature you would like to see supported in Web Monetization? Is there a challenge you have experienced working with or talking about Web Monetization? Or do you have new ideas or general feedback about the Web Monetization API, specification, documentation, or adoption? If yes, please share them, and we will curate them to be discussed during the workshop. You can create a new issue on the Web Monetization Github repo or reply below, and we will include it in the list.

3. Join the technical discussion session

The topics submitted above, alongside other community feedback received in the last few months, will be curated and discussed at the technical architecture session. The purpose of the architecture session include:

In-depth technical discussion on the declarative and imperative APIs
Discussion of community feedback
Update of the Web Monetization specification from agreements reached during the discussion

Session 1 will be led by Ben Sharafian, CTO of Coil, and Session 2 will be led by Marcos Caceres, Co-chair of Web Applications WG at W3C. Contact Uchi or email devs@coil.com to receive more information.

View the schedule at workshop.webmonetization.org/schedule.

4. Showcase your project

If would you like to do a 3 - 5 minute demo of your Web Monetization project, please reach out to Uchi, reply below, or email devs@coil.com to receive more information.

See you on July 28 at workshop.webmonetization.org!

Updated July 8, 2021.

The Web Monetization meta tag and API

Peter-Paul Koch — Tue, 06 Jul 2021 10:00:33 +0000

Part 1 of this series made clear why web monetization is a good thing. Part 2 described the Coil system at high level. In this third article we're going to take a closer look at details: the <meta> tag and the JavaScript API.

The Coil developer site contains more information about technical topics, including a few example scripts.

The meta tag

During the sign-up process for Coil and Interledger you set up a wallet, which enables you to receive payments. You are given a payment pointer for that wallet in the form $url.of.server/someID. In order to monetize a page you should add a <meta> tag on that page that contains this pointer:

<meta name="monetization" content="$url.of.server/someID">

Right now you need tthe Coil extension to read out the <meta> tag — but in the future, when browsers support web monetization natively, they will do so themselves. If a page contains multiple monetization <meta>tags the extension uses the first one and ignores the others.

All this works without JavaScript. Neither the current extension nor the future standard are reliant on scripting for the initiation of a payment stream. If you want to get any information, though, or if you want to change the payment stream’s direction, you need JavaScript.

You can change the payment pointer by changing the <meta>tag. It's ugly, but it works:

<meta name="monetization" content="$url.of.server/someID" id="paymentPointer">

function changePointer() {
    let meta = document.querySelector('#paymentPointer');
    meta.setProperty('content','$url.of.server/myOtherID');
}

The plugin will pick up on this change even in the middle of a session and divert all future payments to the new payment pointer.

One reason to do so is a collaborative article. If an article has, say, three authors, JavaScript could pick one of them at random and send the payment stream their way. Technically, you do this by switching the <meta>tag's content, as shown above. See this article for more information.

You could also use the Intersection Observer to figure out which page element is in view right now, and change the payment pointer based on that information. This could be useful if one page shows art by several creators, for instance. This article gives an overview and a code example.

Future: link

In the future specification the <meta> tag will likely change to a link tag, like this one:

<link rel="monetization" content="https://url.of.server/someID">

The reasons are complex and can be read here. The upcoming Firefox implementation uses this link, and not a <meta>.

That means that in the future any script that changes the payment pointer has to be rewritten, possibly changing the pointer in both the <meta> and the link tag. For that reason it would be nicer if the JavaScript API offered a direct, imperative way of setting the pointer, like:

document.monetization.pointer = '$url.of.server/someOtherID';

Right now the API doesn’t support this, although it is one of the many ideas under discussion.

JavaScript API

Since we’re on the topic anyway, let’s discuss the JavaScript API. It’s a light-weight, useful thing to have in your back pocket while messing about with payment streams. It consists of the document.monetization container, three events, and one property.

This API is part of the proposed standard, and if browsers start supporting web monetization natively they’ll take over this API as well. In that sense, current extension serves as a polyfill and scripts you write now will continue to work in the future.

document.monetization

document.monetization is the container for all API functionality, and its presence indicates that your current visitor supports monetization:

if (document.monetization) {
    // user may monetize you;
    // find out and do something
} else {
    // user is certain not to monetize you
}

document.monetization is a <div> DOM node that is not inserted into the document. Thus you can read document.monetization.nodeName and most other DOM properties, even though there is no practical reason to do so.

Making it a DOM node allows the firing of the custom monetization events we’ll treat in a moment. Without this trick it appears to be quite difficult to fire custom events from extensions, though specific information is surprisingly hard to find.

state

document.monetization.state contains information about the current monetization state. It can take three values:

started: a monetization stream has started and you will receive money. At least one valid Interledger package has been received.
pending: a monetization stream has not yet started, but the extension is trying to connect.
stopped: no monetization stream possible: the page has no <meta> tag, or the pointer is invalid.

If no <meta> tag is found the initial state is stopped. If a <meta> tag is present the initial state is pending.

If the <meta> tag contains no valid payment pointer the state becomes stopped. If a valid payment pointer is present the extension connects to the Interledger server and waits for the first package. Once that package arrives the state becomes started.

The state remains started even if the connection drops — the extension keeps track of the time spent on the site, after all.

If you change the payment pointer the extension first goes to pending and then to either started or stopped, depending on the validity of the new pointer.

So this snippet tells you if the user is currently paying you:

if (document.monetization && document.monetization.state === 'started') {
    // user is currently paying you
}

Events

document.monetization allows you to capture four events, three of which mirror the state property pretty closely:

monetizationpending: a monetization stream is being started up, but is not sending payments yet. Fires when the state is set to pending.
monetizationstart: a monetization stream has started. Fires when the state is set to started.
monetizationprogress: a new single payment has arrived. See below.
monetizationstop: a monetization stream has stopped. Fires when the state is set to stopped.

Typically, when a payer enters a payee’s page and a <meta> tag is present. the monetizationpending event will fire, followed by a monetizationstart event and an indeterminate amount of monetizationprogress events. If the payment pointer is invalid monetizationstop fires.

This is exactly the same sequence as with the state property, except that no event will fire if no <meta> tag is present. The sequence restarts at pending whenever you change the payment pointer.

The information the events deliver allows you to build a basic script to show/hide extra content:

if (document.monetization) {
    let extraContent = document.querySelector('#extraContent');
    document.monetization.addEventListener('monetizationstart',function() {
        extraContent.style.display = 'block'; 
        // or any other way of showing content
    });
    document.monetization.addEventListener('monetizationstop',function() {
        extraContent.style.display = 'none'; 
    });
}

Again, this script is fairly easy to hack, and won't work without JavaScript being enabled. It’s not suited for serious use, especially not in web development sites. Still, it serves as an example of using the monetization events.

monetizationprogress

The monetizartionprogress event fires whenever an Interledge package with a non-zero sum arrives from the Coil servers, which is generally every second or so. It contains information about the amount that's been paid so far, and you could use it to build a micropayment counter.

If the connection drops the payment stream also drops and the monetizationprogress event stops firing. If the connection is restored the event resumes after a new connection to the Interledger server has been made. As we saw before, the extension keeps track of the time the user has spent on your site, and the first payment after the restoration of the connection will pay for that entire time. Thus, you cannot assume that the payer stopped paying just because monetizationprogress stops firing.

Event properties

If you want to find out wha the current payment status is you can use the special properties of these events. All these are properties of event.detail.

amount is the amount contained in the current Interledger package, as an integer.
assetCode is a code for the currency, either a cryptocurrency or a real one.
assetScale is the number of places past the decimal for the amount. This serves to keep amount an integer.
paymentPointer is the payment pointer the extension read from the <meta> tag.
receipt is a proof of payment sent back to the payer.
requestID is a transient ID temporarily assigned to your payment stream.

For instance, this gives you the amount the last package delivered:

document.monetization.addEventListener('monetizationprogress',function(e){
    let amt = e.detail.amount;
    let scale = e.detail.assetScale;
    let code = e.detail.assetCode;
    let amount = amt * Math.pow(10,-scale);
    let printableAmount = code + ' ' + amount;
    // do something with amount or printableAmount
})

paymentPointer contains the same information as the <meta> tag. receipt and requestID contain values that are internal to the Interledger packages. You can use it to write a receipt verifyer if you like.

Reading out the amount of money an Interledger package contains requires the amount-related properties. For instance, if amount is 17 and assetScale is 3 you received 17*10^-3, or 0.017, of the currency indicated in assetCode.

That concludes our study of the <meta> tag and API. In the final part we’ll take a look at web monetization’s future, which includes a formal W3C standard.

How Coil works

Peter-Paul Koch — Tue, 29 Jun 2021 10:07:16 +0000

Part 1 of this series made clear why web monetization is a good thing and we web developers should start paying for our articles and documentation. In this second article we’ll take a look at how Coil works.

Step 1: Register with Coil

First, both payer and payee should register with Coil. Unfortunately, for payees this process is not yet as streamlined as it could be.

For now payees need to register both with Coil and with an Interledger-enabled wallet where you can receive payments. This double sign-up is annoying, and you need to remember both sets of credentials. Coil is working on integrating the Interledger part into its service, but this integration has not yet finished at the time of writing.

And what, you might ask, is Interledger? It is an open protocol for exchanging money - initially between cryptocurrency servers, but now also to regular bank accounts. This series will not treat Interledger in more detail, but it is the technical basis for any web monetization system, Coil and all future ones. Stephanie Rieger wrote a great, non-technical introduction to Interledger for those who are interested.

Step 2: Add meta tag

During sign-up payees are given a payment pointer for that wallet in the form $url.of.server/someID. You should insert a <meta> tag into each page that you want to monetize, like:

<meta name="monetization" content="$url.of.server/someID">

This tells Coil where to send payments to. We’ll take a closer look at this <meta> tag in the next part of this series.

Step 3: Install extension

The payer should install the Coil extension in order to actually pay money.

The only browser to support the draft Web Monetization specification is the Gecko-based Puma Browser for Android. Until more browsers support the standard natively you will have to use an extension. A Safari extension is not yet available, but all other major browsers have one.

The extension works with HTTPS and HTTP connections, but not with FILE connections — something to keep in mind during testing.

Step 4: Restrict content

The payee can offer extra content to paying visitors. In the future this might become a vital feature. For instance, you could decide that your blog posts are only visible to users that pay you for the first two weeks or so, after which the paywall will be removed. Or you may keep access to some vital articles restricted to paying users forever.

At the moment hiding content can only be done via a fairly easy to hack scripting solution that we’ll take a closer look at in the next part. A server-side solution is not yet available at the time of writing, though Coil is aware of its importance.

Coil created a Wordpress plugin, and more plugins for other systems are in the works. Still, the most important feature would be a server-side solution to detect the presence of a monetization stream, so that the server can decide whether to send extra content or not. This feature is lacking as of right now, and the Wordpress plugin also relies on JavaScript to show and hide extra content.

Privacy

Coil is serious about privacy. It retains the minimum amount of data it needs to function. It needs to know who you are for its core service (duh) but does not divulge that information to anyone you pay or anyone who pays you. Every payment you make is an anonymous transaction.

The extension you install in your browser must be able to see the Interledger wallet it should pay to (duh), but does not store the URLs of sites you visited. The payee does not get any information about you, either, except for the amount of money you paid.

The extension needs permission to read your browsing history. For obscure reasons this is necessary to deliver payments. Coil does not actually read your browser history.

For more information you should read the Coil privacy statement, which is one of the clearest ones I've ever read.

The payment stream

If you added the <meta> tag to your site, and a user with the Coil extension visits you, you're getting paid. How much? How does it work?

Coil pays out US$0.36 per hour for every visitor of your site. That's not a huge amount of money, but if several thousands of people visit your page for 10 minutes each ... well, you can do the math. Web monetization is about a large number of people paying a small amount each.

There's a catch here. All payers give Coil a fixed amount per month, currently US$5, and if Coil has spent that amount they can give no more. In order to prevent sites you visit later in your billing month getting nothing, Coil starts throttling the payer's payments once $4.50 is spent, and pays a lower amount.

Coil intentionally pays a flat rate. If payers or payees would be able to set prices they would initiate a race to the bottom, where payees would ask for less and less money in order to attract more payers, while payers would cap their payments at the lowest possible level. Since this state of affairs is almost indistinguishable from the current free-content model, Coil decided to short-circuit it by establishing flat rates. See this discussion for more informtion.

Technically, every second or so the extension sends out an Interledger request and, ideally, receives a positive response. At that time a tiny amount is transferred from payer to payee. This process does not need JavaScript to run, though there are JavaScript events that allow you to monitor the process. We’ll get back to those in the next part.

For each request the extension reads out the <meta> tag anew. Thus, if the tag's contents have been changed in the mean time, the extension automatically redirects the payment stream to the new ID.

If the payer loses their connection the payment stream will stop, but the extension will remember how much time the payer spent on the payee's site. Once the connection is restored the extension will calculate the balance and send out an Interledger request for that amount. This information is lost if the payer closes their browser window before the connection is restored, however.

If a monetized page disappears into the background, for instance because the user opens another tab, the payment stream is supposed to stop, only to resume when the user brings the page to the foreground. However, my tests indicate that this is not actually the case, and that the payment stream continues even while the page is in the background. This is an unsolved problem at the time of writing — maybe my tests are incorrect; maybe it’s a bug in the extension; maybe the payment stream is supposed to continue.

Now we have a bird’s eye overview of how Coil works. Part 3 will describe the <meta> tag and the JavaScript API, and in part 4 we’ll take a look at the future, which includes a formal W3C standard.

20 Web Monetized Projects to Inspire You

Didicodes — Wed, 23 Jun 2021 16:07:52 +0000

Until recently, the only way content creators could make money was through advertising or other business models that take advantage of a user's privacy.

But with the proposed W3C Web Monetization API, creators now have a revenue model that empowers them to make money from their users without advertising, forcing them to subscribe, or invading their privacy. Amazing right? 😍

There are a ton of developers across the world who are experimenting with Web Monetization. Want to see them? You are in the right place. 😀

In this article, I collated a list of projects using Web Monetization to make money and offer their users exciting perks.

Cinnamon

Cinnamon is a community-driven content creation platform that allows users to view and create videos while providing native cross-app sharing.

It uses web monetization to allow video creators to earn from their content without bugging the viewers with unnecessary advertisements.

With a fee of only $5, Cinnamon grants viewers ad-free access to all videos available on the platform. Then pays the video creators in real-time.

This means that creators do not have to wait until the end of the month to be paid like traditional video streaming platforms because Cinnamon uses Web monetization to redistribute funds based on the time viewers spend on video content.

Simmer

Simmer is a platform for Indie game developers to host their creations in the browser for free with a single drag and drop mechanism.

Simmer was one of the first game portals to integrate with the Web Monetization API. Through this integration, creators can generate their payment pointer from Coil, paste it into Simmer's game editor UI to make their games monetized automatically.

If you are a game developer, you should take advantage of the engaging audience on Simmer by uploading your games and making money at the same time.

Twitch

Twitch is a live streaming service that allows users to create channels, run broadcasts, and interact with their viewers.

Thanks to the automatic Web Monetization support on twitch, viewers can support their favorite Twitch Partners and Affiliates by simply watching their streams.

Then Coil keeps track of how much each streamer has earned and then purchases Twitch Bits when the minimum purchase threshold is reached for that particular streamer. Pretty cool, right?

Hashnode

Hashnode enables developers to create a blog mapped to their domain for free. So they can focus on developing and sharing content on their blogs while we take care of the rest - customization, readership, visibility, web monetization, and so much more.

As a reader, you'll get access to all the tech articles for free without any ads or restrictions. On the other hand, the creators get to make money based on the amount of time any Coil subscriber spends on their blog.

Web Monetization has changed a lot of things. Gone are those days where we thought the only way to make money as a blogger was through ads or adding a paywall.

Imgur Emerald

Imgur is the easiest way to discover and enjoy the magic of the Internet. It's where you'll find the funniest, most informative, and inspiring images, memes, GIFs, and visual stories served up in an endless stream of bite-sized fun.

Powered by a passionate community of people worldwide, anyone can join to share cool stuff and vote the best to the top. You'll always find something on Imgur that brightens your day. 😀

Yes, Imgur uses the Web Monetization API as well. So, Coil will distribute the micropayments to the creators according to the amount of time Coil subscribers spend looking at content on Imgur.

Subscribers also get access to unlimited uploads, community features, and, most importantly, an ad-free browsing experience.

Permanent

Have you ever thought about your digital legacy? By digital legacy, I mean an accumulation of the different text, pictures, and videos you've posted online over the years.

The truth is our digital legacy is disappearing because we've not had a central place to store it. And each time it disappears, a glimpse of who we were vanishes as well.

To solve this, Permanent enables you to create, curate, and collaborate on living archives for yourself, your family, and your community.

Thanks to the power of the Web Monetization API, the owners of Permanent.org are prototyping and building an Open Source API that allows users to easily store data with a storage provider using a one-time micropayment, with no need for storage provider or frontend service accounts and financial commitments.

She Code Africa

She Code Africa is a non-profit organization focused on celebrating and empowering young girls and women in tech across Africa.

They champion exceptional programs and initiatives to improve the tech skills of their members and keep the community engaged, amongst other things.

She Code Africa recently integrated Web Monetization into their website as a means to earn revenue. This revenue is used to continue the fantastic work they are doing in the developer community. You should support them!

CSS-Tricks

CSS-Tricks is one of the best websites to find insightful articles about frontend development.

Keeping in mind that it is one of the best websites for frontend content, many devs worldwide have benefitted from it tremendously. Meaning that some of them may have wanted to tip the writers or tell them "thanks" financially.

With Coil as CSS-Tricks web monetization provider, the website now receives micropayments from readers who have an active Coil subscription and the browser extension.

Ushahidi

Ushahidi is a crowdsource-driven data platform that enables people to raise their voices, inform their decisions, and influence change in their communities.

Being a non-profit, integrating web monetization on Ushahidi was an excellent way to gain revenue without running ads, especially during the pandemic. So, if any Coil user visits Ushahidi, Coil will calculate the amount of time you've spent on the website and credit the non-profit team. And most importantly, your data is safe!

Akita

Akita is a free and Open Source project that displays your top-visited monetized sites, how much time you're spending on them, and how much you're contributing (or could contribute) to them.

They also create diverse resources that will help you understand Web Monetization through storytelling, easy-to-use tools, and community outreach.

Puma Browser

Puma is a new way to pay for content through a privacy-focused web browser!

It provides a fast and private mobile Web3 browser that makes it easy to support creators, game & app developers, and charities of your choice.

The platform uses Coil and the Web Monetization API to create an ad-free user experience and send payment(s) for the content directly from the browser.

Flood Escape

Flood Escape is an action-packed rush to get out of danger!

You have to build your way up to escape the flood and be rescued in time in the game. You can also customize your experience with flames, get rewarded, and have a good time. 😀

Flood Escape uses web monetization to generate revenue from its game without the need for bugging users with unnecessary advertisements. They also give web monetization subscribers a bonus of 100 plus coins and a faster cooldown time.

Dev

Dev is an Open Source software that powers a community of software developers who write articles and build relationships with other developers.

The platform allows individual authors to add their Coil Payment pointer to their blogs right through their settings. So, every time a Coil subscriber reads your article, micropayments will be sent to your payment wallet by Coil.

Ballet Rising

Ballet Rising is a non-profit organization focused on the stories of people worldwide whose passion for classical ballet is redefining its culture and elevating ballet as a truly global art form.

It highlights communities where there is an interest in ballet to drive and build positive relationships with local arts organizations so that the global ballet community grows in harmony with local customs.

Their website is monetized using Coil. So, you can support them by signing up for a coil membership.

Tech with Catalin

Tech with Catalin is a blog owned by Catalin Pit, a Software Engineer specializing in JavaScript technologies and AWS.

The blog covers content about NodeJS, backend development, Open Source contributions, and growing as a developer.

Thanks to web monetization, Tech with Catalin generates revenue without displaying ads to its readers or adding a paywall.

Techdirt

Techdirt is an American Internet blog that reports on technology's legal challenges and related business & economic policy issues in the context of the digital revolution. It focuses on intellectual property, patents, information privacy, and copyright reform in particular.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, Techdirt has made their site open and available to anyone, thanks to Web Monetization.

As a Coil subscriber, you'll get to support Techdirt anytime you read content on their website.

On The Chain

OnTheChain promotes everything cryptocurrency-related. It has many podcasts, Youtube videos, newsletters, and a channel where they share tips and encourage people to join the cryptocurrency community.

OnTheChain uses the XRP TipBots wallet to receive bits of streaming payments from subscribers via Coil's Web Monetization API.

This allows them to give their users an incredible ad-free experience and not invade their privacy to make money.

SHORT FILM WEB

ShortFilmWeb is a directory of some of the best short films freely available online carefully handpicked by the team.

ShortFilmWeb uses Coil to monetize its content, giving them an edge to continue posting quality films and reviews.

Hackernoon

Hackernoon is a community of over 12,000+ contributing writers publishing free high-quality tech stories. The platform supports writers by proofreading their articles before it is published on the platform.

Hackernoon believes that advertising is not the best way to generate revenue, so they use Web Monetization instead.

Because of this, writers on the platform can accept a stream of micro-tips from their readers.

JS Bin

JS Bin is a free and Open Source code-sharing website for web developers. It enables developers to create and share code snippets or web pages with their colleagues or anyone in the developer community.

Being a free platform, JS Bin uses Coil and the Web Monetization API to generate revenue to keep the website running without ads.

Summary

Web monetization paves the way for a more open, fair, and inclusive web to better support users and creators.

Creators make money, and users finally experience their favorite websites without annoying advertisements or the invasion of their privacy.

Now that you've seen a couple of projects and people using the Web Monetization API by Coil go ahead and become a Coil Subscriber or integrate the Web Monetization API into your projects, blog, or website. You will find everything you need to get started here.

I hope you enjoyed reading this article. If you have any questions, share them in the comment section below, and I'll reply to every comment. 💛

Announcing the Web Monetization Workshop

Uchi Uchibeke — Tue, 22 Jun 2021 14:14:54 +0000

Web Monetization is being proposed as a W3C standard at the Web Platform Incubator Community Group. Since August 2019, Web Monetization has enabled content creators and developers to earn from their web content like articles, videos, tutorials, and more. Content creators have been able to earn from the content on their website on plain HTML+CSS, on WordPress, and even on blogging platforms like dev.to, Hashnode and others.

As the proposed standard gains more support and popularity, the Maintainers, working in the Web Incubator Community group, have gotten many feedback from the community and want to improve the specification to address the feedback, support more users and use cases, and align it with W3C's core standardization work. So, Coil is partnering with the Maintainers to host the Web Monetization Workshop in support of the community.

Why Web Monetization Workshop

The workshop aims to accomplish the following:

Get and discuss community feedback
Come away from the workshop with changes to the Web Monetization specification

What to expect at the Web Monetization Workshop

The two-day event will include a Web Monetization project Showcase, Q and A sessions, and two breakout sessions.

July 28 Day 1: Community Showcase

Opening
Web Monetization project Showcase
Closing

Sessions

Session 1 starts at 8am PST
Session 2 starts at 3pm PST (repeat)

July 29 Day 2: Technical and Architectural discussion

Opening
Breakout session - Community feedback, discussions, and recommendations, and summary of the update
- Declarative API session led by Marcos Caceres, Co-chair of Web Applications WG at W3C
- Imperative API session led by Ben Sharafian, CTO of Coil
Closing

Sessions

Session 1 starts at 8am PST
Session 2 starts at 3pm PST (repeat)

What to expect after Web Monetization Workshop

Post-event, all the feedback and discussions from the Showcase, Q and A, and architectural discussion sessions will be used to update the the Web Monetization Specification.

How to participate

There are many opportunities to be part of the Web Monetization workshop. You can:

Present at Showcase: If you have a project that uses Web Monetization and would like to share it with community members or want to share your story and experience working with web Monetization, this session is for you. Contact Uchi or email devs@coil.com to get more information about joining the Showcase.
Attend as a Participant: The Showcase is open to everyone to attend. Follow Coil on dev.to/coil or @coil to learn when you can RSVP.
Contribute to the Architectural Discussion: If you're a developer or interested in Web Standard, join one of the Architectural discussion sessions led by Marcos Caceres, Co-chair of Web Applications WG at W3C, and Ben Sharafian, CTO of Coil. Contact Uchi or email devs@coil.com to get more information about joining the Showcase.
Promote and Amplify: Want to help spread the word in your community? Please, share this post and talk to friends and colleagues to attend.

See you on July 28!

Updated July 2, 2021

DEV Community: Coil

Building Payment systems for the World at Hackathons

What to expect

Thank you!

Interledger 2022 - The Year of Rafiki

Why are we ready to fly now?

What is Rafiki, my friend?

Where is development at?

What is the timeline for 2022?

What else do we have in store for 2022?

WMS changes part 2: Background information

New events

Errors

Monetization as a state machine

pointers

Multiple pointers

media queries

WMS changes part 1: Breaking changes

<meta> to <link>

The old situation

Why <link>?

Changes to your pages

Setting the payment pointer

document to navigator

From document to navigator

Changes to your pages

How Coil supports the open-source projects we use

Supporting open-source projects and maintainers

Equitably support all projects

Promote transparency for all maintainers

Fund projects that drive impact for the community and Coil

Drive sustainability

Coil supports open-source Projects with Flossbank

Donation impact

Total top-level packages supported

Total packages supported

Conclusion

An Update from the Web Monetization Workshop

Project Showcase

Technical Architecture session

Branding

Meta vs Link tag

Web Monetization Events

Document.monetization vs Navigator.Monetization

Future of the Web Monetization Specification

Spec update

Implement Web Monetization in Browser

Rafiki open source project

The future of web monetization

Standard

New features

The future of web monetization

How to participate in the Web Monetization Workshop

1. Attend to watch the project Showcase

2. Submit topics for discussion

3. Join the technical discussion session

4. Showcase your project

The Web Monetization meta tag and API

The meta tag

Future: link

JavaScript API

document.monetization

state

Events

monetizationprogress

Event properties

How Coil works

Step 1: Register with Coil

Step 2: Add meta tag

Step 3: Install extension

Step 4: Restrict content

Privacy

The payment stream

20 Web Monetized Projects to Inspire You

Summary

Announcing the Web Monetization Workshop

Why Web Monetization Workshop

What to expect at the Web Monetization Workshop

July 28 Day 1: Community Showcase

Sessions

`<meta>` to `<link>`

Why `<link>`?