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