If you send someone to a Web Monetized website, it would be nice if you could include your payment pointer in the URL to get a small cut of the money they stream to that website. This would be like a standardized affiliate link. For example, you could rewrite links like this https://web-monetized-site.example?referrer_pointer=$evan.wallet.example.
As far as I understand, one of the big problems with these types of programs in the past has been that pay per click and pay per view models incentivize scammers to spam people and get them to click on those links. It seems like this would be slightly less of a problem if the referrer only got a cut of money streamed by the user. That said, depending on how fast money is streamed and how much of a cut the referrer got, it could still incentivize annoying or spammy behavior.
the referrer only got a cut of money streamed by the user
i think the spammy nature of affiliate links/programs as they currently work is due to the fact that the reward comes from the content/product producer only.
if the consumer also needed to approve the fact that part of their payment goes to an affiliate, this could disincentivize spammers. as a consumer, i would like the ability to block referrers i find spammy and whitelist ones i find high quality. on the other hand, this process potentially adds a lot of friction to payment from the consumer.
This could be something that user (and their browsers) control entirely.
Example: If your browser detects that you go from one monetized site to another it could automatically send a small monetization stream to the referrer based on user settings.
Do we need anything extra for this to “just work”?
I like putting it on the site instead of building it into the browser. It would be easier if we supported multiple payment pointers at once with WM so that you don’t need to do a server side revshare but I’ve still not thought of a reasonably simple way to support multiple payment pointers in the WM API
I hope the discussion can still continue. I do think a simple way to implement this is through probability revenue sharing + IndexedDB combo (requiring no sign up for stream payment just like WM API does). The only problem is that I’m not sure how reliable it’s storage persistent option is for long term affiliate ids storage (which in some cases expected to retain for 1+ year).
This is how I’m planning it on my small JS library https://github.com/ProgNovel/fundme
(NOTE: revenue sharing with hashing after payment adress already shipped in v0.1.1, but the affiliate part is not and only a concept for now)
import { fund } from 'fundme'
// the number following hash after the payment pointers below
// are weights for probability revenue sharing
const paymentPointers = [
'$wallet.example.com/website-owner#10',
'$wallet.example.com/article-author#10',
'$wallet.example.com/article-editor#5'
]
fund(paymentPointers, {
affiliateId: 'my-product-id',
affiliateRate: 0.15
})
What I’m planning to do with it is looking through key ‘my-product-id’ in IDB, which will store payment pointer for referrer and other details. If exists, it will get appended alongside other payment pointers before the revenue sharing calculation happens.