The Interledger Community 🌱

Discussion on: How Does It Work?

abhinavchawla13 profile image
Abhinav Chawla

Insulate does not maintain any user session between the user and the provider; it only maintains a user session between the insulation infrastructure i.e. Chrome extension and Insulate backend. The provider backend can verify by connecting with Insulate backend via the clientId/clientSecret pair.

The aim is to not let the provider have any access to the user information, so there is no chance of PII leakage of any form.

Answering the questions:

  1. Yes, for now. My whole aim with the project was to come up with an architecture that can be proven, so more of an MVP solution that can eventually be integrated within the Coil's main extension, hopefully 🤞
  2. Insulate does not stream payments, again my focus was to just find a way to protect open API calls for now. But it has the capability to do so since Insulate holds the Coil credentials to initiate BTP transaction.
  3. Currently, the provider does. But yes, both models are totally possible.
  4. Yes, I suppose so. transactionId is generated uniquely once the extension registers a block (which is an authenticated process), and this same transactionId is used to create a hash when the provider's backend passes it for verification. So in any instance, if a fake transactionId is being tried to pass (or even a repeated id), Insulate backend would not verify it, to keep the process secure.

I hope that answers your doubts, but feel absolutely free to ask more questions here 😁

benhylau profile image
Benedict Lau

Thanks for clarifying on the approach, I think your project is really important because the current model of Web Monetization has two risks:

  1. Coil knowing the browsing history of every user by their email address putting them in a position of mass data collection
  2. Service provider being able to de-anonymize via some Coil-level SSO (I don't think this exists yet but may evolve out of necessity)

I don't actually think the intention of Coil is to track users, and there is no real reason that payments need to be coupled to this orthogonal problem of identity. I think an architecture that differentiates the two, and still prioritizes end-user and provider UX, will be key to ecosystem growth.

Thread Thread
abhinavchawla13 profile image
Abhinav Chawla

Agreed. That's a great way to put it!

Same, I don't think it's Coil's intention to do so, but since they hold the data, they do have the capability to do so. For me, it's more about providers not being able to track users, even if Coil can. Personally, keep anonymity between the content-viewing user and content-providing provider while still smoothly processing payments is really exciting!

Having Insulate extension definitely aids the cause, but at the end of the day, you do not want people to install two extensions. So somehow, if similar concept could be inherited within Coil, it would be nice (I'll say an easier and probably more efficient method over the receipt verifier for most providers)