Re: Web Credits Writeup

[Pelle Braendgaard]

Great simple spec.

I realize that this was based on PaySwarm and not OpenTransact. But with a couple of parameter name changes it would be OpenTransact compliant. Also I'd suggest you have a URL form encode option to make it simple to integrate with web forms.

BTW I love the Tim Berners-Lee quote on the page, which is exactly we have made the design choices we have made in OpenTransact:

"The way the Web spread was a piece at a time. So you could take html without taking http. So the failure of NEXT was a lesson, don’t try to sell it all at one time. Sell each piece on its own merits. Never insist that everybody take all. They will take all the pieces once they see how it fits together."

P

On Fri, Jan 20, 2012 at 4:47 PM, Melvin Carvalho <melvinc...@gmail.com> wrote:

Here's a quick writeup of what I previously posted as the opentabs
protocol.  I've codenamed it 'Web Credits' for now and put it on the
wiki.

Introduction
==========

Web Credits is an ultra simple system for storing and transferring
IOUs (credits) between agents.

*The aim of this spec is not to exceed 2 pages*, be usable to create
distributed payments, and arbitrarily extensible to add encryption,
workflow, trust and aggregation systems of your chosing.

95%+ of the money in the world is in the form of an IOU. A bank
balance is an IOU from the bank to you, Cash is often an IOU from a
govt. to an individual.

The protocol is inspired by the Linked Data and PaySwarm standards,
and is a usable subset that focuses on the data layer (JSON) and
communication to apps (HTTP).

[Read More]

http://webcredits.org/

--
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking

[Melvin Carvalho]

On 24 January 2012 16:22, Pelle Braendgaard <pe...@stakeventures.com> wrote:
> Great simple spec.
>
> I realize that this was based on PaySwarm and not OpenTransact. But with a
> couple of parameter name changes it would be OpenTransact compliant. Also
> I'd suggest you have a URL form encode option to make it simple to integrate
> with web forms.

I'd be very happy to try and make the base layer both payswarm and
opentransact compliant.

Could you give an example of how you think this could be done.

Do you mean a translation service that takes an HTTP GET + OAuth token
and transforms it to a POST and preserves the token?

[Pelle Braendgaard]

In OpenTransact we use to/from instead of source/destination as it's more concise seems more human like, is similar to SMTP and matches what is used in many different implementations of proprietary APIs.

It's simple of course to support both is to just check for both. I'd like to see OpenTransact as being the lower level payment layer for PaySwarm. 

The Transfer Request and Transfer parts of the spec would be very simple for you to implement:

http://www.opentransact.org/core.html#transfer-request-1

On Get you would just pre populate the payment fields in your existing payment form with the parameters from the query string.

The transfer should also be fairly simple as long as you support the OAuth 2 bearer spec:

http://www.opentransact.org/core.html#transfer-1

Just accept the parameters as URL form encoded form as well and it is pretty much OpenTransact compliant.

Transfer Authorizations are fairly simple to implement as long as you can create an OAuth token within your implementation that has some sort of way of specifying scope. eg. amount, from, to etc.

OAuth 2 is pretty lightweight to implement. You could implement it from scratch in a json store by storing transfer json objects with an extra expiry field and a unique token which would act as the access token. Store this in the "authorization" store in your json store.

In the POST to the wallet URL you would see if there is a bearer token in the authorization header and look up the json in the authorization store using the token.

An empty post would by default use all the parameters stored in the original authorization and delete it from the authorization store.

POST parameters could be used to modify certain aspects of the original authorized parameters within business rules in the spec. Such as change the amount to $8 instead of the authorized $10.

Sorry if this was rambling, it was just a quick brain dump.

P

[Melvin Carvalho]

On 24 January 2012 16:22, Pelle Braendgaard <pe...@stakeventures.com> wrote:

> Great simple spec.
>
> I realize that this was based on PaySwarm and not OpenTransact. But with a
> couple of parameter name changes it would be OpenTransact compliant. Also
> I'd suggest you have a URL form encode option to make it simple to integrate
> with web forms.
>
> BTW I love the Tim Berners-Lee quote on the page, which is exactly we have
> made the design choices we have made in OpenTransact:
>
> "The way the Web spread was a piece at a time. So you could take html
> without taking http. So the failure of NEXT was a lesson, don’t try to sell
> it all at one time. Sell each piece on its own merits. Never insist that
> everybody take all. They will take all the pieces once they see how it fits
> together."

The prototype of the first app should be available here:

http://opentabs.data.fm/

Please be aware that it's still alpha-ish code

[Manu Sporny]

On 02/08/2012 02:54 AM, Melvin Carvalho wrote:
> The prototype of the first app should be available here:
>
> http://opentabs.data.fm/
>
> Please be aware that it's still alpha-ish code

Melvin - neat demo. :)

I tried out all of the functionality on the page. Seems to work for me
for the most part. I've created an IOU - now what can I do with it? Is
there any way to sync IOUs between participants?

Looking at the javascript, it seems as if I should be able to retrieve
your IOUs to me?

var walletURIs = this.getWalletURIs(this.user);

Could I register a payment IRI for me with your OpenTabs server? So,
whenever you enter an IOU for me, it could go to my OpenTabs server and
give you my public payment details? I'm trying to figure out how
discovery works.

It might be good if you had some way of demonstrating the distributed
nature of the solution. That is, show the person how entering an IOU for
someone on the page results in the IOU appearing on some other page on
the Web... or, have some application that makes the Test Dummy create an
IOU for the person using the demo.

Looks good so far... :)

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

[Melvin Carvalho]

On 8 February 2012 11:02, Manu Sporny <msp...@digitalbazaar.com> wrote:
> On 02/08/2012 02:54 AM, Melvin Carvalho wrote:
>>
>> The prototype of the first app should be available here:
>>
>> http://opentabs.data.fm/
>>
>> Please be aware that it's still alpha-ish code
>
>
> Melvin - neat demo. :)
>
> I tried out all of the functionality on the page. Seems to work for me
> for the most part. I've created an IOU - now what can I do with it? Is
> there any way to sync IOUs between participants?

Sync should happen behind the scenes in this case.

Clearing, ripple, escrow are interesting workflows that I'd love to
explore. The first cut is just a record keeping system, but hopefully
useful in itself.

>
> Looking at the javascript, it seems as if I should be able to retrieve
> your IOUs to me?
>
> var walletURIs = this.getWalletURIs(this.user);
>

Each user has one or more wallets. I've implemented a very basic
algorithm to find wallets in a well known location. But ultimately
the user will decide where they want to keep their wallets.

> Could I register a payment IRI for me with your OpenTabs server? So,
> whenever you enter an IOU for me, it could go to my OpenTabs server and
> give you my public payment details? I'm trying to figure out how
> discovery works.

Discovery will basically work according to the "Open World Assumption".

The app will initiate a probe sequence based on what it knows to find
user preferences.

After authentication the app knows a little about:
The environment it runs in
The authenticated user
The project home page

From this information the app has to intelligently 'query the web' to
find out more about the user. So webfinger, linked data, well known
registries and default fallbacks are the strategy.

Ultimately the user should have complete control.

>
> It might be good if you had some way of demonstrating the distributed
> nature of the solution. That is, show the person how entering an IOU for
> someone on the page results in the IOU appearing on some other page on
> the Web... or, have some application that makes the Test Dummy create an
> IOU for the person using the demo.

If you log in with the counter party that you sent money to, you'll
see the credit in their account. This can be done, for example, with
browserid.

Hopefully more demos, screencasts, docs coming soon ...

>
> Looks good so far... :)

Thanks! :)

[David Nicol]

I like it. You've got to,from,currency,amount,message,a timestamp,
I'm looking at the "storage" section which describes a JSON-LD data template.

When currency is a ISO currency identifier, who backs it? Allowing those implies a settlements system

Also, "storage" is an implementation detail. I'm understanding this section to be misnamed, as it is about what the transfer looks like on the wire. A section title like "JSON-LD Field Names" or whatever the right term from JSON-LD jargon is would be better.

The ID could be explained better. Is it supposed to be unique? Is it how one looks up a transfer? To get the URL for a transfer do I append the ID to the "context" or what? If all the fields are predictable, a hash of the transfer in wire format is not secure.

what is the "context" for? ... oh, that's a JSON-LD thing
http://json-ld.org/spec/latest/json-ld-syntax/#syntax-tokens-and-keywords like "xmlns" in XML. I don't think the -LD stuff is needed at all here: it complicates things for no gain.

It could use  "originator" and "originator-ID" fields, which whoever originates this transfer object is responsible for filling in, also a "status" field about if this transfer is proposed/rejected/approved/completed, there are other statuses that are probably needed when using ISO currencies to handle the various states between approval and completion.

Various expiration-date fields could be added to answer, how long does it persist without getting approved, or without getting completed, and how long will it be available for access after it has been completed, if it is going to get archived where will it be archived to and how long will it be retained? a callback URL for rejection, or expiration events, either a separate URL for each possible event or another little language for use in the callbacks


those are some things it seems like its missing.

[Melvin Carvalho]

On 8 February 2012 20:44, David Nicol <david...@gmail.com> wrote:
>
> I like it. You've got to,from,currency,amount,message,a timestamp,
> I'm looking at the "storage" section which describes a JSON-LD data
> template.

Thanks

>
> When currency is a ISO currency identifier, who backs it? Allowing those
> implies a settlements system

ISO currencies are normally govt. issued. The base spec does not have
a specific settlement system. But one could be built on top. I'm
thinking about a ripple integration.

>
> Also, "storage" is an implementation detail. I'm understanding this section
> to be misnamed, as it is about what the transfer looks like on the wire. A
> section title like "JSON-LD Field Names" or whatever the right term from
> JSON-LD jargon is would be better.

they are just key value pairs, sometimes called attribute / value,
sometimes called predicate / object

The storage data structure here is exactly the same as the message
structure, which I think is quite neat. You store an IOU, you send
someone an IOU. Summed IOUs give a balance. A bit like online
banking.

>
> The ID could be explained better. Is it supposed to be unique? Is it how one
> looks up a transfer? To get the URL for a transfer do I append the ID to the
> "context" or what? If all the fields are predictable, a hash of the transfer
> in wire format is not secure.

Yes, agree, that can be fleshed out. The ID is actually optional, but
having a globally unique identifier is one of the foundational
principles of the web It allows namespaces and non colliding data
points.

So a web page is a document, inside a document can be data points.
You normally describe it as:

example.com/doc#dataID ... the data ID here is just a unique sha1 sum
... it means it can be used in a foreign key for other workflows etc.

>
> what is the "context" for? ... oh, that's a JSON-LD thing
> http://json-ld.org/spec/latest/json-ld-syntax/#syntax-tokens-and-keywords
> like "xmlns" in XML. I don't think the -LD stuff is needed at all here: it
> complicates things for no gain.

This is to make things globally unique and non colliding terms.
There's a few other benefits but those are the initial ones. Imagine
if everyone came up with their own terms and everyone had a spec it
would be kind of chaotic. The Linked Data part allows web scale
interoperability.

In a way it is the magic sauce.

>
> It could use  "originator" and "originator-ID" fields, which whoever
> originates this transfer object is responsible for filling in, also a
> "status" field about if this transfer is
> proposed/rejected/approved/completed, there are other statuses that are
> probably needed when using ISO currencies to handle the various states
> between approval and completion.

I thought long and hard about adding state to the object, having
talked to matt slater. This is the one field they have in LETS that
web credits doesnt have.

I decided not to complicate the core data with this field.

It's perfectly possible to extend the model in JSON to use status
either as member field or to reference this object as a foreign key.
I prefer the foreign key approach in order to keep the base structure
clean and analogous to network theory topology.

>
> Various expiration-date fields could be added to answer, how long does it
> persist without getting approved, or without getting completed, and how long
> will it be available for access after it has been completed, if it is going
> to get archived where will it be archived to and how long will it be
> retained? a callback URL for rejection, or expiration events, either a
> separate URL for each possible event or another little language for use in
> the callbacks

The next thing to extend is workflows based on the base structure.

Just like in an SQL database one table does not rule them all, but you
an have a base table and build others up around it as they become
needed. This is also the essence of the web as a giant database.

Finance can explode in complexity quite fast so I thought it would be
an idea to build the smallest useful building block I could imagine,
and demonstrate how it could be used etc.

Hope that helps!