Re: Web Payments Telecon Minutes for 2012-02-10
David Nicol
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 couldManu Sporny: What I'm saying is that there is no requirement that every
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.
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:
- dereference DCC-OEP currency IRI
- is the source hive a trusted hive for this currency?
- Phooey, they aren't. query the source hive concerning it's authority to deal in DCC-OEP
- source hive states that source received those egg points from an account verified by attocoin, which is one of the two on the list.
- Excellent. Query attocoin concerning the standing of the source hive, including the amount of DCC-OEP arriving.
- 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)
- receiver accepts.
required layers:
- Backer: the Detroit Coop Co-op
- Preferred hives: Picomoney and Attocoin
- Other hives: both the source and destination hives in the example. Hives have accounts with one or more preferred hives for aggregation purposes
- 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.
Manu Sporny
> 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/
Walter
Sorry I don't have time to look further through the group and
proposals yet, however I hope to catch up to where you are at
eventually and contribute further.
Right now though there's a couple of things I thought to mention that
you may find interesting or useful -- "just my two cents".
>> all the JSON-LDisms are marked as such in the main text, and the
>> JSON-LD touting entirely removed.
Another standard, JSON Schema, is relatively well developed and offers
a lot of extra functionality in addition to JSON-LD ... for example
schema specification in addition to linking. I have been using and
following its development recently. It's sort of like 'extremely
lightweight XML DTDs for JSON'. Though there are no authoring tools
right now, it's pretty lightweight and easy to get in to, though the
embedded schemas mechanism can be a bit confusing. Anyway, if
interested do take a look: http://json-schema.org/
>> 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.
That's really precisely what we've been looking at with the
still-evolving proposal for a settlement system and asset (or
currency, or credit/debt measurement denomination, etc...) neutral
transaction protocol. Over the last couple of days the the IETF
Application Area Workgroup Managers asked me to publish an outline to
their general list, which is available here:
Hopefully then we shall soon have a mailing list for the discussion of
precisely that type of solution shortly.
As an aside, by contrast from present readings it strikes me that the
W3C Web Payments effort appears to be more focused at this time
explicitly on web-based technologies and integration of simple to
deploy payments mechanisms within the general web infrastructure.
This is a different sort of problem area, in that it seems to keep a
lot of the more exotic requirements of large scale financial networks
and markets out of scope (non point-to-point communications being an
immediate example).
>> 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.
This sounds rather centralized. Our approach has been to avoid
specifying any particular trust mechanism and leave it up to natural
evolution of deployment norms to create solutions that meet the needs
of early and future adopters. Theoretically this makes greater
protocol flexibility and longevity assured.
> 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).
(In no way directly related to this discussion on web of trust) This
style of intermediary-based approach is also absolutely critical when
you want to make transactions along what we have taken to calling a
'settlement path' that necessitates the acquisition of alternative or
intermediary assets (or value-stores, currencies, debt/credit
denomination types, whatever your preferred terminology) in order to
effect settlement. For instance, if A holds Apples and C demands
payment in carrots, B has a supply of both, the settlement path A <->
B <-> C could facilitate.
> 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.
Again, by contrast we explicitly avoid any notion of authorities at
the protocol level.
> 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.
This notion appears be based upon a false generalization: not all
assets are centrally issued, nor are they consolidated. If the goal is
to deal only with centrally issued and consolidate currencies, then
that's fine. But one should be explicit about such things. A lot of
the community currencies are not centrally issued. Economists appear
to distinguish between two kinds of asset, 'consolidated' and
'non-consolidated'. Consolidated assets are those in which the entire
distribution of an asset is mappable at a certain place ("authority")
and remains ad infinitum, for instance the case of directly held
stocks on a financial market. Non-consolidated assets are the
inverse, for instance physical cash and coinage issued under standard
government currencies -- nobody can ever tell where they've gone.
In our transaction protocol effort, we are trying not to limit scope
at all, thus seek to cover all possibilites. However, perhaps it is
appropriate for the web payments effort to work on a more limited
scope. However, I raise the point as it is possible that this is a
de-facto property of the proposed solution under discussion and has
not been explicitly considered. (It's also possible I've missed
something.)
Regards,
Walter Stanish
Payward, Inc.