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 e​asier 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 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 

 Unfortunately I don’t think the semi-trusted provider idea will work especially in a self custodial setup.

I don’t think this can be fixed for keysend, but with invoices you can use the preimage as proof of payment 

 Maybe we should just abandon keysend - I think Podcasting 2.0 is the only place it's used and it makes everything so much harder because many wallets don't support it. 

 Maybe there can be verified and unverified payments, and clients can choose to show both or only verified ones?

I think it will take time for podcasting 2.0 to transition and it’s great to support V4V however we can! 

 For self-custodial setups the recipient could also create one of these events - and as you say clients could choose whether to trust it based on their pubkey. 

 Can this maybe combined with an ecash zap spec? #cashu 

 Yes very curious how people working on ecash plan to represent payments on nostr - have you seen anything proposed? 

 +1.    Need to read up on this too.
eCash is perfect for the two use cases you mention. 
- You can start zapping podcasters that aren't on Nostr from the moment you have any contact info from them 😉. 
- eCash can be denominated in whatever currency. Where it's gets confusing is in the UI for those zaps though. You don't want volatile zaps on posts so it's best to keep denomination there in sats.  

  @calle 👁️⚡👁️ any thoughts on the above? 

 We can generalize zaps to anything by removing the bolt11 and just putting amount + denomination. 

 So I could just create a zap receipt for a keysend payment without the bolt11 tag? 

 We would have to update the spec but yeah. You could also create a fake bolt11 if you wanted to be backwards compatible