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!
Login to reply
Replies (2)
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