Brilliant. While we don't care to verify payments to unlock content, we ran into a related problem because we want to know (real-time-ish) how much money we received via Web Monetization across all readers, and I didn't want to hard-code into Uphold private APIs to query this info. This is a viable path for us :)
I linked to our relevant issue here, but we have some decentralization requirement that this method may not work. My original thought was to query some publicly available information from the transaction, but it seems this is behind Uphold's API and I don't want to tightly couple. I emailed Uphold to see if they have a suggestion but haven't heard back.
What about doing this the other way round? You know in the front end code when a payment has been made, and what that was paid (e.g. webmonetization.org/docs/counter), why not send that on into a tidbit like Prometheus or similar to render?
Because the client is not trusted, anyone can report any number via an unprotected call. This is why we have to read off some verified place such as aggregating receipts.
Ah right. I think taking this into your own hands wouldn’t be horrendous (famous last words), if you can’t find a place that will give you the dashboard you need.
Got some answers from Uphold side about a verification path from the reserve chain endpoints. Our project won't pursue this path, but leaving response here in case anyone is wondering.
Q: Is there a way to read this information outside of the Uphold authentication? For example, directly on the Reserve Chain using some associated public key (without Uphold login)?
Q: If I need to use Uphold’s API, as I need to read account information on behalf of other Uphold account holders, do I need to register a Business Account and set up each account with the Client Credentials Flow? Under this auth flow, are we expected to read only the account that belongs to us, or can request for other account’s read-only tokens and read data on their behalf? uphold.com/en/developer/api/docume...
A: If you need to read account information on behalf of other uphold account holders you need to have a business account.
Great. If there is broader scope conversation over email with them that you feel helpful to pull me in, feel free to cc. me benedict [at] compost.digital.
For further actions, you may consider blocking this person and/or reporting abuse
Brilliant. While we don't care to verify payments to unlock content, we ran into a related problem because we want to know (real-time-ish) how much money we received via Web Monetization across all readers, and I didn't want to hard-code into Uphold private APIs to query this info. This is a viable path for us :)
I linked to our relevant issue here, but we have some decentralization requirement that this method may not work. My original thought was to query some publicly available information from the transaction, but it seems this is behind Uphold's API and I don't want to tightly couple. I emailed Uphold to see if they have a suggestion but haven't heard back.
What about doing this the other way round? You know in the front end code when a payment has been made, and what that was paid (e.g. webmonetization.org/docs/counter), why not send that on into a tidbit like Prometheus or similar to render?
Because the client is not trusted, anyone can report any number via an unprotected call. This is why we have to read off some verified place such as aggregating receipts.
Ah right. I think taking this into your own hands wouldn’t be horrendous (famous last words), if you can’t find a place that will give you the dashboard you need.
Or send something to an analytics tool. I’ve been using Fathom, and setting goals to record whether a visitor has coil enabled etc.
Got some answers from Uphold side about a verification path from the reserve chain endpoints. Our project won't pursue this path, but leaving response here in case anyone is wondering.
Great :) I think the vanilla folk have some plans for that sort of thing, and they’ve been very helpful when I’ve mailed them.
Great. If there is broader scope conversation over email with them that you feel helpful to pull me in, feel free to cc. me
benedict [at] compost.digital.