SatPoll is an experiment around bitcoin micropayments, part of gathering best practices for a "Sign in with bitcoin" reference design for the Bitcoin Design Guide. What better way to figure this out than by practical experimentation.

Alby is likely the best way to use SatPoll. If you set an allowance, payments can be pretty much handled automatically in the background.

There's also an option to deposit sats. Consecutive payments will be frictionless as no invoices need to be handled anymore. But is that really what we want? Reason it's there is to experiment with this low-friction model as a comparison point. Also, it might be convenient for users who use LNURL-auth in the future, so they don't have to pull out their external wallet for every payment and scan QR code. Withdrawing deposits is not possible. I decided against this to discourage big deposits and to avoid holding funds for users.

Some questions I am looking into:

  • How to present and explain the "Sign in with bitcoin" interaction model?
  • Do micropayments work for frequent interactions where users expect an almost instant response time?
  • What's the best way to manage invoices? As they are needed? In anticipation of payments?
  • Is payment batching needed to make fees economically viable?
  • What do users prefer? Full control and transparency? Or is low friction with some "magic" better?
  • How to manage multiple wallets linked to one account?
  • And whatever comes up along the way...

As mentioned above, LNURL-Auth would be a cool feature. But haven't quite figured out how to implement that. It would allow for both authentication and payments without the wallet having to interact with the browser. A nice separation.

Would be cool if SatPoll could become an oracle (via DLCs) in the future, as an experiment with that tech. I have no idea how to do that. If you do, reach out.