NIP-AD: decentralized advertising protocol #2073
Conversation
There was a problem hiding this comment.
The basic idea is quite simple, I think the length of the text obscures more than it clarifies, the NIP could be probably 20% as long. I do think this is easily gamed, and the punishments for falsifying actions will be more expensive to implement than to circumvent unless the user action can be independently verified (e.g. by having the user visit the site). "Impressions" are a big part of digital advertising, and are mostly enforced by contract, which doesn't really work here. Even then, fraud is rampant. Anyhow, I personally don't have much interest in adverting, but it could be an interesting way to build some kind of shopping app.
| "hold_time": <time in seconds>, | ||
| "max_payouts": <maximum number of paid actions>, | ||
| "payout_reset_interval": <interval in seconds to reset the max_payouts count>, | ||
| }), |
There was a problem hiding this comment.
It's generally better to put structured data into tags, content should be human readable if possible.
2 participants
This is inspired by #956 .
While exploring the implementation of the nostr-dan protocol, I realized it wasn’t privacy-friendly, as it would expose users’ metadata publicly on the network. So, I developed my own protocol that flips the script, putting users in control instead of advertisers.
The protocol distinguishes four roles:
By separating these roles, the protocol becomes more flexible. Advertisers don’t need to be online constantly if they trust a third-party delegate service, but they can also choose to self-host.
The protocol is focused on standardizing how interested parties communicate in an interoperable way. It can accommodate various implementation-specific logic, such as who receives payments (e.g., app developer or user), how actions are tracked, and how ad spaces are selected and validated.
I have a proof of concept implementation here: https://nostr-ads.ngengine.org/ , source: https://github.com/NostrGameEngine/nostrads .
The rationale behind this is not to propose an alternative to high-volume targeted networks like Google Ads, which rely heavily on collecting users’ personal information and require very high throughput and centralization, but to create something similar to satogram, embeddable directly into Nostr app UIs, with a mechanism to filter ads and enable private client-side targeting.
I hope this proposal is well-received. I put a lot of effort into making the specification clear, but I’m just not very good at writing docs, so any feedback is very welcome.
Also, this PR includes a CSV file for the standard ads categories. I’m not sure where it should go, I’ve pushed it to the repo, but it doesn’t seem like the right place.