On Thursday 07 May 2009 04:32:19 Ximin Luo wrote: > xor wrote: > > .... Considering the fact that there will be many more client > > applications (for example: Search indexing, files haring, web of trust > > based code review (image Freenet compiling its updates itself as soon as > > all code has received enough "review trust")). we came to the conclusion > > that it must be possible to assign a trust value which is only valid in > > the context of a single client application and does not affect any > > others. If someone publishes crap in the file sharing that does not prove > > that he is not able to produce nice messages in Freetalk, and vice versa. > > > > Now the question is: Which logic should be used to decide when to ignore > > an identity, i.e. when to NOT download it anymore and not add the > > identities which it trusts to the database? > > Several ideas: > > > > - Have a global "trust list trust" as in FMS which is a rating of whether > > the identity as a whole is trustworthy and should be downloaded, only > > decide upon the score value there whether to download it or not, ignoring > > all scores from client apps. > > > > - Because I do not have any other ideas, I came to the conclusion that it > > is necessary to have a separate "global" trust context (could be called > > "TrustList" or "WoT" or whatever) which is used to judge whether an > > identity should be downloaded or not. This means that each client app > > will need UI to manage 2 trust values per identity. > > Surely each client app will need only one trust value for itself, then the > meta-trust value can be handled by WoT itself?
What do you mean by "meta-trust value"? > Or did you mean the meta-trust is per-context only? In which case I agree > this is overkill; just have a meta-trust value for the whole identity, for > all its contexts. Each trust value will only be associated with the context in which it is given, yes. This is not overkill, I quote myself: > > If someone publishes crap in the file sharing that does not prove > > that he is not able to produce nice messages in Freetalk, and vice versa. It would be unfair if an identity was distrusted in ALL client applications just because the user misbehaved in one, wouldn't it? > The UI for this can then be in WoT. Also, other plugins > could just provide a link to the WoT UI for their context instead of making > their own UIs. > > > So does anyone has an idea which prevents the need of a "global" trust > > context? If not, I will implement it with the global context and call it > > "TrustList". > > I don't see why this is such a bad thing that you'd prefer to prevent it. > We (at least I) do something like this in real life, especially when > meeting strangers for the first time. A meta-trust value makes perfect > sense to me. It's a bad thing because the user of 1 client application will have to manage 2 trust values, the global trust and the local trust of the client application. The global trust for deciding whether the identity's trust list should be downloaded - this decides whether it is able to introduce new identities, and the local trust for deciding whether objects of the client application should be downloaded (that is Freetalk messages for Freetalk for example). > > On a different issue, I don't think it's a good idea for the algorithm to > recurse indefinitely. Would you be able to make it automatically construct > a small world network? Download the trust list of your most trusted IDs, > then (say) 2/3 of their most trusted, then 1/2 of theirs, etc? It is absolutely necessary that the algorithm downloads ALL identities because with messaging systems like Freetalk ALL messages should be visible to the user, not just "some" messages. This is the fundament of freedom of speech: The importance of every opinion of every speaker is EQUAL, even if someone creates an identity for just posting ONE message that ONE message must be visible to everyone. If you do not think so, consider the fact that someone might obtain a "secret government document" which reveals something important for the society, and because he is scared of getting arrested for publishing it, he creates a new identity just for publishing the document and then not ever uses the identity anymore. > Also (I said this to you before, but I have an additional reason here) the > algorithm itself should be modularised from the rest of the plugin. Maybe > not so users can change it, but so that we the developers can change it. > Trust metrics are still a topic of research and new ones are probably going > to be invented over the next few years; it would be nice if they could be > implemented without re-writing the whole plugin. It is not a problem to change the algorithm as long as the database model does not change. I think the model of Identity, Trust and Score should be enough for any algorithm. > One of my supervisors pointed me to one of his papers: > http://www.isoc.org/isoc/conferences/ndss/09/pdf/06.pdf Will have a look at it, thanks. -------------- 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/9c44a78f/attachment.pgp>
