search

kendraio / kendraio-app

Kendraio App
https://app.kendra.io
MIT License
22 stars 6 forks source link

Proposal for session pinging to verify Web Monetization works to DSPs #178

Open lukestanley opened 3 years ago

lukestanley commented 3 years ago

I propose we add a "sessionPing" config option to the Web Money block. The config option could be a payment pointer URL that will recieve the first 'monetization event' to verify receipt of the payment. A block with this new config option could be loaded at the start of the flow, before music plays, or potentially on demand. After the first Web Monetization event fires, it could stop the payment stream right away (to conserve the end users credit). After stopping the payment stream, the main payment pointer. would be switched to. Interestingly, with this approach, for Kendraio Player we could have multiple DSP's that need a "session ping". For unauthenticated users, we could still use the Coil login button as needed. For playing music with the audio player block, rather than preforming the session ping on load, we could perform it after a 429 error, rather than on demand. @drsm79 @darrenmothersele @dahacouk

drsm79 commented 3 years ago

https://webmonetization.org/docs/receipt-verifier May be of interest. I think if music is playing the payment should flow...

On 31 Mar 2021, at 17:04, lukestanley @.***> wrote:

 I propose we add a "sessionPing" config option to the Web Money block. The config option could be a payment pointer URL that will recieve the first 'monetization event' to verify receipt of the payment. A block with this new config option could be loaded at the start of the flow, before music plays, or potentially on demand. After the first Web Monetization event fires, it could stop the payment stream right away (to conserve the end users credit). Interestingly, with this approach, for Kendraio Player we could have multiple DSP's that need a "session ping". For unauthenticated users, we could still use the Coil login button as needed. For playing music with the audio player block, rather than preforming the session ping on load, we could perform it after a 429 error, rather than on demand. @drsm79 @darrenmothersele @dahacouk

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

lukestanley commented 3 years ago

@drsm79 Maybe it's not specified but I assumed your implementation needed a specific payment pointer to use purely for creating a verified session, is this not the case? I was thinking there would have to be multiple payment pointers, one for sessions then the pointer to pay the rights holder / artist?

drsm79 commented 3 years ago

Yeah that’s right. In theory the server could verify any payment pointer (I’ve a thing in the backlog for that) but at the moment it’s using the audiotarky one then swapping to the normal artists one. I possibly misread your thing; you mean you’d do one payment to create the session then swap to the artists one from then on? That works for me.

On 1 Apr 2021, at 09:56, lukestanley @.***> wrote:

 @drsm79 Maybe it's not specified but I assumed your implementation needed a specific payment pointer to use purely for creating a verified session, is this not the case? I was thinking there would have to be multiple payment pointers, one for sessions then the pointer to pay the rights holder / artist?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

lukestanley commented 3 years ago

If there was a trial / grace period of one track request (with no robotic audio watermark etc), where the user was assumed to be in good standing, it could be simplified to use one payment pointer and potentially work faster for the music listener, so I think working with multiple payment pointers would be quite nice. Would you be up for making that a priority on your end? @drsm79