A simple way would be Gordian Envelopes with an elided encrypted field for the content, and upon payment you receive the encryption key, and the non-elided field. That way it would all be over nostr and you would be able to know that what you're receiving is actually the content you paid for and it wasn't tampered with, without having access to the content in advance. In fact you could even publish that on nostr, have it attached to your pubkey like all other event types, it just won't be readable without 1 revealing the encrypted content and 2 decrypting that content.

GM verbiricha! We have a server with a secret key. When you want to publish, you send a UUID to request an encryption key. The UUID, your pubkey, and the secret key are combined with a salt via PBKDF to create an encryption key for that UUID. Your nostr event has a "d" tag of that UUID, and the secret data is encrypted with AES-CGM (text or binary). If it's just text, the cyphertext is included in the "encrypted" tag and the content serves as the preview. If it's binary, we upload the file to our CDN (blossom coming soon) and store the link in the event in an "imeta" tag. When you are using Fanfares, you can request the decryption key for an event via NIP-98. Our server will take your pubkey and the event you are seeking, parse the zaps for that event, and determine if you have paid for the event. If you have, it will re-derive the decryption key and send it to you. The decryption key is stored locally so the client always checks there first before requesting it from the server. If you want to grab all Fanfares events, you could REQ for the "a" tag that is included on all Fanfares events in this form: [ "a", "31990:d7d8109ee43657ce6056ada4653006bbb641f31e50e85243681c2724507811ec:Fanfares", "wss://fanfares.nostr1.com" ] We don't use any unique event kinds for encrypted content; we just use the standard kinds and include the following tags to make it purchasable. This way, any nostr event can be sold as long as we provide a UI for it: - "d" tag with the UUID used to generate the decryption key, - ["encrypted", "aes-256-cgm", "<cyphertext if present>"], - ["price", "2", "SATS"], "zap" tag(s), - ["referral","1"] tag for the amount of sats referrers get, - "a" tag for the client as shown above. Yes, we use "d" tags for all event kinds. This may seem weird but it isn't actually against the protocol. And it provides a uniform surface for identifying all events with a naddr which reduces a lot of complexity when passing events around between APIs and functions. Our goal at Fanfares is to integrate content unlocks in every client that is willing to integrate it. We see it as an open protocol on top of nostr, not a proprietary client function. We're really early yet, but I'm happy to work with you on integrating unlocks into your cilents. I honestly don't know what the best way would be to enable this, but we can sure talk about it and figure out what that might be! Thanks for the question!

That's interesting, but you don't actually need a Gordian Envelope for that assurance. The nostr event is signed, so if the event is changed the signature check will fail. The nostr event either contains the ciphertext or a reference to the file; the file is named by its sha256, so if the file was changed the sha256 wouldn't match, which would also invalidate the nostr event's signature.

The tricky part is the "pay for it and receive the decryption key". We architected Fanfares to remove as much friction as possible for creators to start (no running your own L402, etc) and with as much sovereignty as possible (all events signed by creator) and as interoperable as possible (no unique event kinds, just tags that facilitate payment).

awesome thanks for clarifying, can I read about the tags you use somewhere? looking forward to kind 30023 support!

oops just saw this, you can ignore my previous reply. this is awesome. i really like the way you've implemented this, very *nostry* and interop friendly. ping me when you add support for kind 30023 and I'll add support to Habla :vibePls:

that would be amazing! I thought you mentioned you couldn't work on habla anymore? It's an excellent client, I am happy this isn't the case

I have a full time job so time is limited but I'm revamping Habla and working on @npub1gm7g...0fte Weekend warrior hehe

not quite. the event is public as usual. it either contains a tag with the encrypted text content or it has a link to an encrypted file hosted on a CDN or blossom server. see? this is an encrypted note you can buy, but the unencrypted content is the preview content. this note also has an encrypted image in it. you can zap the note here, login to fanfares, and the note will unlock. you can view the json of the note in fanfares if you want