Popup should show intermediate states of streaming?

[sublimator]

To give more indication of the reason for any delays in payment, and perhaps actionable information.

https://community.webmonetization.org/blackforestboi/slow-payment-process-with-coil-ux-improvement-possible-119p

• [ ] enumerate all states
  • Validate Payment Pointer
  • Query SPSP
  • Setup "Connection"
  • Setup "Stream"
  • ?
• [ ] add to popup in simple text form
• [ ] push to CoilDev for design to test
• [ ] get design input/mocks
• [ ] update popup as per design

[sublimator]

Related issue: https://github.com/coilhq/web-monetization-projects/issues/1250

[blackforestboi]

thanks @sublimator for putting the issue here.

I'd suggest to give an optimistic confirmation that the "payment action" was confirmed and will be processed, and that in an event of failure the user will be notified. This action of paying should be under 200ms to confirm.

It's already a pain to remember to pay.

[sublimator]

It's already a pain to remember to pay.

The extension should be paying (streaming multiple packets per second) automatically

I'm even more curious now as to what you are seeing. What action do you need to take when you are remembering to pay ?

Thanks again!

[sublimator]

@blackforestboi

Are you talking about tipping perhaps ?

[sublimator]

@blackforestboi

Hi, Happy New Year !

Could you elaborate on the pain in remembering to pay ?

[blackforestboi]

@sublimator sorry have been missing this message in the flood of notifications!

The Coil popup keeps loading and loading.

If I do these things manually by injecting the payment pointer via the console it throws hundreds of entries (about 5-10 per second) for monetizationprogress that have no receipt, only for it to end with monetizationstop after a few minutes. They are all the same. I have the Coil extension installed.

function startEventHandler (event) {
  console.log(event)
}
document.monetization.addEventListener('monetizationstart', startEventHandler)

function stopEventHandler (event) {
  console.log(event)
}
document.monetization.addEventListener('monetizationstop', stopEventHandler)

function progressEventHandler (event) {
  console.log(event)
}
document.monetization.addEventListener('monetizationprogress', progressEventHandler)

meta = document.createElement('meta'); meta.setAttribute('name', 'monetization'); meta.setAttribute('content', '$ilp.uphold.com/zHjHFKyUWbwB'); document.head.appendChild(meta);

Setup:

MacOSX 10.14 Brave 10.19.86

[blackforestboi]

Happy new year to you too. 😊

Just now coming back here as I left the last message on a busy day and just dropped off my observations. Thanks for helping me to fix this.

How can I help finding the root cause or assist in testing things?

[sublimator]

The Coil popup keeps loading and loading.

Can you show me a screen shot of the popup in the 'loading' state ?

Something doesn't sound right

[blackforestboi]

I made a screenrecording here: https://www.loom.com/share/cc75e410f1d34fd89c430fdaefa0fc61

[blackforestboi]

So we found that if you have the setting enabled for Coil to run on every page, the above sequence of progress events without a receipt will happen.

If you use the setting of "only on click" it will not move the state from "pending" to "started", but just does nothing. The coil popup is then in this state, without the progress bar:

We tried it on several computers and browsers.

Also another question: It seems as if coil is right now designed to auto-pay every page that is monetisation enabled or does it require the interaction of users to pay. We were initially under the impression that you have to click the coil extension icon to trigger a payment, even if it streams, but the continuous progress events as soon as the page loads indicate an auto payment. They just never complete by sending a receipt it seems.

Would there be an opportunity to jump on a 30min call and do some investigation together?

Thanks!

[sublimator]

@blackforestboi

Hi, sorry for the late reply! I had some health issues last week.

We were initially under the impression that you have to click the coil extension It was envisioned that WM agents ( such as the Coil extension) are intended to automatically pay any WM enabled sites.

Thanks for the "Site access" report. I have been meaning to investigate that for Safari (#1073)

They just never complete by sending a receipt it seems.

I'm not 100% sure what you mean regarding the receipts (or lack thereof) but they require the the SPSP server referenced by the payment pointer to support receipts.

[sublimator]

I made a screenrecording here: https://www.loom.com/share/cc75e410f1d34fd89c430fdaefa0fc61

Thanks for that. Yeah, WM will start "streaming" immediately (currently a few packets a second, but there is some work towards cutting down the amount of packets sent) In your video the streaming had already started, that's why you didn't see the start event.

[blackforestboi]

Thanks yeah. I think maybe more intuititive ux may be to have the Coil popup show the amount donated increase there or just say something like: “Site is being donated to” and a checkmark. Streaming money is a new mental model.

Other questions: Chris (from GftW) mentioned you guys plan tipping to release this year to Coil? Awesome. Is there a timeline for that? Also do you consider subscriptions too?

[sublimator]

Streaming money is a new mental model.

Good feedback, though I suspect your experience has been colored a bit by the "On click" setting for "Site Access"

@fruehle @manxz ? thoughts ?

Chris (from GftW) mentioned you guys plan tipping to release this year to Coil? Awesome. Is there a timeline for that?

@traviscrist is leading the tipping efforts and can speak to that

Also do you consider subscriptions too?

Subscription plans other than $5 ?

[sublimator]

re: tipping timeline

I queried this for you. It's still in the r&d phase, but it's a priority for the team so will be seen soon enough

[sublimator]

@blackforestboi

show the amount donated increase

The earlier versions actually did just that. I can't recall off the top of my head just now the reason for the changes

[sublimator]

@blackforestboi

We found that the counter was only really meaningful in showing movement. The amounts for each packet are so small that it's hard to do mental math with them and we are moving to paying on larger intervals (*) for perf reasons on mobile anyway.

* moves to minutes rather than seconds the longer you stay on a page

[blackforestboi]

Leaving another idea I just had. Will come back to the rest later.

Give users the ability to set a maximum donation per page or visit. Problem is that if you leave a tab open and active that is web monetized it will continue streaming there, even if you are not on the computer etc. In our test accounts we got like 1.5€ or so already back from the 5€ because of things like that. Can imagine many people stay for example on a page and walk away, giving those creators an uneven amount (especially since payout in the beginning of the month is higher, bc funds run low or out the later the month people are in.

[sublimator]

Thanks again, noted :)

[blackforestboi]

Subscription plans other than $5 ?

No I mean subscriptions to creators content. Like a substack or patreon. So the ideal workflow I imagine is: I use Coil to load e.g. 40€ per month. I go around and some of the creators I stream money to, some I want to pay a subscription and some I want to tip.

Coil would manage for me that I always have enough funds to pay those subscriptions and are able to tip, and reminds me if my funds run out.

re: tipping timeline

thanks, looking forward to this. Will open so many new use cases, like the ones above, or paying individual creators in a timeline, like Brave's BAT does it on Twitter.

• moves to minutes rather than seconds the longer you stay on a page

That's a great start to not overpay someone. Though I think it would be good to give the user a bit more control over who to pay - though I don't think its a higher priority than getting tipping done.

[blackforestboi]

I just had the thought that potentially "subscriptions" is more important to get right than "tipping", although the latter might be foundational to develop for subscriptions to work. Reason is that tipping is a manual act that is very laborious for the user - hard to adopt UX because it needs changing existing habits. Partially because of that it failed multiple times to gain expected traction with services like Flattr or Satoshipay.

On the other hand, subscriptions are widely used in existing business models, like newspapers, or services like Substack, Patreon, Blendl, Flipboard that can be more readily implemented there, and users are used to the UX - and its less work.

I do think that tipping and auto-tipping is going to be very important to scale WM further, though maybe as a next steps when a lot more people have already WM set up. This mass could be reached easier, I assume, if the user has the least amount of work to adopt the habit of using micropayments.

What was your thinking behind first doing the 'tipping' use case?

[sublimator]

I'm not entirely sure but I believe it's a sum of various considerations including exploring a more human engaged/controlled experience.

[blackforestboi]

Mhh interesting. Is there anyone from the Product team to speak to. I had now conversations with several GftW grantees and we are all struggling with the limitations by coil bc the streaming/tipping use case alone is just not cutting it for our use cases :(

[justmoon]

Hey @blackforestboi - thanks for the feedback! Coil CEO here. We're definitely aware of the current limitations and are working towards fully featured sending/receiving (including subscriptions) and raw Interledger access. There are a lot of tough challenges to solve: technical, regulatory, and fraud/risk. We believe they are all solvable, but it will definitely take some time. It's too soon to promise a specific timeline but I'm hoping we can have something launched by the end of the year. Could be sooner, could be later.

In the meantime: Our team in Cape Town built a proof-of-concept for recurring payments which could be revived and deployed on the Interledger testnet. See: https://github.com/interledgerjs/rafiki.shop/tree/master/sites/recurring

This is built using Open Payments Mandates, see: https://docs.openpayments.dev/mandates

Beware that this is the bleeding edge of ILP right now so YMMV - but I always prefer giving some answer rather than no answer. :)