lightlinks

Affiliate marketing has a problem - too much trust. The solution: LightLinks.io - a platform built on lightning and nostr that better aligns incentives between merchants and affiliates.

Comment

lightlinks

Our inspiration

The affiliate marketing experience is broken and we set out to fix it, once and for all.

The problem for affiliates:

  • delayed payments
  • high costs
  • lack of transparency

Management overhead is a huge pain for both merchants and affiliates.

What if we could use Nostr and Lightning to make everything easier? Nostr already has classified ads and zaps, and Lightning is cheap, fast, and private.

To solve this problem, we built (most of) this flow (things we haven't built yet are noted inline):

  • merchant publishes kind 30402 (classified ad nip99 https://github.com/nostr-protocol/nips/blob/master/99.md)
  • in this 30402 the merchant specifies the type of delivery: "no info", "email only", or "shipping info" (not yet implemented)
  • affiliate references the ad in kind 13166 (new nostr kind) (list of links)
  • also implemented new nostr kind 13167 (list of approved affiliates from a merchant)
  • the site stores a mapping of usernames to npubs and when a prospective buyer visits the site it shows the 13166 for that user, which is a list of classified ads (30402s)
  • buyer sees the ad on our site, and other sites that support this protocol
  • buyer clicks the ad and it expands to show more details including reviews
  • if user clicks buy, it gathers their shipping info (if required) (not yet implemented) then displays a Lightning QR using the merchant's zap info
  • in the zap request (nip57, kind 9734), the buyer places a reference to the affiliate link list event id and a relay ("["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb", relay", "relay-url"]") and also applies the discount (which is included in the original 30402 event from the merchant), and pays the resulting invoice.
  • The buyer directly pays out the merchant and the affiliate using a pre-existing nwc library for Lightning Prisms (a single invoice that splits into multiple recipients)
  • The merchant sends the goods.
  • From the paid zap request, the merchant's wallet generates a zap receipt and includes this zap request in the description field, which allows the merchant to look up the 13166 to find the affiliate's npub to see if the affiliate is a valid affiliate (not yet implemented)

To implement this, we implemented 4 pages:

  • A merchant/affiliate account page
    • links to the merchant and affiliate dashboards
    • saves a username which maps to a Nostr npub
  • The merchant dashboard
    • creates the kind 13167
  • The affiliate dashboard
    • creates the 13166
  • The affiliate's sales page
    • has a human-memorizable link like lightlinks.io/username, that is easily sharable and contains all the affiliate links, where the buyer will go to buy products and get discounts
    • we built three versions of this page and threw away the first two

Challenges we faced

  • slow/nonexistent internet
  • the merchant/affiliate login landing page was built by someone with no coding experience and no hackathon experience (and actually works pretty well!)
  • learning to use AI tools while learning how to compete in hackathons
  • AI tools not understanding how to connect to Nostr
  • having to throw away hours of hard work and start from scratch
  • our buyer landing page didn't work out and needing to rewrite it from scratch
  • having 4 things left to do and then suddenly having 7 things to do
  • having everything crumbling around us as the deadline approached, while being hungry and sleepy
  • staying up all night to get it all working

Built With

Share this project:

Updates