W3C home > Mailing lists > Public > public-webpayments@w3.org > February 2012

Re: Web Credits Writeup

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Wed, 8 Feb 2012 20:58:52 +0100
Message-ID: <CAKaEYhJhMkwpFqfROcXwpHmSs2y47U==BW_ObhQzupiZ38xFHw@mail.gmail.com>
To: David Nicol <davidnicol@gmail.com>
Cc: opentransact@googlegroups.com, Web Payments <public-webpayments@w3.org>
On 8 February 2012 20:44, David Nicol <davidnicol@gmail.com> wrote:
>
> I like it. You've got to,from,currency,amount,message,a timestamp,
> I'm looking at the "storage" section which describes a JSON-LD data
> template.

Thanks

>
> When currency is a ISO currency identifier, who backs it? Allowing those
> implies a settlements system

ISO currencies are normally govt. issued.  The base spec does not have
a specific settlement system.  But one could be built on top.  I'm
thinking about a ripple integration.

>
> Also, "storage" is an implementation detail. I'm understanding this section
> to be misnamed, as it is about what the transfer looks like on the wire. A
> section title like "JSON-LD Field Names" or whatever the right term from
> JSON-LD jargon is would be better.

they are just key value pairs, sometimes called attribute / value,
sometimes called predicate / object

The storage data structure here is exactly the same as the message
structure, which I think is quite neat.  You store an IOU, you send
someone an IOU.  Summed IOUs give a balance.  A bit like online
banking.

>
> The ID could be explained better. Is it supposed to be unique? Is it how one
> looks up a transfer? To get the URL for a transfer do I append the ID to the
> "context" or what? If all the fields are predictable, a hash of the transfer
> in wire format is not secure.

Yes, agree, that can be fleshed out.  The ID is actually optional, but
having a globally unique identifier is one of the foundational
principles of the web  It allows namespaces and non colliding data
points.

So a web page is a document, inside a document can be data points.
You normally describe it as:

example.com/doc#dataID ... the data ID here is just a unique sha1 sum
... it means it can be used in a foreign key for other workflows etc.

>
> what is the "context" for? ... oh, that's a JSON-LD thing
> http://json-ld.org/spec/latest/json-ld-syntax/#syntax-tokens-and-keywords
> like "xmlns" in XML. I don't think the -LD stuff is needed at all here: it
> complicates things for no gain.

This is to make things globally unique and non colliding terms.
There's a few other benefits but those are the initial ones.  Imagine
if everyone came up with their own terms and everyone had a spec it
would be kind of chaotic.  The Linked Data part allows web scale
interoperability.

In a way it is the magic sauce.

>
> It could use  "originator" and "originator-ID" fields, which whoever
> originates this transfer object is responsible for filling in, also a
> "status" field about if this transfer is
> proposed/rejected/approved/completed, there are other statuses that are
> probably needed when using ISO currencies to handle the various states
> between approval and completion.

I thought long and hard about adding state to the object, having
talked to matt slater.  This is the one field they have in LETS that
web credits doesnt have.

I decided not to complicate the core data with this field.

It's perfectly possible to extend the model in JSON to use status
either as member field or to reference this object as a foreign key.
I prefer the foreign key approach in order to keep the base structure
clean and analogous to network theory topology.

>
> Various expiration-date fields could be added to answer, how long does it
> persist without getting approved, or without getting completed, and how long
> will it be available for access after it has been completed, if it is going
> to get archived where will it be archived to and how long will it be
> retained? a callback URL for rejection, or expiration events, either a
> separate URL for each possible event or another little language for use in
> the callbacks

The next thing to extend is workflows based on the base structure.

Just like in an SQL database one table does not rule them all, but you
an have a base table and build others up around it as they become
needed.  This is also the essence of the web as a giant database.

Finance can explode in complexity quite fast so I thought it would be
an idea to build the smallest useful building block I could imagine,
and demonstrate how it could be used etc.

Hope that helps!

>
>
> those are some things it seems like its missing.
Received on Wednesday, 8 February 2012 19:59:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC