This is the lifecycle of interaction from the point of view of user.

i) Why is this interaction taking place? The user inputs a need reflecting why he wants to participate in an interaction. For example, this might be buy camera, or it might be that he wants to provide a service in exchange for payment, or so on. This need is expressed in terms of keywords.

ii) What will the interaction protocol be? The user will then need a protocol to describe the interaction that he wishes to take part in. This is called an Interaction Model (IM) and is described here. There are various roles (at least two) in an IM and the user must choose which his peer is to play. The user may have written his own IM for this interaction, but more usually he will wish to find one that has been published on the network. In this case, the discovery service is invoked and will return a list of potentially suitable IMs. When IMs are published, they are annotated with a set of keywords, and these keywords are matched to the user's need to discover the potentially appropriate IMs. These IMs are ranked according to their popularity - i.e. how many times they have been used.

The user must then choose which of the potential IMs he wishes to use. This can be done in various ways:
a) Choosing the highest ranked IM;
b) Re-ranking the IMs according to the scores returned by the automated matching operator, which matches the ability of the user's peer to the abilities required by the role it is to play;
c) The user looking through the IMs personally.

iii) Subscribing to the interaction Once the IM has been chosen, the user's peer should subscribe to the appropriate role. The following information is required for subscription:
a) The peer ID (this can be verified and it is not possible to lie about this).
b) The matching score that was produced by matching the peer's abilities to those required (it is possible for dishonest peers to lie about this).
c) Some keywords giving more details of the peers wants or intended service (this is optional).

iv) Initiating the interaction Once all roles in an IM have at least one subscriber, the interaction can begin. This may happen immediately if all the other roles were subscribed to when the user's peer subscribed, or may not happen for some time (or never) if some of the roles currently have no subscribers. Whether a user will wish to subscribe to a role in an IM that won't commence immediately, or whether he will wish to search for one that is ready to go will depend on the situation. For example, a seller may be prepared to subscribe to a role and then wait around until a buyer appears, whereas a buyer may perhaps want to purchase something immediately.

Once all the roles are filled, a peer on the network will be arbitrarily chosen to be the coordinator for this interaction. This may or may not be a peer that also subscribed to that IM, though in a system with a large number of peers, it is very unlikely that they will be. Any peer can opt out of being chosen to be a coordinator; the coordinator will be chosen from all the peers that are willing to do this.

v) Choosing partners The coordinator will send information of which peers have subscribed to which roles to all of the subscribers of the IM. Each peer must then choose which of the peers subscribed to other roles it is prepared to interact with. This can be done automatically with the help of the trust model or can be done through intervention of the user. Each peer then sends back to the coordinator a set of potential partners.

vi) Allocating roles The coordinator then allocates peers to roles in such a way that no peer is forced to interact with a peer that is not in its list of chosen peers. The coordinator informs all subscribed peers of the outcome. The process now ends for peers that have not been chosen. They may resubscribe to the same role in the same IM if they wish, and wait for the process to begin again.

vii) The interaction Whenever a peer is due to send a message, the coordinator will prompt that peer to give it the details that should be sent in that message, and the coordinator then passes that message on to the appropriate peer. This message passing is not visible to all peers, only to the sending and receiving peer in each case.

viii) The interaction terminates If the interaction proceeds smoothly, this will happen after all the messages of the interaction have been sent. However, this may happen earlier if a peer fails to respond appropriately.

ix) Interaction feedback The coordinator informs all peers involved in the interaction as to whether the interaction terminated successfully (they may or may not be able to judge this for themselves, depending on their role in the interaction). The coordinator will also send back information about certain messages so that peers can determine how things went during the interaction (how and why this happens is discussed here).

x) Learning from interactions Optionally, and depending on settings, the user can provide more targeted feedback about certain aspects of the interaction. This may only happen some time after the interaction: for example, if the user's peer acted as a buyer, some judgement can be formed about the success of the interaction through observation of message passing and successful termination of the interaction, but the full quality of the seller can only be ascertained once the goods have actually arrived and been examined by the user. These observations can be used to judge which peers to interact with in the future.