Most active commenters
  • jfoutz(3)

←back to thread

756 points dagurp | 11 comments | | HN request time: 0s | source | bottom
1. jfoutz ◴[] No.36882062[source]
This kinda seems like a fantastic way to implement micro payments. The site owner sets up a attestor that knows they’ve paid.

I hate Wei in general, but it really could open up control over bots and paid access.

replies(2): >>36882168 #>>36882351 #
2. wbobeirne ◴[] No.36882168[source]
There is no reason that can't be done with existing web technology, WEI does not advance that use case in any meaningful way.
replies(1): >>36882384 #
3. burkaman ◴[] No.36882351[source]
Are you aware of any websites that have tried to implement payments, but failed or chose not to because they couldn't verify which users have paid? It's an incredibly easy problem to solve without WEI.
replies(1): >>36882529 #
4. jfoutz ◴[] No.36882384[source]
It provides a uniform service for ensuring a client has desired properties.

That’s kinda tricky to do well. Traffic for monitoring, you can do with a jwt, but like, enabling chunked transfer in python request lib is a problem you discover. An array of attestors could guarantee feature sets.

replies(4): >>36882530 #>>36883260 #>>36883315 #>>36884634 #
5. jfoutz ◴[] No.36882529[source]
Yet another username password pair? Yet another credit card entry?

Nah, let jfoutz pay the fraction of a penny and get no ads. Content producer gets paid, and I get to read the article.

The site can choose, based on attested properties to send to an ad network, or just take the money from the user.

There are other ways to do it, but this makes it a standard.

replies(2): >>36882776 #>>36882796 #
6. wbobeirne ◴[] No.36882530{3}[source]
I'm not understanding how giving the client a token that you put in a request header that proves you've paid, or is just an account lookup token to then ask a payment processor whether or not their account is in good standing, is limited in a way that WEI makes better. I don't see any use cases that wouldn't work that way that would now work with WEI.
7. burkaman ◴[] No.36882776{3}[source]
I genuinely am not understanding why you think WEI would make this easier. You have one central place that you log in to set up this payment system, I guess Google in this case, and then other sites check with the central authority to see if you're a paying user. They can use this attestation or a cookie or a Log In With Google button, what's the difference? Either way when you browse from a new device you'll have to log into the payment system again.
8. Ylpertnodi ◴[] No.36882796{3}[source]
Standard xkcd standards cartoon inserted here.
9. nobody9999 ◴[] No.36883260{3}[source]
>It provides a uniform service for ensuring a client has desired properties.

I see that as a downside, not a benefit -- who decides whether or not a client (i.e., my software running on my hardware) has those "desired properties" and what might those properties be?

10. danShumway ◴[] No.36883315{3}[source]
> for ensuring a client has desired properties.

There's nothing about payments that requires testing client properties though. What you want is the ability to test if there's a corresponding payment, that has nothing really to do with the client's device. It just seems like irrelevant information, what are these "desired properties"?

You want a corresponding token with the request that matches a payment. And WEI seems like a strictly inferior way to get that instead of just... asking a payment provider for the token. What does my hardware/OS/browser have to do with a payment token?

11. doxick ◴[] No.36884634{3}[source]
This will be great when both my partner and i use the same browser but different ... Different what exactly? Ah.. accounts!

"This allows them to detect the actual device"... As if that isn't a solved space already?