This differs from other elements we have discussed so far because this is not part of the kernel and its use is entirely optional for OpenKnowledge peers. Some peers may choose not to use any trust model, some may choose other trust models that may exist or may wish to write their own (see below for information about how to do this). We believe that our trust model is useful in many scenarios but freely admit that it is not the most appropriate model in all situations.

On this page, we briefly introduce the general notions of our trust component. For further details and for the algorithms, please see Deliverable 4.5 and Trust in P2P.

The trust component keeps records of all previous interactions, which can be used to evaluate how well a potential peer is likely to play a role. In addition, these stored records can be shared with other peers through gossip, and gossip can be used in the trust calculation - in addition to personal experience, or in place of it if no personal experience exists - and can be weighted according to the provenance of the trust information.

When considering how well a peer is likely to play a role, there are two factors to consider:
1. is the peer capable of playing that role?
2. is the peer willing to play that role?
Since any peer can play any role in which it can satisfy the constraints, observation of previous constraints that have been satisfied can help us to answer the first question. However, there are two different levels of peer ability in playing a role:
a. satisfying the constraints;
b. providing good quality goods/information/etc. (depending on the type of role).
Complying with the first condition is the minimum requirement of successful interaction, and observation of previously satisfied constraints can answer this question (fully or partially). The second condition is more nebulous and can only be answered by considering user feedback in identical or similar situations.

The second question is more difficult, and depends on factors such as the good intentions of the peer. To answer this question, context is more important. A peer that has performed well in a similar situation is more likely to perform well than one that has only performed well in a very different situation.

The trust algorithm considers all these factors and uses a probabilistic measure to produce a score in [0 1] indicating the trust value for a peer playing a particular role in a particular IM.

There are two kinds of information about how well a peer performed its role in an interaction:

- information about whether an interaction terminated or not.
This can be generated automatically by the coordinator of an interaction. It cannot provide information to help assign blame for the failure of an interaction to terminate: all peers involved in the interaction are blamed equally. This means that in isolation, it does not provide a reliable judgement. However, over many interactions, it is more useful. An able, well-meaning peer may sometimes interact with failing peers and thus be involved in a failed interaction, but most of the time its interactions will terminate successfully.

- information about whether the service was performed well.
This may, depending on the situation, mean providing high quality goods, appropriate and correct information, and so on. This usually cannot be judged through automated observation of the interaction. This is because such considerations are outside the scope of an interaction. Expectations of quality would not normally be expressed as a constraint and cannot usually be judged until after the interaction terminates and the goods or information are actually received and/or used. Additionally, such a judgement is using subjective and depends on the judgement and perhaps taste of the user. Therefore, this information must be given directly by the user.

Once the interaction has successfully terminated, the trust component will cause a small window to pop up in the OpenKnowledge GUI to remind the user that feedback is pending on this interaction (if the interaction terminated unsuccessfully, the user will be informed and no further feedback will be necessary.) The user can ignore and dismiss this request or, at an appropriate point (for example, after the goods have been delivered if the interaction involved buying goods), can provide feedback about the quality of the service provided. If this feedback is provided, it will be used by the trust module as part of the stored information about the transaction and used to judge expected performance in future interactions.

- why and when would you prefer to use another trust model?
Our model is based on frequent interactions. In order for the values produced to be meaningful it is necessary to have several previous interactions to refer to. This does not all have to be personal experience as much useful information can be received through gossip. However, in a domain where interaction is sparse, there may only rarely be enough information to make the output from this trust component useful. Once example of such a domain is bioinformatics.

Additionally, in some particularly communities, trust is judged in very different ways and peers involved in such communities may wish to judge trust in their own way.