Am I right in thinking that Insulate is a SSO service that masks user email address by mediating a session-based auth token between user agent and provider backend?
Couple questions:
Does this require everyone to have the Insulate extension along with the Coil?
Does Insulate stream micropayments on behalf of the user agent?
Who maintains provider inventory of exclusive content? It looks like both models are possible (i.e. managed by provider or on Insulate itself)?
How does provider trust transactionId generated by Insulate? This basically shifts the trust from user agent to Insulate right?
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:
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 🤞
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.
Currently, the provider does. But yes, both models are totally possible.
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 😁
Thanks for clarifying on the approach, I think your project is really important because the current model of Web Monetization has two risks:
Coil knowing the browsing history of every user by their email address putting them in a position of mass data collection
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.
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)
For further actions, you may consider blocking this person and/or reporting abuse
Am I right in thinking that Insulate is a SSO service that masks user email address by mediating a session-based auth token between user agent and provider backend?
Couple questions:
Does this require everyone to have the Insulate extension along with the Coil?
Does Insulate stream micropayments on behalf of the user agent?
Who maintains provider inventory of exclusive content? It looks like both models are possible (i.e. managed by provider or on Insulate itself)?
How does provider trust
transactionIdgenerated by Insulate? This basically shifts the trust from user agent to Insulate right?Thanks for digging into this problem!
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:
transactionIdis generated uniquely once the extension registers a block (which is an authenticated process), and this sametransactionIdis used to create a hash when the provider's backend passes it for verification. So in any instance, if a faketransactionIdis 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 😁
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)