pull down to refresh
0 sats \ 3 replies \ @nps OP 4h \ parent \ on: I'm Nick Slaney CEO and Co-Founder of moneydevkit, AMA AMA
Hm I get the feeling nothing will be completely satisfying here.
Your node creates the invoice, we do take a fee on the last hop, but we only get paid if you get paid.
We don't use a wrapped invoice, but even those are trustless as the provider is not able to collect any fees if the payment doesn't make it to you.
Hm I get the feeling nothing will be completely satisfying here.
It's a first-principles thing which is why I'm trying to clarify, false claims seem to be the norm these days in Lightning given all the fake L2 astroturf. Seems no one wants to solve actual problems and just adds obfuscated trust instead... trying to gauge if this "serverless" thing is adjacent.
This piqued my interest because a Lightning node cannot be serverless, it is by nature a server at it must serve responses in the forms of invoices and signatures, so the question becomes where is the demarcation of your server and the server the user is running.
a wrapped invoice, but even those are trustless
That's not true, if you're serving the invoice the payer and the payee have no means of verifying that the invoice you issue is actually wrapped. Wrapped invoices can provide atomicity, but not trustlessness.
They're also pretty fragile and create forced channel closures so it is good you're not using them, using the hop to collect is a better design.
So I guess the question becomes, what is the user key actually signing and who's service is delivering the invoice? If your service is doing the logic, that implies a blind signing which is of no benefit to the user holding the keys. If you're the one delivering the invoices, thats still every bit as trusted as a wrapped invoice.
reply
See here about serverless. It is a very common industry term that does not mean there is no server.
mdk wraps ldk to make it able to run on a serverless platform. Underneath, your node is spinning up and down as needed and expected by this model. When you create a checkout your node creates an invoice. The keys are to your node.
None of this is exposed to the user, as we're optimizing for people who could care less about the technical detail and want payments. But it is important to me that the bitcoin community understands there's no funny business under the hood. You can go look at the code for our libraries if you want.
reply
I'm well aware of the Lambda psyop, really its ephemeral servers with some form persistent storage/db and a reverse proxy to a container control plane. Fancy talk for docker on the fly basically.
When you create a checkout your node creates an invoice
How are customers getting the invoice from the users node? CLINK could disintermediate this, all it would add is a nostr secret to the users key ring.
people who could care less about the technical detail and want payments
Sure but those users would use a custodial processor and you wouldn't need to tout it as have it be this innovative thing to make it "self-custody".
If your users aren't supposed to care, then why the extra steps?
It's not unreasonable to ask if you call something self-custody how did you solve it? I can't lab every library that makes fantastic claims, so looking for some signal first. If I was convinced, mdk might be a useful bootstrapping back-end in my stuff... but you seem resistant to any level of scrutiny.
reply