Agenda: Web Payments Telecon - Friday, January 13th, 2012
Manu Sporny
We have a Web Payments telecon coming up on this Friday. For those on
the OpenTransact list, these are public telecons, anyone can attend,
everyone who would like to provide constructive input is welcome.
There has been a very in-depth technical analysis performed on the
differences between OpenTransact and PaySwarm[1,2,3,4,5]. We should
discuss some of the highlights of this analysis on the call and then
plot out a path going forward. I don't expect it will be an easy
discussion, but it is a discussion that we must have as a group.
The dial-in information as well as minutes and audio logs of previous
meetings can be found here:
==========
Friday, January 13th, 2012
Time: 1700 UTC, 9am San Francisco, 12pm Boston, 5pm London
Digital Bazaar Telecon Bridge
SIP: pays...@digitalbazaar.com
Phone US: +1.540.961.4469 x6300
irc://freenode.net/#payswarm
Duration: 60 minutes
Scribes: Manny, Manu, Dave, Jeff
==========
Agenda
1. PaySwarm / OpenTransact Technical Comparison Highlights
* Modularization (PaySwarm)
* Interoperability (OpenTransact)
* Centralization (OpenTransact)
* Future Complexity (OpenTransact)
* Other Highlights?
2. Planning a Path Forward
* Changes to Design
* Changes to Specs
-- manu
[1] Web Payments: PaySwarm vs. OpenTransact Shootout (Part 1)
http://manu.sporny.org/2011/web-payments-comparison/
[2] OpenTransact the payment standard where everything is out of scope
http://stakeventures.com/articles/2011/12/21/opentransact-the-payment-standard-where-everything-is-out-of-scope
[3] Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2)
http://manu.sporny.org/2012/web-payments-shootout-part-2/
[4] OpenTransact vs PaySwarm part 2 - yes it's still mostly out of scope
http://stakeventures.com/articles/2012/01/02/opentransact-vs-payswarm-part-2-yes-its-still-mostly-out-of-scope
[5] Web Payments: PaySwarm vs. OpenTransact Shootout (Part 3)
http://manu.sporny.org/2012/web-payments-shootout-part-3/
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/
Pelle Braendgaard
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
Manu Sporny
We have a Web Payments telecon coming up on this Friday. For those on
the OpenTransact list, these are public telecons, anyone can attend,
everyone who would like to provide constructive input is welcome.
A new Editor's Draft of the PaySwarm Web API specification [1] was
published a week ago. This updated specification outlines simple
transactions, the decentralized settlement process, data portability and
migration, and transaction intents/crowd-funding. We should probably
review those updates. The Web Keys specification was split out of the
PaySwarm specification shortly there-after[2], which we should probably
discuss as well.
The dial-in information as well as minutes and audio logs of previous
meetings can be found here:
==========
Friday, January 27th, 2012
Time: 1700 UTC, 9am San Francisco, 12pm Boston, 5pm London
Digital Bazaar Telecon Bridge
SIP: pays...@digitalbazaar.com
Phone US: +1.540.961.4469 x6300
irc://freenode.net/#payswarm
Duration: 60 minutes
Scribes: Manny, Manu, Dave, Jeff
==========
Agenda
1. Updated PaySwarm Editors Draft [1]
*
http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0043.html
* The Transaction Process and Algorithm
* The Decentralized Settlement Process
* The Data Portability and Authority Migration Algorithm
* The Transaction Intents Process and Algorithm
2. Web Keys Editors Draft
*
http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0048.html
* Goals of the specification
-- manu
[1] http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0043.html
[2] http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0048.html
Manu Sporny
We have a Web Payments telecon coming up on this Friday.
The PaySwarm spec has been split into three separate documents[1]. Let's
review the split and figure out where we should focus our work over the
next two months. Our CTO has also requested that we move the telecons to
4pm EST on Friday so that he can join. It would be good to have him on
the calls, so if that time works for everyone, perhaps we could move the
call time.
The dial-in information as well as minutes and audio logs of previous
meetings can be found here:
==========
Friday, February 10th, 2012
Time: 1700 UTC, 9am San Francisco, 12pm Boston, 5pm London
Digital Bazaar Telecon Bridge
SIP: pays...@digitalbazaar.com
Phone US: +1.540.961.4469 x6300
irc://freenode.net/#payswarm
Duration: 60 minutes
Scribes: Dave, Jeff, Manu
==========
Agenda
1. JSON-LD standardization updates
2. Web Payments 1.0
* http://payswarm.com/specs/ED/web-payments/2012-01-30/
3. Web Commerce 1.0
* http://payswarm.com/specs/ED/web-commerce/2012-01-30/
4. Payment Intents 1.0
* http://payswarm.com/specs/ED/payment-intents/2012-01-30/
5. Focus for next few months
-- manu
[1] http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0060.html
David Nicol
The PaySwarm spec has been split into three separate documents[1].
Well done! It is much clearer now.
I have noticed that the paragraph introducing JSON-LD is the same as the introductory paragraph at json-ld.org.
3.2 JavaScript Object Notation for Linking Data
JavaScript Object Notation for Linking Data [JSON-LD] is a lightweight Linked
Data format. It is easy for humans to read and write. It is easy for machines
to parse and generate. It is based on the already successful JSON format and
provides a way to help JSON data interoperate at Web-scale. If you are already
familiar with JSON, writing JSON-LD is very easy. There is a smooth migration
path from the JSON you use today, to the JSON-LD you will use in the future.
These properties make JSON-LD an ideal Linked Data interchange language for
JavaScript environments, Web services, and JSON document-based databases.
Aside from pointing out that data have no agency and thus cannot accept help, I don't want to criticize this paragraph in this forum, but instead offer a full replacement, as follows:
The wire-level format for data transmitted within Payswarm is JSON (Javascript Object Notation.) Invariant key/value pairs and key names have been selected to conform with JSON-LD, and a schema document parseable with JSON-LD tools has been registered with purl.org.
Manu Sporny
>> The PaySwarm spec has been split into three separate documents[1].
>
> Well done! It is much clearer now.
Glad to hear it. :)
> I have noticed that the paragraph introducing JSON-LD is the same as
> the introductory paragraph at json-ld.org <http://json-ld.org>.
>
> Aside from pointing out that data have no agency and thus cannot
> accept help
I'll try and come up with different wording...
> I don't want to criticize this paragraph in this forum
Perhaps the JSON-LD mailing list?
http://lists.w3.org/Archives/Public/public-linked-json/
> The wire-level format for data transmitted within Payswarm is JSON
> (Javascript Object Notation.) Invariant key/value pairs and key names
> have been selected to conform with JSON-LD, and a schema document
> parseable with JSON-LD tools has been registered with purl.org
> <http://purl.org>.
Hmmm, that's not quite what's going on here. I think Melvin is spot on
when he says that we haven't explained why we're using JSON-LD (and
Linked Data) well enough. We probably should have quite a bit more
reasoning, either in a spec or in a FAQ. To summarize, here are the
three main reasons we use JSON-LD:
* Web-native data model (IRIs as identifiers - good for the Web)
* Works with existing JSON tools (good for Web developers)
* Decentralized Extensibility (good for innovation)
JSON doesn't fit the first and last bullet point well. The other Linked
Data formats don't fit the second bullet point well.
JSON-LD uses IRIs for identifiers, which means that it supports
follow-your-nose (the ability to start at one document and discover
other resources by de-referencing links to other documents). This sort
of dereferencing is at the heart of decentralized systems and is used
extensively in the PaySwarm specs.
JSON-LD was designed to be compatible with the existing JSON toolchains
and layer on top of regular JSON documents if necessary. It was designed
to give Web developers access to Linked Data without requiring them to
learn a great deal about it. JSON-LD is basically the power of a
graph-based data structure, expressed as simple key-value pairs.
Since JSON-LD uses IRIs for object properties, you can expand the
functionality of a JSON-LD document without worrying about property name
clashes or if the system will accidentally use the term you use in the
future. JSON-LD provides a future-proof mechanism for expanding the
functionality of the objects used in PaySwarm (things like Assets,
Transfers, Transactions, Listings, and Contracts).
All of these come into play when you want to innovate on top of the
platform - it's just something that regular JSON does not do a very good
job at. Yes, you can quarantine a part of a JSON document off and state
that "any extensibility stuff goes here", but that's not a very elegant
solution. JSON-LD is elegant in that it allows you to extend the
document where it makes the most amount of sense for your application.
It allows innovation at the edges and if the innovation becomes
mainstream, it allows that innovation to be absorbed into the
standardized system without breaking backwards-compatibility with the
documents that are already out there.
At this point, you are either nodding your head in agreement, or you
don't think what I'm saying makes one bit of sense. In the latter case,
you may want to read the JSON-LD Requirements document:
http://json-ld.org/requirements/latest/
and the JSON-LD Syntax specification:
http://json-ld.org/spec/latest/json-ld-syntax/
I don't promise that those documents will shed any further light on the
situation... but they might help you understand the possibilities with
Linked Data vs. regular JSON.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/
David Nicol
(Javascript Object Notation.) Invariant key/value pairs and key names
have been selected to conform with JSON-LD, and a schema document
parseable with JSON-LD tools has been registered with purl.org
<http://purl.org>.
Hmmm, that's not quite what's going on here.
No? I didn't see anything in your response that contradicts my dispassionate summary.
the three main reasons we use JSON-LD [are]:
* Web-native data model (IRIs as identifiers - good for the Web)
* Works with existing JSON tools (good for Web developers)
* Decentralized Extensibility (good for innovation)
JSON doesn't fit the first and last bullet point well. The other Linked
Data formats don't fit the second bullet point well.
I'm not suggesting you stop any of that, or change the meat of the wire-level protocols you are proposing at all (not here, anyway. I reserve the right to make such suggestions in the future)
What I'm saying is, requiring your audience to drink the kool-aid is going to make a lot of them mosey towards the exits. By introducing JSON-LD as a given (it's JSON, and it's conformant with JSON-LD, which BY IMPLICATION is worth looking into, but that's not why I called this meeting) you can show instead of tell what makes JSON-LD the best thing since the convention of capitalizing abbreviations.
JSON-LD uses IRIs for identifiers, which means that it supports
follow-your-nose (the ability to start at one document and discover
other resources by de-referencing links to other documents). This sort
of dereferencing is at the heart of decentralized systems and is used
extensively in the PaySwarm specs.
That's great! So, tell us that PaySwarm uses IRIs for identifiers, which means that it supports follow-your-nose (the ability to start at one document and discover other resources by de-referencing links to other documents), and let us agree (or dispute) the coolness of that, okay? And if we think that's as cool as you think it is, we may want to set up other protocols the same way, and we'll come back to JSON-LD (As used in PaySwarm!)
JSON-LD was designed to be compatible with the existing JSON toolchains
and layer on top of regular JSON documents if necessary. It was designed
to give Web developers access to Linked Data without requiring them to
learn a great deal about it. JSON-LD is basically the power of a
graph-based data structure, expressed as simple key-value pairs.
That's nice. And irrelevant.
Since JSON-LD uses IRIs for object properties, you can expand the
functionality of a JSON-LD document without worrying about property name
clashes or if the system will accidentally use the term you use in the
future. JSON-LD provides a future-proof mechanism for expanding the
functionality of the objects used in PaySwarm (things like Assets,
Transfers, Transactions, Listings, and Contracts).
requiring facility for "expanding the functionality" of objects used in a payment infrasturcture is frightening. It's general, so you want to have the equivalent of pointer-to-void types in there for the things that can change, sure, but also the objects should be restricted to the things that make sense
All of these come into play when you want to innovate on top of the
platform - it's just something that regular JSON does not do a very good
job at.
and that's why you're using JSON-LD. Show, don't tell (he tells.)
Yes, you can quarantine a part of a JSON document off and state
that "any extensibility stuff goes here", but that's not a very elegant
solution. JSON-LD is elegant in that it allows you to extend the
document where it makes the most amount of sense for your application.
so if I write an application to rip someone off, I can extend the document in ways that will make sense for me to do that? I can extend the document in ways that allow XSS attacks? I can extend the document to cause distributed denial of service attacks against my hapless victim who suddenly has to field a billion requests for a nonexistent context definition?
It allows innovation at the edges and if the innovation becomes
mainstream, it allows that innovation to be absorbed into the
standardized system without breaking backwards-compatibility with the
documents that are already out there.
At this point, you are either nodding your head in agreement, or you
don't think what I'm saying makes one bit of sense. In the latter case,
no, neither. And furthermore, I do not wish to join the church of JSON-LD at this time.
David Nicol
The wire-level format for data transmitted within Payswarm is JSON (Javascript Object Notation.) Invariant key/value pairs and key names have been selected to conform with JSON-LD, and a schema document parseable with JSON-LD tools has been registered with purl.org.
--
on the outside of the bottom of the barrel, that's how much of an outlier it is.
Melvin Carvalho
>
>
> On Wed, Feb 8, 2012 at 10:55 PM, David Nicol <david...@gmail.com> wrote:
>>
>> The wire-level format for data transmitted within Payswarm is JSON
>> (Javascript Object Notation.) Invariant key/value pairs and key names have
>> been selected to conform with JSON-LD, and a schema document parseable with
>> JSON-LD tools has been registered with purl.org.
>
> Melvin Carvalho has proposed that the word meaning "within the context of
> this protocol, these strings are always present, like this, exactly" might
> be changed from "invariant" to either "universal" or "uniform."
On reviewing the normative document on Web Architecture
I think perhaps the best language to use is in section 2.1 "Benefits
of Using URIs" [in this case as keys]
"The choice of syntax for global identifiers is somewhat arbitrary; it
is their global scope that is important."
So what we would like to convey in the sentence is that the keys have
global scope.
The web arch document goes into great detail about the advantages of
this, and how it lead to the WWW. One immediate advantage I can see
is to make the key terms non colliding between different systems and
another is that they can be (and in this case are) self documenting.
Manu Sporny
We have a Web Payments telecon coming up on this Friday.
We will probably spend a good bit of the telecon going through the newly
released PaySwarm demo and answering any questions that people may have
about it. I was supposed to send out a doodle poll on what times work
for everyone, but I failed to do that, so let's try for 4pm again.
Pelle, would you be able to make this time again? (I know you said that
it won't work for you once you're back in Miami)
The dial-in information as well as minutes and audio logs of previous
meetings can be found here:
==========
Friday, February 24th, 2012
Time: 2100 UTC, 1pm San Francisco, 4pm Boston, 9pm London
Digital Bazaar Telecon Bridge
SIP: pays...@digitalbazaar.com
Phone US: +1.540.961.4469 x6300
irc://freenode.net/#payswarm
Duration: 60 minutes
Scribes: Jeff, Manu, Dave
==========
Agenda
1. PaySwarm Reference Implementation
* https://dev.payswarm.com/
2. Payment Intents 1.0
* http://payswarm.com/specs/ED/payment-intents/2012-01-30/
3. Focus for next few months
* Implementation focus
* Spec work focus
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/