
Web Credits Spec - bergie
https://www.w3.org/community/webpayments/wiki/Web_Credits
======
striking
> The aim of this spec is not to exceed 2 pages

Then this spec will never be anywhere close to complete.

Money isn't just a piece of information that can pass from one place to
another. "encryption, workflow, trust and aggregation systems" are not just
things you can handwave away.

Who is willing to process transactions like these? Why is encryption and
signing not part of the standard?

What happens if I post a credit that is not my own, or with the same @id but
differing contents? How much data is exposed by GET /wallet, and will it be a
privacy concern?

It's just not helpful.

~~~
woah
The point of specifications is to standardize certain parts of a system where
it interfaces with other systems using the same spec. This looks like it is
supposed to pass information from a user interface to a payment system.
Specifying the entire system would defeat the point of the specification.

~~~
striking
> certain parts of a system

Implying there is a greater system to speak of. Or even that one has been
contemplated.

This doesn't fit into any sort of existing payment processing system, nor do
the identity systems this is supposed to rest on top of exist.

------
Robin_Message
At the top of the article, expounding simplicity and independence of
implementation:

 _So you could take html without taking http_

In the specification:

 _The Credit structure specified is RDF. Turtle and JSON-LD SHOULD be
supported._

Is a complete contradiction of that principle.

Also, what is the point of this spec? To be a very basic way to overcomplicate
the easy bit? Why?!?

------
jcranmer
First off, this is a community group "specification," which is to say, it's
part of a W3C process that's supposed to be easier for lay community members
to be involved--and easier for people who have no clue about implementation
issues to hijack the process [1]. So I decided to do some digging to see how
involved actual browser vendors were in the process...

The backstory seems to involve a very, very acrimonious community split. See
[http://manu.sporny.org/2016/browser-api-incubation-
antipatte...](http://manu.sporny.org/2016/browser-api-incubation-antipattern/)
(it's a biased view, and I haven't researched alternative viewpoints).

As far as I can untangle, the community group here decided they wanted to
dictate to browser vendors what they should implement, complete with
philosophical viewpoints. The working group that actually has traction with
browser vendors and is likely to implement doesn't appear to be paying too
much attention to this, and the community group seems unwilling to engage with
the browser vendors meaningfully.

In short, this is unlikely to go anywhere.

[1] It should be noted that regular WGs are also amenable to this capture
(e.g., the XHTML work that ended up with all the browser vendors quitting).

------
Johnie
There's also the W3C Web Payments Interest Group [1] and the defunct
Micropayments Interest Group [2].

Micropayments for web content is notoriously hard.

Some existing players are:

* Flattr - [https://flattr.com/about](https://flattr.com/about)

* ChangeTip - [https://www.changetip.com/](https://www.changetip.com/) (acqui-hired by AirBnB)

* Patreon - [https://www.patreon.com/](https://www.patreon.com/)

[1] [https://www.w3.org/Payments/IG/](https://www.w3.org/Payments/IG/)

[2] [https://www.w3.org/ECommerce/](https://www.w3.org/ECommerce/)

------
Someone1234
This leaves too many open questions as it currently stands. There's far too
much hand waving about how an actual implementation of this may look (e.g.
support for different currencies, verifying, consolidation, etc).

There's no specific reason this cannot work, but we won't know until it is
much more fleshed out.

~~~
web007
All of the elements you believe are hand-waving are addressed - this is just a
wallet specification, not a (crypto)currency specification.

> Web Credits are currency agnostic. Currencies such as time banks, bitcoin,
> virtual items and karma are supported.

~~~
Johnie
In other words, this spec is on the easy part of micropayments. The hard part
is undefined.

~~~
nathancahill
Just like most specs.

------
rdw
Is it just me or does JSON-LD's use of urls as keys feel very XML/SOAP-Y?

~~~
M2Ys4U
More RDFey. You can elide them away by using a Context.

For example: { "@context": "[http://schema.org/"](http://schema.org/"), "@id":
"#bigbang", "@type": "Event", "name": "The Big Bang" }

is equivalent to { "@id": "#bigbang", "@type":
"[http://schema.org/Event"](http://schema.org/Event"),
"[http://schema.org/name"](http://schema.org/name"): "The Big Bang" }

This makes things extensible.

------
ktRolster
It's notable that bitcoin is the default payment method.

------
Kinnard
It seems like this is being drafted not "a draft".

