Manu Sporny: Yes, but in most cases, they won't becaue the
context will be hard coded or cached. It is a security risk...
Pelle Braendgaard: Most of functionality should be useful w/o
JSON-LD library. You should be able to use just regular JSON.
lines that Pelle outlined. Didn't think spec split was going to
lead to as many arguments as it did.
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
authority has to accept every currency. You're right - there are
some currencies where it doesn't make sense for it to be
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.
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
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:
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:
> 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.
> 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
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
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
> So the message has to name the currency, and the hive where the
> source's account is,
It can do both with one URL:
(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 Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
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
>> 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