Log in to customize your experience and get involved.
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:
I hope that answers your doubts, but feel absolutely free to ask more questions here 😁
Thanks for clarifying on the approach, I think your project is really important because the current model of Web Monetization has two risks:
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.
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)
We’d love for you to be a part of this community.