I know @bumi and @Alby have done a lot of work with it. @cascdr uses it.
Today at least, it seems most useful if you expect 3rd parties want programmatic access to a paywalled http resource or anticipate consumers will access the resource in a context that's L402-aware. While it still makes sense, it makes a little less sense where the application has accounts and other forms of authentication afaict.
For our paid stuff when it's paid non-custodially, we have a bespoke flow through graphql. We could use L402 for these but I prefer to build initial things to meet UX requirements rather than interoperability ones, and good UX demands a large degree of awareness/statefulness. I can imagine us moving to using L402 when we understand everything we'll accomplish with payments and want a more generic abstraction.
241 sats \ 0 replies \ @cascdr 11 Aug
Technically we do not use L402 but we use something very akin to it in terms of spirit. Our issue has been that it can be a bit bloated for our requirements. Like @k00b we are focused on the UX first and most likely will cut over once adoption/interoperability/maturity considerations are there.
reply
Interesting - would be really curious about the architecture of Stacker News non-custodial payment flow. Is it documented anywhere?
reply
361 sats \ 0 replies \ @k00b 11 Aug
The graphql mutations return these types which contain invoices, payment state, and the results of the paywalled mutations.
reply