DEV is hosting a “Grant For The Web” Hackathon that I plan on joining.
My idea regarding Web Monetization for games, has to do with the <meta name="monetization"> tag.
In short, I want to have something that makes it as easy to add monetisation to games as it is for other content.
As you can read in my previous post, there are three use-cases that have a specific value to games on the web:
- Multi-player / Multi-user scenarios
- Turn-based (asynchronous) rather than time-based (synchronous) payments
- Sending micro-rewards (back) to other users
Currently, the monetization <meta> tag only has one function or purpose. I want to extend the tag (or add other tags) to support these cases.
So I started reading the W3c Web Monetization Specification.
Relevant information from the specs
The goals stated in the specifications that are relevant to my idea are:
- Simple for webmasters to use in their site.
- Interaction with the user should be optional.
- The user retains control over how much to spend
- Pay continuously as the user consumes content
On the face of it “Pay continuously as the user consumes content” conflicts with the desired turn-based use-case. However, as “the user retains control over how much to spend”, this isn’t really an issue.
So what else do the specs tell us?
There MUST be only one
<meta name="monetization">tag at any given time
Okay, no problem.
The [..] Monetization ID [..] MUST be regenerated upon dynamic changes to the meta tags
Hmmm… That could be useful.
Payment continues for the lifetime of a given meta tag (or semantically equivalent)
Right. Also good to know.
The provider MAY decide to stop/start payment at any time, e.g. if the user is idle, backgrounds the page, or instructs the browser to do so.
Ah! So The browser can start and stop payment when the user instructs the browser to do so!
It looks like we have everything we need to support the multi-player and turn-based scenarios. So what about winner awards or sending a kick-back to users?
(Ab)using Probabilistic Revenue Sharing
On the Web Monetization site, there is an example that explains “Probabilistic Revenue Sharing”. It explains how to share revenue amongst different people, despite the fact that only one payment pointer is supported in the monetization meta tag.
In short, it simply changes the value of the monetization meta tag based on a a piece of code that uses the laws of probability.
To my mind, a variation of this technique could be used for awarding winner(s) or sending a kick-back to users. Assuming we can figure out were to send the money. So how do we do that? I guess we’ll have to worry about that later…
Expanding the META tag
Before going more into the “how” of things, I want to focus a bit on the “what”.
Currently, the steps needed to use Web Monetization are:
- Set up a wallet to receive payments (this gives you a payment pointer).
- Add a monetization
<meta>tag to each page that you want to monetize.
Part of my goal is to make it easy for creators to use the defined game scenarios. This aligns with the goals stated in the specifications. So what would be most easy?
I’m thinking, either add a custom attribute to the existing meta tag, or adding another meta tag that adds more details about the desired scenario.
Looking at the specs again, we read:
The
nameof the<meta>tags all start withmonetization. [..] Currently there is only one tag, but this may be expanded in the future
Hijacking an existing tag for our purposes by adding another property feels a bit whack. So defining a new meta tag makes more sense.
Obviously, that isn’t part of the spec. Maybe some day it could be, I don’t know. What matters is that, for the user, it is very clear that these belong together.
So, we know that the name for the meta tag must begin with monetization. What shall we name it?
Micro-data to the rescue
There is a standard that concerns itself with how to define things: https://schema.org/
It defines a vocabulary that can be used in various formats. The one closes to HTML is microdata. Let’s say we have a game. (Yes, I know, just play along). Adding micro-data to the HTML to desribe such a game might look like this:
An added bonus is that this makes it easier to discover content. Spiders, crawlers and other bots can see what kind of content this is (i.e. “a game”).
What people often don’t realise is that this can also be expressed only using <meta> tags:
Not that I am saying you should. But if need be, you could.
Since we have all that information as meta tags anyway, schema+micro-data might be a good inspiration for monetization-... names.
The naming of a thing
Whatever name we choose, it should not be too specific. Any details can always be provided by other fields. As an example, for the sake of creating a common standard for Games, the numberOfPlayers and playMode could be of particular use. But using them directly doesn’t realy make sense:
monetization-numberOfPlayersmonetization-playMode
Looks weird, right?
But what about monetization-mode? That would make more sense. In fact, that would allow for other modes to be added later. (In case someone else comes up with another usage scenario that has not yet been thought of).
However, the content attribute also bears thinking about. Even with a good name, this is still too specific:
<meta name="monetization-mode" content="game">What would “game” even mean here? What kind of “mode” would it trigger?
So lets start out with defining which modes we are thinking of. Based on the three use-cases specified in the beginning of this article, they are: asynchronous, multi-player, and payback.
That would give us:
<meta name="monetization-mode" content="allow-payback"/>
<meta name="monetization-mode" content="asynchronous" />
<meta name="monetization-mode" content="multi-player" /><!-- Or a combination thereof: -->
<meta
name="monetization-mode"
content="allow-payback;asynchronous;multi-player"
/>
The first two look good, but multi-player might be a misnomer. Maybe we’ll get back to that later.
Payment events
The specifications also defines various events. We want things that the current implementation does not support. So we’ll need to translate between our game-specific events and existing, supported events.
At this point we’ll switch to the Web Monetization API as it is a better reference for current implementations than the specs.
The available events in the API are:
So there doesn’t seem to be any easy way to either set the height of a payment or get the wallet of a user.
This means a lower-level API will have to be used, these are Interledger protocol (ILP) and Simple Payment Setup protocol (SPSP)
There is an NPM package that offers functionaly (created by Interledger).
But it will take some hard thinking about how to implement this and at this point, I am not even sure this could be done without a server/backend. Sounds like a good part to research further after the hackathon.
Wrapping up
So, combining all of this, what do we get?
- By creating a custom
<meta>tag, we should be able to define configuration for monetization Javascript - Further details for such a script could use existing vocabulary provided by Schema.org
- Using ILP/SPSP it should be possible to create functionality beyond that already provided by the Web Monetization API
- This functionality would make it trivial for developers/publishers of Web Games to customize the way they monitize their games
So, after submitting this to the Hackathon, the next step is to prepare a submission for the June 12th deadline. There might be enough time to wrap up my research regarding ILP/SPSP and create a first rough proof-of-concept.
Either way, more to follow soon.👋
