Web Credits Writeup
Melvin Carvalho
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]
Jorge Timón
Cryptography is needed at the lowest level of the protocol.
http URLs don't seem secure for identifying senders or receivers.
https has its flaws too. Look at this discussion on the bitcoin
development list where https was questioned to be used for an aliases
standard:
http://www.mail-archive.com/bitcoin-d...@lists.sourceforge.net/msg00419.html
2012/1/21, Melvin Carvalho <melvinc...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To post to this group, send email to rippl...@googlegroups.com.
> To unsubscribe from this group, send email to
> rippleusers...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rippleusers?hl=en.
>
>
--
Jorge Timón
Melvin Carvalho
> I don't think it's a good idea to make this at the web level.
It's aimed at the Web. The rationale for this is that The Web has
been a proven medium for scalable uptake and viral growth.
> Cryptography is needed at the lowest level of the protocol.
Why is that? Crypto is intentionally out of scope of the doc, as
there are so many ways to do it. But can be layered on top, if
desired.
> http URLs don't seem secure for identifying senders or receivers.
Any system that involves human beings is not secure. You will never
achieve perfection, only try and increase the confidence interval.
> https has its flaws too. Look at this discussion on the bitcoin
> development list where https was questioned to be used for an aliases
> standard:
>
> http://www.mail-archive.com/bitcoin-d...@lists.sourceforge.net/msg00419.html
Not sure of the specific objection here, but I'm also working with
Amir (the author of that spec) both on the bitcoin URI scheme and Web
Credits.
I sympathize with your point that you want to make something rock
solid secure. However you have to start somewhere and as things get
adopted security can be tightened. Just think facebook got to several
hundred million users before turning on https ...
Jorge Timón
protocol that actually abstracts the communication layer instead of
the security. That's why I thought crypto must be the base and the
other things layered on top of it. Maybe both can be made compatible.
Maybe my proposal has a big flaw I don't see.
If you want to take a look, I've posted a draft on the bitcoin forum:
https://bitcointalk.org/index.php?topic=60591.0
Criticism is welcomed.
2012/1/21, Melvin Carvalho <melvinc...@gmail.com>:
Melvin Carvalho
> Well, maybe you're right. I've just been thinking in a cryptographic
> protocol that actually abstracts the communication layer instead of
> the security. That's why I thought crypto must be the base and the
> other things layered on top of it. Maybe both can be made compatible.
>
> Maybe my proposal has a big flaw I don't see.
> If you want to take a look, I've posted a draft on the bitcoin forum:
>
> https://bitcointalk.org/index.php?topic=60591.0
Looks good, in general the way to translate something P2P to be also
scalable to the web is to use "URIs" as identifiers and "linked data"
principles.
http://en.wikipedia.org/wiki/Linked_data
Miles Thompson
That looks really nice. I like the way it looks.
If you are well aware of these efforts already, what would you say is the big difference in approach or functionality to web credits? Or are they just different efforts in the same space for you but you prefer webcredit because..?
Miles
PS Prowl
--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To post to this group, send email to rippl...@googlegroups.com.
To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.
Melvin Carvalho
> Melvin,
>
> That looks really nice. I like the way it looks.
>
> I definitely don't want to state the overly obvious but on the other hand
> wanted to be sure you were aware of opentransact, payswarm and the recent
> discussion about creating a new w3c web payments standard..
>
> Not sure the best thing to link to but figure this might be a good starting
> point:
>
> http://stakeventures.com/articles/2011/12/21/opentransact-the-payment-standard-where-everything-is-out-of-scope
>
> Along with:
> http://www.opentransact.org/
>
> and
> http://payswarm.com/
>
> Personally I'm a big favor of open transact approach - which like web
> credits concentrates on defining a spec just for the minimum bits required.
> Or something.
Sure I talk to pelle and manu about these things. Also fellow
traveler (opentransactions), Amir (bitcoin), Matt slater (LETS) for
feedback.
Generally the response has been positive, tho I could do a better job
explaining general concepts, I think.
>
> --
>
> If you are well aware of these efforts already, what would you say is the
> big difference in approach or functionality to web credits? Or are they just
> different efforts in the same space for you but you prefer webcredit
> because..?
Payswarm is a big project 7 years of work and covers a lot of use cases.
Web Credits is a smaller spec (perhaps a subset) aimed at the data
layer, just for credits, and with a 'universal' HTTP interface. It's
the most minimal subset I could think of to get up and running with
proof of concepts (which will be released under open source shortly).
I havent covered opentransact in detail, but I'm generally favourable
to it. It deals more with the connection between app and data. I
leave that part open. So it's a bit like building a modular system
out of lego blocks.
One thing that turned a lot of lights on in my head was 2 years ago a
conference call with Tim Berners-Lee. He talked about the danger of
'walled gardens' hiding their data on the web and the advantages of
open data. He next praised APIs for exposing data. However the next
thing both surprised and intrigued me:
"However APIs are poor, because in general they hide data under their
interface. The most flexible way to do things is to expose the data
layer under the universal interface of HTTP, so that it can be used in
interesting and unexpected ways". (Law of unintended consequences)
It's under these principles that I've tried to make a simple Web Scale
building block to put together apps.
Sorry I'm not great at explaining these principles, but hope that makes sense!
Miles Thompson
Melvin Carvalho
> Awesome. In that case please accept my apologies for stating the obvious.
>
> So, why did you feel there was a need for another standard spec?
It's the iterative approach (I got approval from the payswarm folks).
Do something relatively simple, get it working. Use it to build real
world things, in order to see how robust it is, or any gaps. Once
that section of the spec is solid and working, use it as a foundation
for further standardization.
One other quote from timbl seems to suggest the advantage of doing
things in simple pieces:
"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."
Apostolis Xekoukoulotakis
Sincerely yours,
Apostolis Xekoukoulotakis
Melvin Carvalho
> Sorry If I dont know a lot about your projects and their differences but
> isnt metacurrency having http and HTML as a paradigm?
Looks like a great project, would be cool to have these guys in the
conversation.
Biggest difference I can see is that they want to use MCP as an
alternative to HTTP
Mark Shuttlworth wrote an interesting piece on the advantages of reusing HTTP:
"Lessons from HTTP"
http://www.markshuttleworth.com/archives/765
Michiel de Jong
relation between webcredits and ripple:
---------
ripple doesn't specify the destination, only the source. this means that the IOU becomes cashable by the bearer, even if that's not the original recipient (destination) and thus tradeable. when representing a debt between two people it seems obvious to include the names of both people, because both are essential parts of what we're describing, and that information is available anyway. also, specifying the destination allows us to publish the document without fear of anybody stealing it. after all, the owner's name is on there, and can/will be checked before cashing. but on the other hand, if you keep the signed IOU secret, then from the fact you are giving it to the recipient, the destination field can be implicit, which would make webcredits compatible with ripple.
another way of looking at it is that ripple can provide the "currency" field of an IOU. if people have already established ripple currencies, then those can be used as the unit of measure in a webcredit. in a way, even if i say 'dollars' as the currency, for you that means 'dollars from Michiel'. the source always puts their stamp on the currency i think, because to understand what the document means, you have to ask what the author meant. then, you can know whether i meant Australian dollars or American dollars, and pin it to a universally unique meaning. but the default currency of an IOU is always in the first place what the issuer meant to say by it. so even if you don't want to use bearer-cashable IOUs (which would mean you pretty much are outside the scope of ripple), you can still refer to existing ripple currencies. as the alternative currency on your IOU.
relation between webcredits and OpenTransact
-----
one is static (like html), the other is dynamic (like http). so they don't bite each other. it would be sensible to describe the mapping between OpenTransact events and the IOUs they result in. the IOU in OpenTransact is the token that is issued at the end. everything up to that point is just the haggling that preceeds the agreement.
Webcredits are useful because you can sign and publish them, and they can be checked by a third party. Imagine you do an OpenTransact transaction, and there's a bit of delay between the transfer authorization and the transfer or whatever, and at the end when the recipient comes knocking on the payment service's door with the Transfer POST, the payment service claims they've never seen that Bearer token. what can the recipient then do against that? nothing. blacklist the payment service, write an angry blogpost about the dispute, and accept that they just lost X dollars to a crook - or maybe it wasn't even a crook, and there was some other misunderstanding going on. the point is, the Bearer token gives you nothing in the case the payment service disputes its validity.
with PGP-signed Webcredits, if a payment service refuses to pay, you have a signed document which independent judges can verify. that's also why i would like the signing payload to include the cumulative balance. "i owe you 10 dollars for the milk, meaning i now owe you 23 dollars in total". either that, or a way to link to an IOU in a settlement document. "regardless of what else i may still owe you, that 10 dollars for the milk, reference #1234567890, has hereby been settled". or maybe both, so you can habe IOUs as described by webcredits, and then settlement statements that give a list of IOUs that it voids, and creates one new IOU stating the new balance.
relation between webcredits and payswarm
-----
PaySwarm, as i understand it, is a bit like OpenID for credit card processors. A user has a PaySwarm authority where they enter their credit card once, and then can easily pay on websites that accept PaySwarm payments. i agree this is a much needed technology on the web. but afaics it doesn't deal with IOUs - it leaves that part to existing credit card companies. in any case, when you use PaySwarm (as i understand it), you have a PaySwarm authority that vows for you. that authority could give out micropayments in webcredits from the PaySwarm authority to the recipient website. the recipient website could then redeem those IOUs later and convert them to real creditcard payments. it seems like this is not really useful though.
so i would say, if you are going to put your creditcard number into something, then use payswarm and not webcredits. if you are not going to do that, then use webcredits and not payswarm. but i might have overlooked some different mode of operation here?
cheers,
Michiel
Miles Thompson
Apostolis Xekoukoulotakis
Melvin Carvalho
> Ripple is very different from the others as it doesnt require a legal
> authority to function.
>
> The difference between the others is on the way a currency is authenticated
> so that is better defended in court if need be, right?
Web Credits keeps the currency authentication out of scope. You can
pick which one you want or not have any. At it's base it's just a
record keeping system between agents.
I'm also hoping it can be integrated with ripple at some point. That
will be a case of mapping identifiers to each other.
els
from the beginnings and design of the Web. Not sure of the Semantic
Web future, though, but I digress.
Second, I developed the Inter-Entity Payment Protocol (IPP) to suit
the particular requirements of an alternative currency system that I'm
working on. I explain my thinking, and provide links to demos, in
http://groups.google.com/group/opentransact/browse_thread/thread/dce378fc6ed7b1a6.
Here are comparisons, if I understood Web Credits correctly:
- Like Web Credits, IPP does not require a particular authentication/
verification scheme. It also uses URIs to specify payment endpoints
for discovery as well as record-keeping purposes.
- Unlike Web Credits, discovery and the general payment dynamics are
within scope of IPP. By payment dynamics, I mean payment states and
stages, as well as IPP-specific error codes, are defined by the
protocol. The idea is for the protocol to impose simple expectations
to guide orthogonal development and to encourage uniform user
experience.
Lastly, just a comment that I found using JSON to be much easier than
XML, and that JSON-LD seems to be a really good 'extension' of it in
that it doesn't attempt to do too much.
On Jan 22, 6:03 am, Melvin Carvalho <melvincarva...@gmail.com> wrote:
>
> > Ripple is very different from the others as it doesnt require a legal
> > authority to function.
>
> > The difference between the others is on the way a currency is authenticated
> > so that is better defended in court if need be, right?
>
> Web Credits keeps the currency authentication out of scope. You can
> pick which one you want or not have any. At it's base it's just a
> record keeping system between agents.
>
> I'm also hoping it can be integrated with ripple at some point. That
> will be a case of mapping identifiers to each other.
>
>
>
>
>
>
>
>
>
> > 2012/1/22 Miles Thompson <utu...@gmail.com>
>
> >> OK wow. I get it. Sorry for being a bit dense.
>
> >> So .. to summarize so brutally as to get it wrong something like:
>
> >> ripple = management of debts (on a directed graph)
> >> webcredits = statements of debts (between two parties)
> >> open transact = payment transactions (against arbitrary assets)
> >> pay swarm = payment transactions (with more of a main stream focus)
>
> >> ?
>
> >> Miles
>
>
> >>>> On 22 January 2012 00:02, Apostolis Xekoukoulotakis <xekou...@gmail.com>
>
> read more »
elf Pavlik
> On 22 January 2012 00:02, Apostolis Xekoukoulotakis <xeko...@gmail.com> wrote:
> > Sorry If I dont know a lot about your projects and their differences but
> > isnt metacurrency having http and HTML as a paradigm?
>
> Looks like a great project, would be cool to have these guys in the
> conversation.
Last days I just got chance to meet in person Arthur Brock from Metacurrency, you can find some of his presentations here:
http://prezi.com/user/qaco0pb4fhws/
He visits Berlin and should stay here for 2-3 more days, just today we had a bike ride and I let myself bug him about trying to take advantage of all the work already done in realm of Linked Data =)
If you like we could maybe arrange a online call tomorrow and touch down base on those topics?
=)
~ elf Pavlik ~
--
(living strictly moneyless already for over 2 years)
http://wwelves.org/perpetual-tripper
http://moneyless.info
http://hackers4peace.net
Melvin Carvalho
> Excerpts from Melvin Carvalho's message of 2012-01-21 23:19:01 +0000:
>> On 22 January 2012 00:02, Apostolis Xekoukoulotakis <xeko...@gmail.com> wrote:
>> > Sorry If I dont know a lot about your projects and their differences but
>> > isnt metacurrency having http and HTML as a paradigm?
>>
>> Looks like a great project, would be cool to have these guys in the
>> conversation.
> Hi Melvin,
>
> Last days I just got chance to meet in person Arthur Brock from Metacurrency, you can find some of his presentations here:
> http://prezi.com/user/qaco0pb4fhws/
>
> He visits Berlin and should stay here for 2-3 more days, just today we had a bike ride and I let myself bug him about trying to take advantage of all the work already done in realm of Linked Data =)
>
> If you like we could maybe arrange a online call tomorrow and touch down base on those topics?
Sounds great!
Let's touch base on chat, and see if we can line something informal up ... :)
Melvin Carvalho
> OK wow. I get it. Sorry for being a bit dense.
>
> So .. to summarize so brutally as to get it wrong something like:
>
> ripple = management of debts (on a directed graph)
> webcredits = statements of debts (between two parties)
> open transact = payment transactions (against arbitrary assets)
> pay swarm = payment transactions (with more of a main stream focus)
The prototype of the first app should be available here:
Please be aware that it's still alpha-ish code
Jeffrey Cliff
the record industry has attempted to redefine the term. There is a
relationship there, for sure but is 'stealing' really what you are
protecting against here?
Let's see if I have the concept right here. I want to make sure
that while running my business I accept only at BitstampUSD, because
that's the only one in this crazy network I trust to actually be able
to allow me to buy food from bitmunchies, say. I conduct a
transaction, and although I have jaroUSD, socrates1024USD and
randomguyBTC, the set of cycles allowed is restricted to those
terminating on my end in BitstampUSD, effectively making the
transaction in the currency of BitstampUSD (which would mean that in
the ripple world it would make more sense to have everyone choosing
instead of USD, BitstampBitstampUSD and socrates1024BitstampUSD etc
etc.. )? This seems to add a level of complexity, but could be a
desirable feature. Things that would implement this : the ability to
signal acceptance of a transaction externally or accepting a
transaction as valid (and to roll back any other one) on criterion
beyond merely having a cycle available. That would make it work if
you could signal to the network that a transaction is allowed not just
by the network but by the participants. Another approach might be to
make a tentative payment go through, and then have it reverseable
either based on a script or an external system. This might be risky.
Even so. Isn't this going to 'thin' the available possible
transactions unnecessarily? And isn't it addidng unnecessary
complications to the user -- similar to how no one uses
username@system!system!system.com emails anymore...what reason do we
have to expect this complication would be, on large, scaleable?
any forum and add 1 to the generation