DEV Community

Carl Barrdahl
Carl Barrdahl

Posted on

Journey into Web Monetization - mixtapes

I decided to explore the idea about monetizing mixtapes I mentioned in the first post.

To make the proof of concept as simple as possible I use SoundCloud to stream the audio. It has a nice embeddable widget as well as an API with events to detect pause and play progress.

It works like this:

  • A SoundCloud widget is embedded
  • A tracklist is defined to keep track of which payment pointer should be used at what time
  • Get track playing and update payment pointer whenever the event PLAY_PROGRESS is triggered.
  • Coil is used to monetize the payment pointer in the meta tag
// Initialize SoundCloud widget
const audio = SC.Widget(embedSoundCloud(trackId))

// Fetch tracklist
const tracklist = await fetch("tracklist.json").then(r => r.json())

// Update payment pointer in meta tag as audio is playing
audio.bind(SC.Widget.Events.PLAY_PROGRESS, ({ currentPosition }) => {
  const track = getTrack(currentPosition, tracklist);      
  setMetaTag(track.paymentPointer);
})

// Pause monetization
audio.bind(SC.Widget.Events.PAUSE, (args) => setMetaTag(""));


function setMetaTag(pointer) {
  const monetizationTag = document.querySelector('meta[name="monetization"]');
  if (monetizationTag.content === pointer) {
      return;
  }
  monetizationTag.content = pointer;
}

function getTrack(timestamp, tracklist) {
  const tracks = [...tracklist].reverse() // find last index
  const trackIndex = tracks.findIndex((t) => timestamp / 1000 > t.time)

  return tracks[trackIndex]
}

Some issues that would need to be managed:

  • Each artist would need to set up a wallet and a payment pointer
  • Tracklists need to be defined (I crawled from 1001tracklists.com)
  • Each artist in tracklist need to point to a registered payment pointer
  • Metatag only supports 1 (artist) payment pointer
  • Nothing prevents a user to listen if they don't monetize
  • Monetization stops when browser tab is in background

Future improvements could be:

  • Move payments to a backend service and stream song position using WebSockets. This could enable payouts to multiple artists (collaborations) and songs playing at the same time (during crossfades and mashups).
  • Let artists sign up for a wallet and payment pointer
  • Periodically check if payments are sent to let the user keep listening

You can check it out here:
https://traveling-island-marscapone.glitch.me

And the code:
https://glitch.com/edit/#!/traveling-island-marscapone

Some thoughts on WebMonetization and ILP in general:

  • Is a browser extension really needed? Why can't the user authorize a backend to send payments to a pointer?
  • Could we have something like an OAuth2 flow where we allow a site to spend x amount from our wallet?

Discussion (5)

Collapse
wobsoriano profile image
Robert

RE: "Could we have something like an OAuth2 flow where we allow a site to spend x amount from our wallet?"

I've published a browser extension to check how much went to each site in total, it doesn't answer your question but I guess for now this is the closest thing that we can do to track micropayments.

Collapse
carlbarrdahl profile image
Carl Barrdahl Author

Thanks for your comment Robert.

I saw your contribution and it's pretty cool! Well done!

What I had in mind would be something like:

  1. User visits monetized site
  2. Monetized site has registered its site in a OAuth2Wallet provider
  3. User is asked to sign in (much like Github, Google, FB etc...)
  4. Code is receiver to exchange for access token
  5. Access token contains payment pointer
  6. Monetized site requests content using access token
  7. Monetized backend sets up stream using payment pointer
  8. Monetized backend calls stream.receiveTotal(amount) every x seconds
Collapse
dfoderick profile image
Dave Foderick

RE: "Is a browser extension really needed? Why can't the user authorize a backend to send payments to a pointer?"

Web monetization is "pay as you go" meaning the back end needs to know if you are engaged with the content in order to keep the payment stream going to the content site. i.e. it is session based.
Without that session/connect mechanism then we are back to the subscription model.

Although, I agree with the spirit of your comment. I think there needs to be other (better?) ways for users to control the payment stream.

Collapse
carlbarrdahl profile image
Carl Barrdahl Author

Thanks for your comment Dave.

Would it be possible to use WebSockets or polling an HTTP endpoint depending on what kind of frequency of payments you're looking for?

Collapse
dfoderick profile image
Dave Foderick

Not sure if you are talking about sending or receiving payments.
I haven't parsed all the architecture yet, but I think for sending payments yourself would be something like this
github.com/interledgerjs/ilp-wm-pr...
You would have to run moneyd for your own wallet and a bunch of infrastructure yourself