pull down to refresh

I built a decentralized Advertising Network protocol on Nostr
2877 sats \ 7 comments \ @rblb 15h nostr
I’ve designed a decentralized advertising protocol on top of Nostr, Lightning and proof of work.
The full specs are drafted here.
Unlike current systems, which rely on tracking and profiling users against their own will, and even the proposed Nostr-DAN which merely makes user data public, so... arguably even worse, this approach flips the script entirely.
Advertisers broadcast signed bids with metadata to nostr; user apps then independently choose which ads to display, by filtering them relay-side and client-side.
When a user app selects an ad, the negotiation begins: either party may reject or bail out the negotiation at any time, incurring in a proof‑of‑work or rank penalty on the other side.
If the negotiation succeed, the payout is sent instantly via Lightning to the lud06 or lud16 address set in the kind 0 metadata event of the "app" pubkey, that could be a pubkey assigned to the app that the user is running or of the user itself.
The advertiser’s side of each negotiation is managed by a delegate service, that can be a trusted third‑party service, or self‑hosted if preferred. These delegate services can apply additional heuristics and checks to decide when to process a payout or impose a pow penalty if the counterparty attempts to cheat.
This integrates with the existing Nostr protocol and is flexible enough to support various advertising models, such as:
  • The classic ad model targeted to a specific, centralized app
  • A Brave-reward style reward model that compensates users directly
  • A Satogram-like, open broadcast model that any app can pick up and display
This is a crude, mostly complete, implementation of the protocol: NostrGameEngine/nostrads that is demoed on: https://nostr-ads.ngengine.org/
write
preview
related posts
21 sats \ 1 reply \ @BlokchainB 13h
Will this kill Google and meta? Ad businesses masquerading as tech companies?
reply
88 sats \ 0 replies \ @TheBTCManual 11h
Possible, the double-blind auction system both platforms use is set up to be abused they can pick the floor price even when there's no competition, it's not a true auction for attention, so there's plenty of margin to extract if an open protocol can gain enough inventory
Advertisers will apply move some of their budget to these networks if the CPM and CPC is lower, even if targeting isn't as good since display networks are about top of funnel, brand and reach
reply
21 sats \ 1 reply \ @lunin 12h
I think I understood everything, but no. Could you please tell me how the audience will be selected and what settings will be available to the advertiser? Will there be an auction system if two advertisers target the same viewer? What targeting options will be available in general? Thank you!
reply
0 sats \ 0 replies \ @rblb OP 11h
Could you please tell me how the audience will be selected and what settings will be available to the advertiser?
Bid events carry a set of metadata for the ads, that's how the advertiser can hint for an audience.
In addition to that every user is defined by an anonymous pubkey and every request carry an app pubkey, so the advertiser can target a specific app and a set of users without knowing exactly who they are.
Will there be an auction system if two advertisers target the same viewer?
This is client-side and is mostly implementation specific, in my implementation bids are ranked based on how many sats they pay, how well they fit the adspace, how many times they have been shown and by the honesty of the advertiser.
reply
21 sats \ 0 replies \ @grayruby 14h
Very nice.
reply
21 sats \ 0 replies \ @Scoresby 15h
Cool idea!
I do wonder, though, if there is any better mass advertising than just zapping your customers...
reply
0 sats \ 0 replies \ @NodeR1der 9h
Really interesting approach — you're essentially building an ad bidding layer on top of the Nostr relay protocol, using signed events, PoW-based deterrents, and programmatic Lightning payouts.
The fact that ad selection happens client-side, avoiding centralized profiling, is crucial for preserving user privacy. Also, leveraging the kind:0 metadata event to define the payout lud06/16 address is an elegant reuse of existing Nostr primitives without introducing new ones.
The negotiation mechanism with opt-out and PoW penalties introduces a lightweight but effective anti-spam / anti-sybil measure. The delegate service abstraction for payout logic and fraud heuristics adds flexibility, allowing things like whitelist enforcement or behavior-based scoring.
What stands out is the multi-model compatibility — supporting anything from classic app-specific ad delivery to Brave-style opt-in user rewards or even Satogram-style open broadcast.
reply