Re: Web Payments Telecon Minutes for 2012-02-10

> Manu Sporny:  Yes, but in most cases, they won't becaue the
>   context will be hard coded or cached. It is a security risk...
>

There seems like there's a bounded set of payswarm contexts, which are all
registered already at purl. What I believe I had been trying to say, and
will try to reiterate here, now, is: The specification document would be
clearer, and might actually promote JSON-LD better, if the list of contexts
is enumerated at the beginning, and then an example of the use of each is
provided. They could all be explained, line-by-line, in some kind of
appendix. aside from that, all the JSON-LDisms are marked as such in the
main text, and the JSON-LD touting entirely removed.

Towards that vision, I rewrote a paragraph -- that also appeared right at
the top of json-ld.org -- to state that "invariant portions of the messages
have been designed for conformance with JSON-LD" and after that, the parts
of the messages that seem unintuitively complicated can be justified as
required for JSON-LD compliance.

For instance, it took me several tries before I understood that the
"@context" property is essentially the type (a.k.a. class) of a JSON-LD
message object, and by the time I had reached that epiphany, the hour I had
budgeted for looking over the spec had expired.

To repeat again. I find the sentence "[JSON-LD] is based on the already
successful JSON format and provides a way to help JSON data interoperate at
Web-scale" off-putting on two counts. 1: "based on" is vague. I take that
to mean that JSON-LD is a proper subset -- that a more precise term than
"based on" might be "refinement" -- that it's a proper subset, so all
well-formed JSON-LD messages are well-formed JSON messages, but not the
other way around. But I don't know for sure if that's right, especially if
that sentence is all I know about JSON-LD.  2: "[JSON-LD] provides a way to
help JSON data interoperate at Web-scale" seems like snowing rhetoric. Just
parse that -- what's the subject of the dependent clause? JSON data. What
are JSON data? JSON data are string representations of data structures in a
particualr format, Javascript Object Notation, intended for convenience as
inputs to systems running ECMA-262, because JSON is a proper subset of
ECMA-262. Are these string representations capable of accepting help at
interoperating, whatever that means to string representations of data
structures, as if string representations of data structures were
independent agents attempting to interoperate? That's a nonsensical
question, because they aren't. "JSON data" do not have minds, and are
therefore not capable of accepting this help. What could this off-putting
sentence really be trying to say? I think it's something like "The
[JSON-LD] format solves some problems that have been experienced when
designing interoperable systems using the JSON format" but I'm not sure, as
that isn't what it actually says, and the context is a specification
document, where everything is supposed to be painfully literal.  So my hope
is that the authors of the document will clarify that language, and show,
not tell, the JSON-LD features, as they come up in the explanations, and
only then might I form an opinion on the question of, does the benefit of
having @context properties and namespace-decorated property names, and the
other aspects of JSON-LD that set it apart from JSON, does the benefit of
this extra noise justify the extra noise?

the convention of setting @context to state what type of message it is,
instead of simply expecting a particular message at a particular point in
the dialogue, is great, no problem with that, I wouldn't have called it
'@context' but I don't have a competing draft standard in hand at this
point; this convention could be explained.

Pelle Braendgaard:  Most of functionality should be useful w/o
>   JSON-LD library. You should be able to use just regular JSON.
>

I think it's reasonable in 2012 to expect potential implementors to be
familiar with JSON. So if the document was written in JSON terms, but using
JSON-LD, with contexts and namespaces and the rest of it, but before those
appear they are explained in prose, instead of punting to the JSON-LD
specifications, that would be a good thing. Like,

       The "ps:source" property has for a value an IRI defining the payer.



Manu Sporny:  Spec split into four major components, along the

>   lines that Pelle outlined. Didn't think spec split was going to
>   lead to as many arguments as it did.
>

Everyone who said they'd read it if it was split up did.

Pelle Braendgaard:  For example - w/ OpenTransact - you could use

>   it to transfer Domains, you could use it for Shares, you could
>   use it for non-traditional money. It could be a local community
>   currency - it wouldn't make any sense to have a decentralized
>   settlement process.
>
Manu Sporny: What I'm saying is that there is no requirement that every

>   authority has to accept every currency. You're right - there are
>   some currencies where it doesn't make sense for it to be
>   decentralized.
>


Let's posit a competitor to picomoney (Pelle's operation) called, err,
attocoin, and their differentiator is they allow transactions with a
resolution a million times more accurate than what is available at
picomoney. Some currency backer, say, the Detroit Urban Laying Hen Owners
Collective, a.k.a the coop co-op, has established a currency redeemable on
demand, modulo availability, for a fresh egg from any participating coop,
with redemption rules and procedures established by the co-op -- something
like, coops gather eggs twice a day, and currency holders must claim their
eggs before the gathering they want eggs from, based on the projected
collection, and they are allocated first-come first-serve until the
projection is exhausted, then there is a four hour window when they buyers
can pick their eggs up, and after that the remaining reserved eggs are put
in with the general for-sale stock. Something sort of like that, but more
practical. Anyway they have registered egg credits with picomoney, and now
they're registering with attocoin too.

At this point, decentralized settlement protocols start making sense, and
the trust relations can be made the responsibility of the ultimate backer.
The coop co-op treats egg credits from picomoney accounts the same as egg
credits from attomoney accounts. A distributed settlement system in my
opinion should be able to handle this scenario.

Handling means, the JSON message one gets from accessing the IRI for
the *Detroit
coop co-op egg point* currency must include, either inline or by reference
to another IRI, or both, a list of one or more registries trusted by the
Detroit coop co-op to be legitimate and trustworthy.

is that pretty much how the mentioned "web of trust" thing is supposed to
work?

But to get to the question of requiring any participating hive -- they're
hives, right? and the transactions are the bees? or are the customers the
bees? I'm not entirely clear on that and not looking at the spec, so for
this e-mail both picomoney and attocoin are hives -- to accept any
well-formatted transaction, the way any bank will cash a well-formatted
check for their own account holders drawn on any other bank

when the transaction initiating message comes in, the question is, how do
we know that the egg points are genuine Detroit egg points, with an audit
trail back to issue by the Detroit coop co-op?  So the message has to name
the currency, and the hive where the source's account is, and the receiving
hive has never received any Detroit egg points before and isn't sure what
to do with them. it's well-formatted, though, so something like this
happens at the receiving hive:

   1. dereference DCC-OEP currency IRI
   2. is the source hive a trusted hive for this currency?
   3. Phooey, they aren't. query the source hive concerning it's authority
   to deal in DCC-OEP
   4. source hive states that source received those egg points from an
   account verified by attocoin, which is one of the two on the list.
   5. Excellent. Query attocoin concerning the standing of the source hive,
   including the amount of DCC-OEP arriving.
   6. Attocoin states that the source hive has at least that much DCC-OEP,
   and furthermore offer a policy statement of some kind containing Attocoin's
   settings for whatever might be left variable in the protocols and policies
   regarding DCC-OEP at Attocoin, and that they have debited sender's numer
   and credited receiver's number (sender and receiver are both hives here,
   not accountholders)
   7. receiver accepts.


required layers:

   1. Backer: the Detroit Coop Co-op
   2. Preferred hives: Picomoney and Attocoin
   3. Other hives: both the source and destination hives in the example.
   Hives have accounts with one or more preferred hives for aggregation
   purposes
   4. account holders: individuals or other legal entities, the source and
   destination of the transfers have accounts at hives.

is that pretty much how everyone else envisions decentralized settlements
working? The thing about "normal money" is, unless you're Warren Mosler
(google him and his "required reading" list) or such you never bother to
think about the top two layers, and there's enforcement infrastructure in
place to discourage bad checks.

Alternative currency engineers don't have the luxury of centuries of
acceptance though. The protocol MUST be able to withstand all kinds of
nonsense, otherwise the Detroit Coop Co-op will surely visit us with
spoiled product and throw it at our houses.