Web Credits Spec | Hacker News Reader

Web Credits Spec

w3.org

60 pointsbergie18 comments

> 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.

Agreed. A spec is supposed to be enormously detailed. 2 pages sounds more like a summary blog post.

To be fair, specs can be short. A wildly used spec that's only 11 pages long (of which only 6 are the actual specification) is RFC 1952[0], the specification of the GZIP file format (.gz)

[0]: http://tools.ietf.org/html/rfc1952

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.

> 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.

I agree since you have to deal with various banking systems. In the US this would just be such a mess to support considering ACH (could you do ACH from anything akin to this Web Credits spec?). Bleh this is just a bad idea all around.

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?!?

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... (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).

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

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

* Patreon - https://www.patreon.com/

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

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

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.

"The aim of this spec is not to exceed 2 pages"

Your absolutely right, and anyone who thinks they can do all that in two pages is very misinformed.

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.

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

Just like most specs.

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

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

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

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

This makes things extensible.

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

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

Reply on news.ycombinator.com