From: Andrew Miller <amiller@cs.ucf.edu>

Date: Thu, 27 Sep 2012 05:31:44 -0400

Message-ID: <CAF7tpEzrPG4w=-CXb1BdLOPsbkSjRziVe1qYTwVv7VNvkPm-OA@mail.gmail.com>

To: Melvin Carvalho <melvincarvalho@gmail.com>

Cc: Web Payments <public-webpayments@w3.org>

Date: Thu, 27 Sep 2012 05:31:44 -0400

Message-ID: <CAF7tpEzrPG4w=-CXb1BdLOPsbkSjRziVe1qYTwVv7VNvkPm-OA@mail.gmail.com>

To: Melvin Carvalho <melvincarvalho@gmail.com>

Cc: Web Payments <public-webpayments@w3.org>

The most important thing about the overlays I described (including Ripple, TrustDavis, etc) is that trust in the network is inherently subjective. There is no such thing as a 'global' assessment. Instead, if you have a pair of identities, you can infer the trust between them. To illustrate this distinction, let me point out that eBay reputations are NOT a weblike overlay. Your seller rating is a global value. If your seller rating is 98%, then everyone who looks at your page will see 98% (and will see the same supporting data as well). eBay, as an authority, is required to curate the ratings to some degree. >Given the above, we've been thinking of making PaySwarm Authority >software be able to vouch for identities on the network. For example: > >* This identity has performed 104 successful transactions. This, in my opinion, is a step in the wrong direction. It puts the PaySwarm Authority into the context of your trust assertion. I'll try to make a constructive suggestion: use FOAF style tags to indicate who computed this summary on your behalf. If you fully trust the person who produced (and signed) this assertion, then you might take their statement at face value. If you only trust them partially, then you may dereference the links in order to obtain corroborating evidence. As an extreme example, if the assertion is that the seller has completed 100 successful transactions, then your client might attempt to contact each of those 100 satisfied customers, obtaining signed message from each of them confirming their positive review before including it in your inference. On Thu, Sep 27, 2012 at 5:09 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 23 September 2012 18:40, Andrew Miller <amiller@cs.ucf.edu> wrote: >> >> The relationship between Trust, the Web, and Payments is profound and >> deep, and Ripple is the clearest expression of this idea. The >> important thing to realize is that trust is inherently a weblike >> structure. Trust is subjective and indirect. I'm going to describe the >> general structure of the social graph, and explain how you get >> different forms by choosing the semantics of the edges. >> >> Consider a family of directed weighted graphs sharing the same nodes, >> where each node represents a persona - either a 'real identity' or a >> pseudonym. Since the graphs share the same nodes, they differ only by >> the edges. So by a 'family of graphs', I mean that each graph is like >> an overlay of links between the same set of nodes. In each case, an >> edge between a pair of personas represents some kind of direct >> relationship between the two. Given one of these graphs, and a pair of >> nodes/personas, what we are usually interested is observing a 'flow' >> of some kind, the sum of all weighted paths from A to B. >> >> In one overlay, each edge represents a credit line, where the weight >> is the credit limit. The flow from one person to another represents >> the total available credit to use as a payment. In another overlay, >> each edge represents an 'outstanding balance', or a debt - credit >> limits that have been exercised. These two overlays together are >> Ripple, which allows payment through indirect credit on a web. Also >> see "Liquidity in Credit Networks" http://arxiv.org/abs/1007.0515 >> >> In another overlay, each edge represents that one person has >> diligently validated the identity of another. In another overlay, each >> edge represents an assessment that a persona is trustworthy to perform >> such diligent checks. These two overlays together are the PGP web of >> trust, which is useful for validating identities with no central >> administration. >> >> In a slight variation of this, the edges represent trust in the >> responsible trading behavior of each person. Now we are talking about >> a reputation graph like Bitcoin-OTC. For an illustration, see >> >> http://serajewelks.bitcoin-otc.com/trustgraph.php?source=nanotube&dest=amiller >> >> In another overlay, each edge represents an 'insurance bond' where one >> person vouches for the other. The flow from A to B represents the >> amount of insurance payout that A could collect if B misbehaves. This >> graph is TrustDavis. >> http://www.cs.ucdavis.edu/~defigued/index_files/trustdavis.pdf >> >> Do you see that these are all inherently the same kind of weblike >> structure? It's disappointing that OpenTabs, for example, scopes >> itself out of the potential to express indirect relationships, since >> the credits are strictly limited to the two people who initially >> interacted with each other. As another example, eBay has a seller >> reputation, but it is global rather than weblike, and therefore also >> cannot express indirect trust. Bicoin-OTC is weblike, eBay ratings are >> not. Ripple is weblike, OpenTabs is not. Let us build more weblike >> things! > > > I've been reading through trust davis and it remind me of network theory. > In particular min flow, max cut. > > http://en.wikipedia.org/wiki/Max-flow_min-cut_theorem > > The overlay idea is exactly what I have in mind. Additive information can > only be a good thing. > > So you have two ideas. > > 1. Reputation Footprint > > 2. Trust Inferences > > I think it makes sense to decouple the two? > >> >> >> On Sun, Sep 23, 2012 at 8:28 AM, Melvin Carvalho >> <melvincarvalho@gmail.com> wrote: >> > I'm starting to think more and more that payments and trust go hand in >> > hand. >> > >> > This is especially true when you are establishing credit limits for >> > issuing >> > new money. >> > >> > Has anyone had thoughts on this topic? >> > >> >> >> >> -- >> Andrew Miller > > -- Andrew MillerReceived on Thursday, 27 September 2012 09:32:18 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Thursday, 27 September 2012 09:32:19 GMT
*