search

WICG / webmonetization

Proposed Web Monetization standard
https://webmonetization.org
Other
466 stars 152 forks source link

Drop support for "payment pointers" #201

Closed marcoscaceres closed 1 year ago

marcoscaceres commented 3 years ago

Payment pointers are an important/established part of the Web Monetization ecosystem. However, they are incompatible with href attribute, in that the href attribute must take a URL.

So, I'm thinking, why don't we just create our own attribute pointer for <link>, that takes a payment pointer... it then dereferences itself and automatically sets the .href attribute. 

<link rel="monetization" pointer="$some1231231">

<link rel="monetization" href="https://foo.com/details.json">

<!-- pointer wins? ---> 
<link rel="monetization" pointer="$some1231231" href="http://foo.com/details.json">

That solves for both .href attribute and for payment pointers.

@AlexLakatos wdyt?

marcoscaceres commented 3 years ago

Another think we might want to add as a dereferencing function on the monetization interface, which returns a URL object:

const URL = navigator.monetization.pointerToURL("$whatever")

// Or, probably better, as a static
const URL = Monetization.pointerToURL("$whatever");
AlexLakatos commented 3 years ago

I like the idea of having a "pointer" attribute! For the JS part, I think a static Monetization.resolvePointer("$whatever") would look better.

marcoscaceres commented 3 years ago

I've been looking more into payment pointers and trying to see if they provide enough value to justify standardization.

Although payment pointers do provide some assurances (https, strict URL subset, no username:password) and convenience (dereference to a "well-known" URL), they only do so at the client layer.

Unfortunately, the more I investigate them, the less value I feel they add over regular URLs.

I think even this proposal might end up making things more messy (particularly if you change one, then it affects the other, etc.).

In the end, a payment pointer is just a URL, so I think we should just stick with a single URL scheme.

I think there might also be some weirdness in how they associate with well-known URLs. Link relationships are usually explicit to a URL, rather than relying on well-known URLs.

adrianhopebailie commented 3 years ago

In the end, a payment pointer is just a URL, so I think we should just stick with a single URL scheme.

I agree. The way I have always thought of them is that they ARE urls, just they have a shortened form that is easier for recognition and manual transcription.

marcoscaceres commented 3 years ago

Yeah, they are nice in that sense, which is why I was also motivated to keep them.

However, as I said above, I don't think they add significant value, so if it's ok with everyone, we should drop them.

AlexLakatos commented 3 years ago

I'm going to play devil's advocate here. Looking at the spec for Payment Pointers, one of their design goals was to provide a unique and easily recognizable way to exchange payment information. And they achieve exactly that.

URLs on the other hand, while they are unique, have no easily recognizable way to see what's behind them. If we're designing for software here ( the browsers ), then I'm all up for using only URLs. But I feel keeping both around for user experience reasons would be the better way to go.

marcoscaceres commented 3 years ago

But I feel keeping both around for user experience reasons would be the better way to go.

Problem is that they are incompatible with <link href="">. They also seems to somewhat misuse /.well-known/.

marcoscaceres commented 2 years ago

Just noting that moving to <link> will make this happen regardless, as href expects a URL.