Re: Payment Protected Resources -- Using HTTP 402

I think the concept has merit, and moreover the ontological functions would
be useful whether their part of thr webcredits ontology or otherwise
placed.

With relation to the usecase, I'd suggest "merit" orientated cases are
perhaps better "business models" rather than the concept of protected
resources off the bat.  Philosophically, the ability to provide resources
freely needs 'buy-in' which has traditionally been done via advertising
sales.  In some ways users are already treated like advertisers, by
prioritizing posts in lists which are then further reduced by paid posts
interwoven with ones sourced via existing named graphs.

If a "like" had the option of being a microcredit/debit,  the result may
stimulate further merit based activity,  where perhaps existing systems
focus more on the idea of sponsorship or prepayment.  like the difference
between hiring an act you've not seen, vs. Supporting a busker.

So, the ability to +1 an object / uri and whatever ontological means needed
to do so on the various platforms...  I note the bot at #webcredits
(freenode:irc) and I think you've now got the ability to have 'melvin pays
tim 0.0001' kinda thing.

Ie: a uri for an email would refer to from:email@address.tld ??

Uri for wiki post might refer to a sum or function (representing
contributors) stored in the page with some address?

Say tim / henry / manu / Kingsley / melvin contributed +/÷ service fee
(hosting/admin charges for wiki)

Ontologically both are important.  But in seeking open standards, my
preference would be to start finding ways of improving support for people
who essentially contribute as artists, rather than vendors.  This in-turn
may provide a sufficiently compelling reason for people to get a webid, and
start messing with embedding the relavent webpayments code.

Mind, its the wallet function ln that would perhaps need some work in
either case. A distributed means to locate different identifiers and
translate them into something that associates to the wallet address, seems
like a complex task...  obviously foaf helps.  Perhaps driving the thing
off a foaf addressbook...  does that mean you need a person/agent dedicated
as the wallet defined as an agent for the person...  therein perhapd the
agent provides transactions,  the person recieves the qudos / merit / karma
benefits...

License obviously translates, in terms of total bandwidth utilisation
verticals / graphs, doesn't seem to work so well to capture the audience,
regardless of the economics for provisioning the data without a rel:

Timh.

On 28/05/2014 3:24 AM, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote:
>
> Many of us are now using web ACLs on a regular basis.
>
> A rule may look like:
>
> <>
>     <http://www.w3.org/ns/auth/acl#accessTo> <.>, <> ;
>     <http://www.w3.org/ns/auth/acl#agent> <http://melvincarvalho.com/#me>
;
>     <http://www.w3.org/ns/auth/acl#mode> <
http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Write> .
>
> This essentially says that my user ID can have read and write access to
the named resource.
>
> I thought it might be an interesting idea to extend this type of access
control to allow payment protected resources.
>
> So each server will maintain a balance for each user, as is typical with
many commercial business models these days.
>
> If the user does not have any credit the server will return a 402 HTTP
response code, explaining the cost of the item and how they can top up
their balance.  This could either be via a traditional payment method such
as Euros, or, say, via a balance in crypto currencies, or as part of a
loyalty / reward scheme that the web site issues.
>
> I'm wondering if we can extend the vocab we have to add payments?
>
> Perhaps a simple way would be to subclass #accessTo with #paidAccessTo
>
> Then have in the ACL rule a simple payment amount (or rule)
>
> Then say something like:
>
> <#amount>  0.001^^BTC
>
> Anyone have any thoughts on whether this could be implemented?