7 ms·

Web Credits Spec

60 points by bergie 10y ago

Someone1234 10y ago
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.
- zer00eyz 10y ago
  "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.
- web007 10y ago
  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 10y ago
    In other words, this spec is on the easy part of micropayments. The hard part is undefined.
    - nathancahill 10y ago
      Just like most specs.
  - Johnie 10y ago
    In other words, this spec is on the easy part of micropayments. The hard part is undefined.
striking 10y ago
> 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.
- blowski 10y ago
  Agreed. A spec is supposed to be enormously detailed. 2 pages sounds more like a summary blog post.
  - colejohnson66 10y ago
    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 http://tools.ietf.org/html/rfc1952
- woah 10y ago
  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 10y ago
    > 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.
- norea-armozel 10y ago
Johnie 10y ago
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/
Kinnard 10y ago
It seems like this is being drafted not "a draft".
Robin_Message 10y ago
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?!?
rdw 10y ago
Is it just me or does JSON-LD's use of urls as keys feel very XML/SOAP-Y?
- M2Ys4U 10y ago
  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 10y ago
It's notable that bitcoin is the default payment method.
jcranmer 10y ago
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-antipattern/ 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).

60 points by bergie 10y ago

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.

zer00eyz 10y ago
"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.
web007 10y ago
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 10y ago
  In other words, this spec is on the easy part of micropayments. The hard part is undefined.
  - nathancahill 10y ago
    Just like most specs.
- Johnie 10y ago
  In other words, this spec is on the easy part of micropayments. The hard part is undefined.

striking 10y ago

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

blowski 10y ago
Agreed. A spec is supposed to be enormously detailed. 2 pages sounds more like a summary blog post.
- colejohnson66 10y ago
  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 http://tools.ietf.org/html/rfc1952
woah 10y ago
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 10y ago
  > 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.
norea-armozel 10y ago

Johnie 10y ago

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/

Kinnard 10y ago

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

Robin_Message 10y ago

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

rdw 10y ago

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

M2Ys4U 10y ago
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 10y ago

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

jcranmer 10y ago

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-antipattern/ 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).