I'd love to know more about the server-side of things regarding Web Monetization, currently the site says "Examples on how to verify Web Monetization from the server side will come soon."
I have an idea for something though it requires effectively running a custom payment pointer - at a quick glance, I can't see much detail about that on the Web Monetization site. Also, does that (an idea built on a custom payment pointer) actually fit into the hackathon categories?
You're correct that server-side verification requires a custom payment pointer right now; it can be quite complex and requires peering into the Interledger network which can be hard for an individual. wouldn't recommend it as a hackathon project as peering into the Interledger network requires setting up business relationships with other Interledger network participants.
As a more developer-friendly alternative, we've been developing STREAM receipts.
STREAM receipts are signed messages that say how much a user has paid to your payment pointer. They can be verified server-side without requiring you to run your own payment pointer and without requiring you to peer your server to the Interledger network.
So far we've implemented STREAM receipts in the STREAM libraries, and the next step is for wallet providers to pull in that new version of the library and expose the receipts functionality.
I'd expect it should be available on at least one wallet provider within a couple of weeks to a month and available on all wallet providers within a month or two.
Thanks for replying! Basically I was thinking of some form of middle-man for the monetization system where a user (who makes the content) can manage it without knowledge of coding.
For example, if they wanted to do profit sharing off a particular page, just knowing the page URL and who they wanted to split it between would be enough. Similarly, if they wanted to donate a particular % to charity or something, they can automagically do that with some changes in an admin system.
While there are JS examples on the Web Monetization site that do a revenue sharing example, to me this is something that makes more sense as a server-side system and I figured "incepting" the actual money through its own custom payment pointer to do the processing on makes the most sense for a real implementation.
Gotcha, that's a cool idea! Implementing a revenue share like that is easier than writing a payment pointer which verifies payments, because it doesn't require you to hook into the Interledger network yourself.
If you want to do revenue sharing server-side you can run a server that redirects to different payment pointers, just like this example on webmonetization.org. The website that wants to use your revsharing service would embed a URL from the revshare service instead of their own payment pointer. Then the user can adjust the revenue sharing parameters on your service without having to update their page every time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd love to know more about the server-side of things regarding Web Monetization, currently the site says "Examples on how to verify Web Monetization from the server side will come soon."
I have an idea for something though it requires effectively running a custom payment pointer - at a quick glance, I can't see much detail about that on the Web Monetization site. Also, does that (an idea built on a custom payment pointer) actually fit into the hackathon categories?
You're correct that server-side verification requires a custom payment pointer right now; it can be quite complex and requires peering into the Interledger network which can be hard for an individual. wouldn't recommend it as a hackathon project as peering into the Interledger network requires setting up business relationships with other Interledger network participants.
As a more developer-friendly alternative, we've been developing STREAM receipts.
STREAM receipts are signed messages that say how much a user has paid to your payment pointer. They can be verified server-side without requiring you to run your own payment pointer and without requiring you to peer your server to the Interledger network.
So far we've implemented STREAM receipts in the STREAM libraries, and the next step is for wallet providers to pull in that new version of the library and expose the receipts functionality.
I'd expect it should be available on at least one wallet provider within a couple of weeks to a month and available on all wallet providers within a month or two.
Thanks for replying! Basically I was thinking of some form of middle-man for the monetization system where a user (who makes the content) can manage it without knowledge of coding.
For example, if they wanted to do profit sharing off a particular page, just knowing the page URL and who they wanted to split it between would be enough. Similarly, if they wanted to donate a particular % to charity or something, they can automagically do that with some changes in an admin system.
While there are JS examples on the Web Monetization site that do a revenue sharing example, to me this is something that makes more sense as a server-side system and I figured "incepting" the actual money through its own custom payment pointer to do the processing on makes the most sense for a real implementation.
Gotcha, that's a cool idea! Implementing a revenue share like that is easier than writing a payment pointer which verifies payments, because it doesn't require you to hook into the Interledger network yourself.
If you want to do revenue sharing server-side you can run a server that redirects to different payment pointers, just like this example on webmonetization.org. The website that wants to use your revsharing service would embed a URL from the revshare service instead of their own payment pointer. Then the user can adjust the revenue sharing parameters on your service without having to update their page every time.