W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2011

The PaySwarm Ecosystem

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 01 Dec 2011 00:43:22 -0500
Message-ID: <4ED713FA.90806@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
Hi folks,

We've been hacking away at Digital Bazaar on PaySwarm for quite a while
now and have not been as good as we should be with messaging progress
that is being made. Part of this problem stems with the huge amount of
work that needs to be done to standardize the bits that are used for
PaySwarm. These technologies include:

* RDFa
* Graph Normalization
* Secure Messaging over HTTP
* Web Payments Vocabularies
* Web Payments API

Only the last two bullet points above are being worked on in this
Community Group. I think the reason for our poor messaging is due to the
massive workload we've been under for the past several years getting the
bits and pieces working (RDFa, JSON-LD, Graph Normalization, etc.).

Many of these technologies may be foreign to a number of folks on this
mailing list, so I thought I'd put together an e-mail detailing why
we're working on each technology for the Web Payments work.



In order to create a decentralized payment system, you have to figure
out a way to list assets for sale on the Web in a decentralized manner.
We don't want any sort of centralized database that requires
registration for listing items for sale. We also want people to be able
to list items for sale in a regular Web page, and have a machine come
along and read the listing information easily. RDFa allows you to
express things on a page so that they are both human-readable and
machine-readable. With RDFa, you can have text that says "This image is
for sale by Jeff for $1.", and have a machine understand exactly what is
for sale, for how much it's for sale, and where to send the money when
the purchase is performed.



Since all of the systems in PaySwarm are meant to be decentralized, they
need to talk with one another, but in a way that is fairly natural to
most Web programmers today. Many programmers love JSON - it's compact,
human readable, and maps really nicely into most programming languages.

The one problem with JSON, is that the JSON objects don't really work at
Web-scale - they don't use URLs to identify other JSON objects and the
keys that they use are ambiguous. That is, if one object has a key that
says "title" and another object has a key that says "title", you have no
idea if both objects are talking about the title of a book, or a job
title. JSON-LD, which stands for JSON for Linking Data, uses URLs and
thus you can link JSON-LD objects with one another. It also allows for
unambiguous key names, so you know if an object is talking about the
title of a book or a job title.

Ultimately, JSON-LD allows us to be specific about what we're talking
about, but extensible at the same time. This is important for PaySwarm
because we need to be able to talk about digital contracts and licenses
(which need to be specific and unambiguous), but also allow people to
innovate on top of those digital contracts and licenses (which requires
great extensibility and flexibility).

Graph Normalization


In order to ensure that a decentralized financial system is secure, you
have to digitally sign transactions on the network. We express assets
and listings on the PaySwarm network as a graph of information (in the
mathematical sense). You can express the same information in multiple
different ways with a graph. Since this is true, we need an algorithm
for normalizing that graph into a particular layout because we need
every decentralized system in PaySwarm to be able to create the same
digital signature from a graph containing the information (regardless of
the layout of the graph).

This is a really hard Computer Science problem, but we believe that
we've cracked it and have a spec outlining how to implement generic
graph normalization. This is good news, because without this technology,
we couldn't do digital signatures on on assets, listings and digital
contracts on PaySwarm.

Secure Messaging over HTTP


Financial systems need to transmit messages that are secure because
those messages contain things like what you're buying, how much you're
paying for it, and other personal information that you don't want to
leak out to the Internet.

We could secure all communication on the network by requiring that all
participants in the network purchase an SSL security certificate. These
certificates typically average around $30 USD per year (sure, it's $12
the first year, but that's how the Certificate Authorities hook you).
However, we want to do better than that. We want the entry fee into
PaySwarm to be $0 for vendors. This is doubly important for people in
developing nations, where $30 could be an entire month's salary.

We've created an asynchronous security mechanism in PaySwarm that allows
vendors that are just getting started to not have to pay a dime for a
level of protection that is adequate for small sites, while also
ensuring that a large site can utilize HTTPS if they want the added

PaySwarm Vocabularies


In order to express assets, listings and digital contracts in RDFa and
JSON-LD, you have to specify a vocabulary, which is basically a list of
all terms that you're going to use when marking up machine-readable data
on a page. This ensures that all of the data in the decentralized system
is identified using an unambiguous set of terminology.

PaySwarm Web API


The PaySwarm Web API puts all of the technologies listed above together
into a cohesive system for performing payments on the Web. The PaySwarm
Web API enables a decentralized system of financial nodes that are
capable of transferring money between each other using an open protocol
over an open network. It also enables the listing of assets for sale,
and the execution of digital contracts (receipts of sale) that can be
used for a variety of purposes (proof of purchase, proof of ownership,
VIP access, etc.)

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Need for Data-Driven Standards
Received on Thursday, 1 December 2011 05:43:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC