Re: Web Credits Writeup

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.

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

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.

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.

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

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.

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


those are some things it seems like its missing.