W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2014

Re: Payment Protected Resources -- Using HTTP 402

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 4 Aug 2014 18:52:02 +0200
Message-ID: <CAKaEYh+eJu64MwWNShmaOinrgRGrkE1eLo+mr33bNx7E0koqOw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Web Payments <public-webpayments@w3.org>
On 31 July 2014 02:58, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2014-07-31 01:04, Melvin Carvalho wrote:
>
>>
>>
>>
>> On 30 July 2014 18:15, Anders Rundgren <anders.rundgren.net@gmail.com
>> <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>>     On 2014-07-30 18:09, Melvin Carvalho wrote:
>>
>>
>>
>>
>>         On 30 July 2014 17:24, Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>
>> <mailto:anders.rundgren.net@__gmail.com <mailto:anders.rundgren.net@
>> gmail.com>>> wrote:
>>
>>              On 2014-07-30 14:38, Melvin Carvalho wrote:
>>
>>
>>
>>
>>                  On 28 May 2014 15:51, Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>
>> <mailto:anders.rundgren.net@__gmail.com <mailto:anders.rundgren.net@
>> gmail.com>> <mailto:anders.rundgren.net@ <mailto:anders.rundgren.net@>_
>> ___gmail.com <http://gmail.com> <mailto:anders.rundgren.net@__gmail.com
>> <mailto:anders.rundgren.net@gmail.com>>>> wrote:
>>
>>                       With this complete lack of clarity, the WebPayments
>> and WebID groups
>>                       won't ever leave their Incubation, IG or CG levels.
>>
>>                       HTTP 402 to a browser user?  Hardly.
>>
>>                       So obviously there must be at least two
>> server-actors involved, right?
>>
>>                       If not, the whole idea is bogus since *internal*
>> operations can be built
>>                       as you like and do not need a standards committee
>> for guidance.
>>
>>
>>                  Been thinking this through a bit more, with almost an
>> implementation ready.
>>
>>                  In the browser scenario the 402 is delivered, but so is
>> human readable text.  The primary means to continue will be the user taking
>> action, by clicking through a wizard that takes them through next steps.
>>
>>                  In the scenario of a robot or spider, if they have run
>> out of credit they need to obtain a new token, and should be smart enough
>> to know how to do this.  They keep using this token until that expires,
>> then either get a new token, top it up, or send funds via a digital
>> signature.
>>
>>                  The workflow for the user is initially non disruptive
>> and does not change.  But as browsers get smarter either natively, or
>> through polyfils etc.  The user experience has an upgrade path to make
>> payments seamless.
>>
>>                  The 402 code is already baked into HTTP, so I'm just
>> working out ways to use it.  I'm aiming to implement a simple pay wall as a
>> first app., but the same technology could be used for pay per view,
>> throttling, shared content, protecting sparql endpoints, streaming
>> bandwidth or disk and so on.
>>
>>
>>              Hi Melvin,
>>
>>              I understand the motives but would personally not take this
>> route for browsers
>>              which I regards as entirely different to "agents" even if
>> use run HTTP.  For
>>              the same reason I don't see HTTP Signatures as a useful
>> browser extension either.
>>
>>              Requiring browsers to be smarter is OK, but only if they can
>> perform some action
>>              that the user cannot.  If there is some local service that
>> the browser can call,
>>              the server should be able to return the necessary webcode
>> equally well.  If such
>>              a service is available or not should be dynamically
>> discoverable.
>>
>>
>>         There's no requirement for the browser to change.  Every browser
>> that I know of, can accept a 402 code today, and can render HTML.  That's
>> because, it's already standarized as part of HTTP.  So from the perspective
>> of the browser and the user, it's a non disruptive change.
>>
>>
>>     Right, but what does the 402 add to this particular scenario today?
>>
>>
>> There's no change to the standard browser experience.
>>
>
> It was easier for me understanding the following:
> https://bitcointalk.org/index.php?topic=3895.0
> which indeed suggests a changed browser experience.


Not quite what I have in mind.  There are many many things that talk HTTP
other than browsers.  Changing the browser may be an option, but I dont
want that to be in the critical path.


>
>
>  The only change is for spiders, robots and AJAX agents than can pass the
>> code on to a handler.
>>
>
> Would those interpret localized HTML?  I hope not.
>

I've now implemented this and it's working really well.

Essentially I've put a credit system on my content on my hard drive, so
that I need to earn credits before I can, say, play a song that I own.

I earn credits a number of ways, but generally my computer monitors my work
(eg keystrokes, lines of code etc.), and pays me a balance based on output.

So now I reward myself by being able to listen to music as I code more :)

Just experimental right now, but all I would have to do is open up a port
on my firewall and the same system could be applied across the whole
internet! :)


>
> Anders
>
>
>
>>
>>     Anders
>>
>>
>>
>>
>>              IMO, browsers remain the #1 pain-point for the WebPayment
>> and WebID communities.
>>
>>              Anders
>>
>>
>>
>>
>>                       Anders
>>
>>
>>                       On 2014-05-28 14:47, Kingsley Idehen wrote:
>>
>>                           On 5/28/14 1:27 AM, Anders Rundgren wrote:
>>
>>                               The most important thing in a payment
>> scenario are the actors and
>>                               their roles.  Linked Data in not a panacea.
>>  If there are only two
>>                               actors, HTML is all you need.
>>
>>                           Again, nobody is indicating that Linked Data is
>> a panacea.
>>
>>                           You need to be able to access, manipulate, and
>> exchange data for
>>                           anything to function in our realm of existing.
>> Linked Data simply makes
>>                           Data webby or web-like.
>>                           RDF based Linked Data simply ensures the
>> relations that constitute the
>>                           Data are human and machine comprehensible.
>>
>>                           RDF based Linked Data is a vehicle for encoding
>> and decoding
>>                           information, via statements, in the medium
>> provided by the Web (an HTTP
>>                           network).
>>
>>                           RDF based Linked Data is a kind of Controlled
>> Natural Language.
>>
>>                           Without Language, we are unable to function.
>>
>>                           Links:
>>
>>                           [1] http://slidesha.re/QEqLZN -- Natural
>> Language & RDF based Linked Data .
>>
>>                           [2] http://bit.ly/1c3QeEc -- Language .
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Received on Monday, 4 August 2014 16:52:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:38 UTC