-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathPROTOCOL
136 lines (93 loc) · 3.5 KB
/
PROTOCOL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
Opentabs PROTOCOL
==================
Opentabs follows the Web Credits Draft spec proposed at the W3C
Web Payments group.
http://webcredits.org/
User
====
Each user is a URI. URIs link to other URIs using linked data
principles, including Webfinger discovery, and web Intents.
Authentication
==============
Opentabs does not specify the authentication method, but so far WebID,
Oauth2 (Gmail/Yahoo) and Facebook connect are supported. We are keen
to support BrowserID, more can be added on request.
Linking a User to IOUs
=======================
This is to be defined so that a user can have one or more spaces for
storing IOUs.
<#me> opentabs:IOUs <target>
Currently for the alpha test we are storing <target> in a well known
location on the MIT data.fm server. As things scale to beta and full
production distributing the storage will be a key consideration. It
is a project goal to port the system to be usable with the unhosted
infrastructure.
IOU
===
We use the following template based on the payswarm Transfer type.
source (aka payer)
destination (aka payee)
amount (aka quantity)
currency
comment (aka note / description)
created (aka createddate)
Each IOU is a self describing data structure, general with global
namespaces to enable a scale free system.
In JSON:
{
"@id": "#1234567890",
"http://payswarm.com/vocabs/commerce#source": {
"@id": "http://melvincarvalho.com#me"
},
"http://payswarm.com/vocabs/commerce#destination": {
"@id": "http://webr3.org/nathan#me"
},
"http://payswarm.com/vocabs/commerce#amount": "5",
"http://payswarm.com/vocabs/commerce#currency": "EUR",
"http://www.w3.org/2000/01/rdf-schema#comment": "Just a test IOU",
"http://purl.org/dc/terms/created": "2011-12-20T15:42:41.030Z",
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type": {
"@id": "http://payswarm.com/vocabs/commerce#Transfer"
}
}
In Turtle
<#1234567890>
<http://payswarm.com/vocabs/commerce#amount> "5";
<http://payswarm.com/vocabs/commerce#currency> "EUR";
<http://payswarm.com/vocabs/commerce#destination>
<http://webr3.org/nathan#me>;
<http://payswarm.com/vocabs/commerce#source> <http://melvincarvalho.com#me>;
<http://purl.org/dc/terms/created> "2011-12-20T15:42:41.030Z";
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://payswarm.com/vocabs/commerce#Transfer>;
<http://www.w3.org/2000/01/rdf-schema#comment> "Just a test IOU".
Experiment in the JSON playground
http://is.gd/Km1iOA
The abstract nature of this data structure makes it both extensible,
linkable and transformable to other formats.
Aggregation
===========
It is the job of the front end to aggregate, net and display IOUs to the user.
Friends
=======
For convenience we currently try and pull in a list of friends to
populate the payee dropdown. New recipients can be added and are
cached.
Workflow
========
Currently we have only the most basic workflow for adding an IOU.
Without doubt there will be more added, but our aim is to decouple the
data layer with the application logic so that arbitrarily many
workflows are possible working with the same data stores.
A Basic Example
================
Alice wants to give bob 5 euros
Alice authenticates
The app discovers where alices wallet is
Alice takes 5 euro out of her wallet (by adding the JSON)
Alice gives 5 euros to bob (by giving him the JSON)
Bob puts 5 euros in his wallet using a POST the JSON
Encryption
==========
Currently we have not included encryption and signature for the alpha,
but it is on the roadmap.