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

On 02/25/2012 03:17 AM, David Nicol wrote:
> Manu Sporny:  Yes, but in most cases, they won't because 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.

This goal is much more clear and I agree with your take on it. There is
supposed to be, in fact, one context used throughout all of the PaySwarm
specifications:

"@context": "http://purl.org/payswarm/v1"

Other contexts may be added to address application-specific
requirements. For example, one could use PaySwarm to define a listing
for a house for sale:

"@context": ["http://purl.org/payswarm/v1",
              "http://purl.org/realtor/v1"]

The second context would layer on top of the first one and allow people
to describe things that are specific to the housing market, things like:

    "rooms": 5,
    "bathrooms": 2,
    "askingPrice": {
       "amount": 283394,
       "currency": "USD"
    }

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

A context in JSON-LD works very much like an #include or @import
statement. That is, the document it points to declares keywords that can
be used in the document and what those keywords mean. Keywords can be
Classes (Person, Place, Event), Properties (hairColor, geoLocation,
startTime), or Datatypes (pounds, meters, minutes).

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

I will try to find different wording that is both accessible to
individuals that only know JSON and clear.

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

Ok, I'll attempt to do this in the next revision of the specification.

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

Would you prefer "ps:source" or "source"?

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

Yes, agreed.

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

Kinda... "Web of Trust" is a pretty general term. So, the answer to your
question is both yes and no.

A Web of Trust as it pertains to PaySwarm works more like this:

A trusts B.
B trusts C.

Therefore, it is safe to assume that if you trust B, then you can
probably trust C. If you don't trust C, you can still perform a
transaction with B as an intermediary, who will then eventually do the
transaction with C (this is how Ripple works).

Another form of a Web of Trust is if you trust your authority and the
way it validates identities and amounts in financial accounts, then you
can probably trust that funds sent to you from someone else on the
authority will get to you. Then if there are two authorities that trust
each other, you can probably trust that funds sent to you from someone
else on another authority will get to you... and so on, and so on.

I think what you're discussing above is a Currency Mint and this is how
we think it's going to work in the future:

1. The Currency Mint is responsible for creating new amounts in its
    native currency - which are typically placed into an authority of
    some kind.
2. An authority contacts a Currency Mint, usually on behalf of somebody
    that wants that particular currency, and performs an exchange
    (USD for egg points, for instance). The new egg points are placed
    into the receivers account (the person that paid for the egg points).
3. The egg points can then be traded on the network, eventually ending
    up back at the currency mint to be destroyed/consumed/recycled.

Alternatively, no purchase of currency has to occur, the currency mint
could deposit egg points into someone's account for any reason it
chooses (randomly, good deeds, favors, work performed in advance, etc.).

> 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

If you want to use hives and bees as an analogy:

The Hives are Authorities
The Bees are Participants
The Honey are Transactions

(assuming that bees swap honey with other hives, etc.)

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

There are a number of ways this could be done:

1. There is a public record of all egg point transfers (this violates
    privacy as everything can be tracked).
2. There is a private record at the Currency Mint of all egg point
    transfers (this violates privacy as the Currency Mint can track
    all egg points).
3. Each unit of currency comes with a certificate of authenticity and
    that certificate must travel with the transaction (prevents
    smaller denominations of the currency than those minted).
4. An Authority must keep a record of all currency coming into and
    going out of the system. A Currency Mint must digitally sign all
    currency created and handed over to an Authority. An authority
    must be able to audit all currency that came into it's system and
    goes out of it's system - the books should always balance. If they
    don't, fraud has occurred and the audit trail can be subpoenaed.

The 4th solution is probably the only workable one from a privacy
perspective.

> So the message has to name the currency, and the hive where the
> source's account is,

It can do both with one URL:

http://detroit-egg.coop/currencies/egg-points

(that /could/ name the currency and the original source account).
However, you could also split them - no preference, possibly the latter
is more flexible.

> is that pretty much how everyone else envisions decentralized
> settlements working?

I think what was discussed above conflates two things: Currency Mints
and Decentralized Settlement. Decentralized Settlement doesn't care
about what currency you're trading - it just cares that the currency is
transferred from authority A to authority B and the books are left in a
valid state on both authorities.

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

Yes, I agree. This is why the Currency Mint algorithm is going to have
to undergo extensive testing before it goes out into the world. The
Decentralized Settlement Algorithm using fiat currencies, however, is a
different problem and is one that is easier to solve (because the
enforcement infrastructure largely exists today - credit cards, banks, etc.)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Saturday, 3 March 2012 20:09:54 UTC