Web Monetization Community

loading...
Cover image for So, Why Project Insulate?
Project Insulate

So, Why Project Insulate?

Abhinav Chawla
・Updated on ・2 min read

To look into why I started building out Project Insulate, let's first quickly try to understand the current standing of the Web Monetization JS API. Let's take the official example:

<script>
    if (document.monetization) {
      document.monetization.addEventListener('monetizationstart', () => {
        // Remove/Hide DOM element using JS/CSS
      })
    }
</script>
Enter fullscreen mode Exit fullscreen mode

Imagine a photographer trying to provide exclusive photographs (provider) to the users paying through a Web Monetization based subscription (for us, Coil). With the current system, he fetches the data through an open API and then hides it on the frontend using JavaScript or CSS.

While this might seem fine to a few people, developers know how easily the open API call can be figured out (bless developer consoles 😇). To resolve this, we primarily see two options:

  1. Log-in to the website: Well, the whole point of web monetization is to stray away from individual logins, and hence subscriptions.
  2. SSO via Coil: This can technically resolve the problem of protecting the endpoint but poses two big challenges. Firstly, a user will still need to log in with Coil on every website he or she visits. Secondly, more importantly, the provider will have access to the user's Coil account and thus to the user's email address, if approved (but since email is trivial, most users can readily allow it). This defeats the purpose of restoring privacy when paying through Coil.

Current System
The above diagram explains the current workflow. The red arrow shows the unprotected open API call made to the backend which can be leveraged by anyone, with or without an active monetization subscription.

To resolve this issue, I decided to build a workflow that enables providers to secure their exclusive data without requesting users to sign into their websites. How? I'll explain that in the next blog.

Discussion (5)

Collapse
drsm79 profile image
Simon Metson

Hey, I just wrote a post that, I think, speaks to the same (or similar) issue - looking forward to comparing notes :)

Collapse
abhinavchawla13 profile image
Abhinav Chawla Author

Hey, Simon (and Benedict), yes indeed, I think we are thinking of a very similar problem, probably just from two opposite ends. What I can see, you're looking at it as a post-payment verification, whereas I'm looking at verifying before the content is delivered.

Considering the main issue of verification (be it payments flowing, or protecting digital content), it seems to be on the same lines. I'll share my more-so architectural post in a few hours, and I'll ping you two!

Collapse
abhinavchawla13 profile image
Abhinav Chawla Author

Here's the next post, I'll be happy to answer any doubts you guys might have, or even just discuss the solution further and maybe we can incorporate some more ideas into place.

Collapse
benhylau profile image
Benedict Lau

Hi fellow Torontonian, I am interested in this problem as well and just commented on Simon's post. Thanks for this post.

Collapse
abhinavchawla13 profile image
Abhinav Chawla Author • Edited

Hey Benedict, glad to meet a Torontonian on my post, haha! For some reason, the replies here don't allow me to tag a person. I tried to mention you in Simon's reply. Let me share the second post of the series in a few hours, it's a bit technical but I try to explain how the system would work.
Edit: New post!