?

Log in

No account? Create an account
Trust metrics' Journal
 
[Most Recent Entries] [Calendar View] [Friends]

Below are 7 journal entries, after skipping by the 20 most recent ones recorded in Trust metrics' LiveJournal:

[ Next 20 >> ]
Tuesday, August 5th, 2003
9:02 pm
[ciphergoth]
Source code for TrustFlow trust metric
Quite a few people have asked for this, so here it is, source code for the trust metric as I'm currently running it. It's nasty and dirty in various ways, but it seems to be getting the job done so far. Improvements welcome!

http://hacks.ciphergoth.org/trustflow/trustflow-0.01.tar.bz2

I meant to add, a great many people have commented on this metric in my journal - over 400 at last count.
Wednesday, July 30th, 2003
12:53 pm
[ciphergoth]
Try my new trust metric!
I have implemented my new trust metric, and applied it (fairly crudely) to LiveJournal friends lists as an experiment. The result is a tool that tells you who is "closest" to your friends list who isn't actually on it, like "popfriends" but more sophisticated.

Who is closest to your friends list?

Let me know how plausible the results seem to you. Note that the top few people are nearly always people you don't have on your friends list "on purpose" - in my case, largely because I've moved away from Edinburgh and so I'm trying to resist the temptation to add even the loveliest Edinburghers to my friends list.
Wednesday, July 9th, 2003
10:43 am
[ciphergoth]
Simple trust metric
Here's a simple trust metric. As usual, nodes are people and directed arcs denote that A confers trust onto B.

We each have a litre bucket. When the bucket overflows, water runs equally down each outgoing arc into the buckets at the other end. To assess who I trust, I simply start pouring water into my own bucket; the order in which other buckets become full to overflowing is their trust rank.

Update with notes:

Dead Ends: Where water has nowhere to go, it runs off the edge of the graph. This happens to water that flows into a subset of nodes all of which are full, with no arcs leaving the subset; the simplest example is a full bucket with no outgoing arcs.

Determining which nodes are dead ends is like determining "unreachability" in garbage collection. Reverse all the arcs, add a "special" node with an arc to each non-full bucket, determine which nodes are reachable from this special node with a standard depth-first search. Those nodes which are not reachable are dead ends.

Monte Carlo implementation: A bucket contains at most n droplets. Each droplet starts from your own bucket. A droplet hitting a full bucket chooses an outgoing arc at random to follow. Repeat until you have enough trusted people. You can explicitly detect dead end conditions, or you can give each droplet a maximum number of transitions before it "evaporates". The higher n is, the longer it will take to run and the greater the precision of your trust ranking.

Deterministic implementation: If water is pouring into my bucket at a constant rate, the rate at which each non-full bucket is filling up is defined by a set of linear equations. Find the "dead ends", determine the set of linear equations, solve, and determine which bucket(s) is going to fill next and how much water it will take. Add exactly that much water, add the newly filled buckets to the trust list, and iterate.

Incomplete knowledge: This metric is designed to work in a situation where each node advertises its outgoing arc list on a different Web page - you don't need to know the whole graph to answer the question "which node do I trust next", you only need the outgoing arc list of nodes you already trust. This applies to both implementations.
Wednesday, October 2nd, 2002
6:18 pm
[ciphergoth]
Implementation of Bram's trust metric
I've implemented Bram's probablistic trust metric: see this Advogato diary entry:

http://www.advogato.org/person/ciphergoth/diary.html?start=5

Update: - just got mail from Bram indicating that this isn't the metric he wanted to propose. More to follow.

The metric is very simple - it measures the probability that a person is reachable from the "trust source" if half the nodes at random are removed. It does this simply by marking every node invalid with probability 0.5, finding out which nodes are reachable, incrementing a counter on them all, then re-sampling 1000 times.

It seems to give plausible results, and on the Advogato graph (4000 active nodes, 40000 arcs) it takes 6 seconds to do 1000 iterations (which gives results to a precision of about 1.6%, where 100% is maximum trust). It's a combination of Perl and C.

brams-metric-0.1.tar.gz

To test it, you'll need the Advogato trust graph. Thanks to Gary Benson for pointing out that this is available as a graphviz .dot file here:

http://www.advogato.org/person/graph.dot

This is the form that my current implementation expects the trust graph to be in. There's a simple test command line in the Makefile.

This trust metric offers a limited form of attack resistance, but no resistance against crapflooding.
Sunday, September 29th, 2002
9:45 pm
[ciphergoth]
Trust metrication criteria
Taken from a discussion in Advogato.

Trust metrication criteria

Bram - I think your ideas about criteria are the Right Thing and I've been thinking some of the same things myself. However I think I can list three desirable criteria and prove you can't have all three.

One is the "Adding Certification Criterion" you define. The second is the "Isomorphism criterion" which states that trust metrication should be a function on graphs, and that isomorphic graphs should get isomorphic trust ratings. The third is attack resistance as raph defines it.

If the attacker has total control over a subgraph, they can duplicate trusted parties, trust links and all. The "Adding Certification Criterion" says that this must not reduce the trust of the duplicated parties, while the "Isomorphism Criterion" means that the duplicates must get the same trust. Thus the attacker has increased the total trust in their part of the graph. They can do this indefinitely for unlimited trust; thus they have violated attack resistance. I'm pretty sure your most recent proposal falls to this attack.

I'll try and write more on this when I get more time...

ciphergoth
Wednesday, July 3rd, 2002
5:29 pm
[ciphergoth]
Some more links
It's possible no-one else will ever join this community, but that's OK, I can use it as a private dumping ground for some of my notes on the subject...

Me asking about determinism in Advogato. It turns out Advogato isn't deterministic.

http://www.livejournal.com/talkread.bml?journal=lj_dev&itemid=328390&thread=3072198#t3072198

The Advogato trust metric: http://www.advogato.org/trust-metric.html

Raph Levien's PhD thesis draft. Often updated. http://www.levien.com/thesis/compact.pdf

TeX sources: http://www.levien.com/thesis/

Raph's diary: http://www.advogato.org/person/raph/
Thursday, April 11th, 2002
2:43 pm
[ciphergoth]
Welcome to the Trust Metrics community!
This is a community for discussion of trust metrics, as might be used on LiveJournal or elsewhere.

See Brad's discussion of the issue on

http://www.livejournal.com/talkread.bml?journal=lj_dev&itemid=328390

Note that Brad currently states that the idea of using trust metrics on LJ is "dead": see

http://www.livejournal.com/talkread.bml?journal=lj_dev&itemid=352658

I've created this community to discuss the idea and revive interest in it.

Examples of trust metric systems include the "karma" system on Slashdot, the kuro5hin points system, and the Advogato trust metric system. All of these systems have their problems. Part of the goal of this community is to discuss what sort of system would be appropriate for LiveJournal.

Just found this entry that relates to LJ trust metrics:

http://www.livejournal.com/talkread.bml?journal=lj_dev&itemid=328014

(updated this entry 2003-08-13 to move some information from the community user info that really belongs here)
[ Next 20 >> ]
About LiveJournal.com