On Thursday 07 May 2009 00:02:11 Evan Daniel wrote: > The WoT documentation claims it is based upon the Advogato trust > metric. (Brief discussion: http://www.advogato.org/trust-metric.html > Full paper: http://www.levien.com/thesis/compact.pdf ) I think this > is wonderful, as I think there is much to recommend the Advogato > metric (and I pushed for it early on in the WoT discussions). > However, my understanding of the paper and what is actually > implemented is that the WoT code does not actually implement it.
I must admit that I do not know whether its claim that it implements Advogato is right or not. I have refactored the code but I have not modified the trust calculation logic and have not checked whether it is Advogato or not. Someone should probably do that. > I don't have any specific ideas for how to choose whether to ignore > identities, but I think you're making the problem much harder than it > needs to be. Why exactly? Your post is nice but I do not see how it answers my question. The general problem my post is about: New identities are obtained by taking them from trust lists of known identities. An attacker therefore could put 1000000 identities in his trust list to fill up your database and slow down WoT. Therefore, an decision has to be made when to NOT import new identities from someone's trust list. In the current implementation, it is when he has a negative score. As I've pointed out, in the future there will be MULTIPLE webs of trust, for different contexts - Freetalk, Filesharing, Identity-Introduction (you can get a trust value from someone in that context when you solve a captcha he has published), so the question now is: Which context(s) shall be used to decide when to NOT import new identity's from someones trust list anymore? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090507/736cf5bb/attachment.pgp>
