I've spoken to a few people about this idea and have had mixed feedback so I'm not sure it's the right approach - but I thought I'd share here anyway with the hope that it sparks conversation about the best way to represent payments for apps that want to integrate nostr for the social layer, but where the zap spec doesn't quite work for their use case.
The idea is a new parameterised replaceable event that can represent any payment in any currency signed by a semi-trusted provider which in most cases will be the app that the user is posting from.
I see two key benefits of this approach which currently are not supported by the zap spec:
- Payment Recipient Not on Nostr - if the user making the payment is on nostr but the recipient is not, it's still useful to both allow the payment, and be able to represent it as a nostr event. Especially for apps that already have a payments component it makes the adoption of nostr easier because they don't have to try and retroactively fit the zap spec into their use case.
- Multiple Currencies - it's also useful for apps that already have a payment component to be able to represent payments in any currency. This de-couples the onboarding to nostr from the onboarding to bitcoin + lightning - something that can still be encouraged but can happen gradually.
For Fountain / Podcasting 2.0 specifically all the payments use keysend so as far as I'm aware there's no way to create a zap receipt that conforms to the spec. Maybe we should just try and switch all the Podcasting 2.0 payments to BOLT-11 - but with BOLT-12 and potentially other payment mechanisms like ecash becoming more popular - is it useful to have a more generic representation of a payment?
Keen to hear people's feedback on this and whether there are any other ideas that might work?
jb55 (npub1xts…kk5s) would also be great to get your thoughts on whether there is a way to 'fit' keysend payments into the existing zap spec / general thoughts on extending it.
https://github.com/nostr-protocol/nips/pull/1339
merryoscar / Oscar Merry
npub1un…vd0j2
2024-07-01 08:45:43
Author Public Key
npub1unmftuzmkpdjxyj4en8r63cm34uuvjn9hnxqz3nz6fls7l5jzzfqtvd0j2Published at
2024-07-01 08:45:43Event JSON
{
"id": "76d95df7b16688dc2aaa152f7bba6c79776a609a0e66c722b95564841b24ae3f",
"pubkey": "e4f695f05bb05b231255ccce3d471b8d79c64a65bccc014662d27f0f7e921092",
"created_at": 1719816343,
"kind": 1,
"tags": [
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245",
"",
"mention"
]
],
"content": "I've spoken to a few people about this idea and have had mixed feedback so I'm not sure it's the right approach - but I thought I'd share here anyway with the hope that it sparks conversation about the best way to represent payments for apps that want to integrate nostr for the social layer, but where the zap spec doesn't quite work for their use case.\n\nThe idea is a new parameterised replaceable event that can represent any payment in any currency signed by a semi-trusted provider which in most cases will be the app that the user is posting from.\n\nI see two key benefits of this approach which currently are not supported by the zap spec:\n\n- Payment Recipient Not on Nostr - if the user making the payment is on nostr but the recipient is not, it's still useful to both allow the payment, and be able to represent it as a nostr event. Especially for apps that already have a payments component it makes the adoption of nostr easier because they don't have to try and retroactively fit the zap spec into their use case.\n\n- Multiple Currencies - it's also useful for apps that already have a payment component to be able to represent payments in any currency. This de-couples the onboarding to nostr from the onboarding to bitcoin + lightning - something that can still be encouraged but can happen gradually.\n\nFor Fountain / Podcasting 2.0 specifically all the payments use keysend so as far as I'm aware there's no way to create a zap receipt that conforms to the spec. Maybe we should just try and switch all the Podcasting 2.0 payments to BOLT-11 - but with BOLT-12 and potentially other payment mechanisms like ecash becoming more popular - is it useful to have a more generic representation of a payment?\n\nKeen to hear people's feedback on this and whether there are any other ideas that might work?\n\n nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s would also be great to get your thoughts on whether there is a way to 'fit' keysend payments into the existing zap spec / general thoughts on extending it.\n\nhttps://github.com/nostr-protocol/nips/pull/1339",
"sig": "fc7311824ef9323c16fdd64c181e58810dcbf676b18f201de7384e7c10cb672987a3403d840fb36044b3e0c6a58798c14c237c21d9fb93140be4b5b76b57acb8"
}