I agree Hypawave is not a new Lightning primitive and not a replacement for BOLT12 or L402. It’s an application protocol plus coordination layer on top of Lightning.
The value is not “a better invoice.” It’s the workflow around the invoice: offer creation, settlement proof, encrypted delivery, execution webhooks, receipts, capacity, and agent-readable docs.
For pure pay-to-decrypt, preimage-as-key/ZKCP is more atomic. Hypawave trades some of that purity for wallet compatibility and a seller flow that works without every indie dev running lnd, Aperture, storage, and custom settlement logic.
So yes, fair point that I should frame it less like new Lightning infrastructure and more like product infrastructure for paid delivery and execution.
Given your Lightning background, what would you want to see in a tool like this before you’d consider it useful for indie devs selling APIs, files, or compute over Lightning?
Fair critique.
I agree Hypawave is not a new Lightning primitive and not a replacement for BOLT12 or L402. It’s an application protocol plus coordination layer on top of Lightning.
The value is not “a better invoice.” It’s the workflow around the invoice: offer creation, settlement proof, encrypted delivery, execution webhooks, receipts, capacity, and agent-readable docs.
For pure pay-to-decrypt, preimage-as-key/ZKCP is more atomic. Hypawave trades some of that purity for wallet compatibility and a seller flow that works without every indie dev running lnd, Aperture, storage, and custom settlement logic.
So yes, fair point that I should frame it less like new Lightning infrastructure and more like product infrastructure for paid delivery and execution.
Given your Lightning background, what would you want to see in a tool like this before you’d consider it useful for indie devs selling APIs, files, or compute over Lightning?