One challenge we'll need to explore is what we do with link relations in HTTP headers, have you given that any thought?
With independent non-HTML documents like PDF, images etc., I think it should be fairly straightforward - it's similar to web pages. If we were to use Link header along with <link> elements, it gets a bit more interesting as we need to use either of them. HTTP headers come before response body, so it might make sense to use Link even when a <link> is present.
When such content is embedded into a web page, we run into same problems as with iframes. From implementation perspective, it's easier to run as many payment streams as their are embedded content, but this can be very bad performance wise. If we were to monetize only "visible" or "active" content, it gets difficult to implement with all the edge cases (what if someone adds 100 1px images in a row etc.). Also, with the overhead of setting up payment, user might scroll away from the content before we even set up the payment.
[on payment pointers]
I mean we'll have to use WHATWG URLs, but I get your point. I'll update the report to make it clearer.
We're doing a lot of work in the Open Payments specification to expand on the use cases for Payment Pointers and Interledger beyond just Web Monetization (think of a Payment Pointer as a Web-native credit card number but with super-powers and better security).
This sounds exciting! I feel like we should again look into the pay:// URL scheme 😄
For further actions, you may consider blocking this person and/or reporting abuse
Thanks Adrian!
With independent non-HTML documents like PDF, images etc., I think it should be fairly straightforward - it's similar to web pages. If we were to use
Linkheader along with<link>elements, it gets a bit more interesting as we need to use either of them. HTTP headers come before response body, so it might make sense to useLinkeven when a<link>is present.When such content is embedded into a web page, we run into same problems as with iframes. From implementation perspective, it's easier to run as many payment streams as their are embedded content, but this can be very bad performance wise. If we were to monetize only "visible" or "active" content, it gets difficult to implement with all the edge cases (what if someone adds 100 1px images in a row etc.). Also, with the overhead of setting up payment, user might scroll away from the content before we even set up the payment.
I mean we'll have to use WHATWG URLs, but I get your point. I'll update the report to make it clearer.
This sounds exciting! I feel like we should again look into the
pay://URL scheme 😄