A quick explanation of TrustFlow

[ciphergoth]

TrustFlow does not look at interests, who reads your journal, or any other such thing. It looks only at "friends" lists. It's trying to determine who is closest to who based on who lists who as a friend

Comments

[rampagingcarrot]

One of the unintended consquences is that if one of your friends has only 3 or 4 people on his friends list, then those 3 or 4 people will end up near or at the top of the list (depending on how connected your friends are).

[ciphergoth]

Yes, this is probably the biggest problem with the metric that this trial has revealed. There has to come a point where having more arcs devalues each arc, but it's tempting to set a bottom line of, say, 20 friends, such that if you have fewer than 20 friends then some of the tokens you get are thrown away.

[rampagingcarrot]

Wow, thanks for responding. I don't know very much about programming language at all, having not spent much time learning much in real applications. I only have the basis of a C++ education and the consequent understanding of the inrinsic role of logic in programming. Thus I was somewhat wary posting that fact, which I correctly guessed you already knew about, and I hope you didn't think that I thought I was pointing out something new to you (I thought of myself kind of acting as a lowly middleman of information).

Figuring out how your metric applied to my friends list was a very fun exercise in logic, and I'd like to help anyway I can, knowing full well that your mental capacity for understanding logical structures is easily sufficient enough for this enterprise.

The problem we have been talking about, is there currently a discussion on it somewhere with possible solutions? I'd be interested in looking at it, even if my lack of technical expertise renders me useless. Always eager to learn.

[ciphergoth]

Any discussion will either be in this community or linked to from here.

[ruakh]

Alternatively, if you're willing to abandon the nice water-flowing imagery, you could use some other rule to distribute tokens from a person to his friends. Currently, if a person's bucket is full and he's getting 1 token per minute, then each of his friends will get n-1 tokens per minute (assuming he has n friends); but you could use some other function - say, n-.5 - that offers less of a penalty for certing more people.

The major downsides that I can think of are (1) that this destroys the water-flowing imagery (since a person will "pass along" more tokens than they receive), and (2) that this adds an extra degree of arbitrariness (how do you decide the best function of n?).

[ciphergoth]

The trouble with this is that it breaks the proof of attack resistance...

[ruakh]

Ah.

I haven't actually seen your proof, but I take it one of the key features is that someone can't dispense trust faster than they obtain it?

[ciphergoth]

I haven't actually written up the proof :-) but yes, that's the key thing. It's all pretty obvious from there TBH.

[ruakh]

It's all pretty obvious from there TBH.

Obvious to you, perhaps; but you flatter me unduly if you think it's obvious to me.

:-)

(My knowledge of trust metrics comes almost exclusively from your explanation of this one, and I have no idea what would even constitute a proof that a given trust metric is resistant to attack. For that matter, I have no idea how one would formally define resistance to attack. So all told, I'm quite clueless on the matter.)

[ciphergoth]

Look at the proof for Advogato's trust metric:

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

With my metric, you can say that there's a bound on the amount of water flowing into nodes controlled by bad people, and that means that there's a bound on the number of nodes they can get certification for.

[ruakh]

With my metric, you can say that there's a bound on the amount of water flowing into nodes controlled by bad people, and that means that there's a bound on the number of nodes they can get certification for.

Except that in your metric, there's an arbitrary amount of water flowing into the seed, so over time all the bad people can get certification and start spilling over more water?

Actually, it seems that in your metric, everyone will eventually get certification, as long as there's any chain of trust from you to them? (Though if they're far away, and some of the intermediaries offer many certs, then it will take much longer.)

Suddenly I think I must be missing something fundamental with your metric. In your nifty LJ tool, you cut off the list after 50 friends; I took that to be just an aspect of the tool, but now I'm wondering - is that an aspect of your metric? That it trusts only n people? Because if so, then I think your system is automatically resistant to attack - because no matter how what volume of spam you have, there is

[ciphergoth]

These are very good points

[ruakh]

Thoughts toward a stricter definition of attack resistance:

Advogato's definition can be rephrased approximately thus:

"Resistance to attack is the property that the number of trusted accounts that are untrustworthy is independent of the total number of accounts that are untrustworthy."

For a metric that can only trust a bounded number of accounts, I think you might adjust this definition just slightly:

"Resistance to attack is the property that the proportion of trusted accounts that are untrustworthy is independent of the overall proportion of accounts that are untrustworthy."

How would that be?

[ciphergoth]

"independent of" is statistical terminology; you'd have to have a statistical model which assigned each possible trust graph a probability before you could use that terminology. That's the wrong way to go, because a big part of the trust graph is not random - it's chosen by the attacker

[ruakh]

Oh, I see.

Apparently, the link you sent me - Advogato's (informal?) proof of attack resistance - doesn't really bother with a formal definition, then?

Sorry about that!

[ciphergoth]

Another dirty secret of trust metrics that I tried to shove under the carpet comes to light! No, Advogato doesn't actually formally define what attack resistance means, and any attempt I make at such a definition is either too inclusive or includes nothing. I'm working on it.

Meanwhile the best I can say is that the 1/n friends list falloff is necessary for the proofs of the properties that in turn give me the warm fuzzies about attack resistance.