The Interledger Community 🌱

Discussion on: Exploring integration of Web Monetization into the Web Platform β€” Grant Report #1

Collapse
 
adrianhopebailie profile image
Adrian Hope-Bailie

@sid

This is fantastic progress, well done!

I think the decision to move to the <link> tag is a good one. One challenge we'll need to explore is what we do with link relations in HTTP headers, have you given that any thought? It's not something we can support from the extension because extensions don't have access to the response headers as far as I know.

On the topic of Payment Pointers, I wouldn't say we're abandoning them but rather that if we use the <link> tag then we'd need to use the full URL form of the Payment Pointer as opposed to the shortened form which is primarily for user transcription and readability.

As an aside, a Payment Pointer is just a URL, but it is a URL that we expect to have very specific behaviours when dereferenced. In this case the resource it is locating is an account that we can send money to via Interledger. 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).

Finally, how do we get some more smart people like yourself to repeat this awesome work on some other browser engines?

@chrislarry and @erikad how can we get more Technical Scholars into the Grant for the Web Program to do this work?

Collapse
 
sid profile image
Sid Vishnoi • Edited

Thanks Adrian!

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 πŸ˜„

Collapse
 
erikad profile image
Erika

@adrianhopebailie We are very enthusiastic about expanding the Technical Scholars program to additional browsers teams. We're drafting info for potential host organizations that will be shared soon. In the meantime, interested team leads are welcome to reach out to @chrislarry and myself directly.