Peer state transition matrix

Peer state-transition matrix

Domain

The following table shows the possible state transitions in regards to peers. Note that the events and states represent the domain and what is meaningful to the user, rather than design-level information. The columns represent (numbered) states, and the rows represent events. The cells show the new state, or a dash if the transition is not allowed. The cells also sometimes link to a note found below the table.

	1. Unknown	2. Unassigned (Unlinked)	3. Trusted (Linked)	4. Ignored
Peer Discovered	1 (a)	-	-	-
Peer Assigned	3 (b)	3	-	3
Peer Ignored	4	4	4	-
Peer Unignored	-	-	-	2
Peer Removed	-	1 (c)	1 (c)	1 (c)

Notes

1. A peer can be discovered in several ways, such as through finding the peer in the XMPP roster, an incoming presence subscription, having the peer communicated to the given user in some other way, having the peer added without a contact, etc.
2. Assigning an Unknown peer is the same as adding a peer and at the same time assigning the peer to a contact.
3. Removing a peer should, in addition to having the peer being removed from the local roster, probably have as side-effects to cancel any presence subscriptions from the peer as well as removing the peer from the remote roster.

Other remarks

• Unknown means that the system is unaware of the peer.
• Unassigned (Unlinked) means that we have not yet decided whether to trust/link, or ignore, the peer. No information is revealed to the peer while the peer is in this state. The state applies to any peer that we know about for some reason, but has not assigned to a contact or ignore yet. It could be an address received from the XMPP roster, or an address communicated to us in another way.
• Trusted (Linked) means that we show our presence and any other "public" information related to ourselves to this peer (public information could for instance be a desired alias). This is the only state in which we share "public" information with the peer. A peer being in this state will necessarily mean that the peer is assigned to a contact. This is the only state in which Pontarius will send and accept presence subscription requests on the user's behalf.
• Ignored means that the peer should be considered irrelevant for Pontarius. However, incoming presence subscription requests from ignored peers should not be ignored. We should also not cancel outgoing subscription requests, at least not willy-nillily. Ignored peers should generally not be visible in the user interface (however, we should allow for the possibility of inspecting ignored peers, as well as "unignoring" ignored peers).

Design: Local Roster

A more detailed and implementation-specific version of the above follows.

	1. Unknown	2. Unlinked	3. Linked	4. Ignored
Incoming Peer From XMPP Roster	2	2	3	4
Incoming Presence Subscription Request	2	2	3 (a)	4 (b)
Peer Missing From XMPP Roster	-	2	3 (c)	4
Peer Added (To/With Contact)	3 (c)	3 (c)	-	3 (c)
Peer Added (Without Contact)	2	2	3 (c)	4
Peer Ignored	4	4	4	-
Peer Unignored	-	-	-	2
Peer Removed	-	1 (d)	1 (d)	1 (d)

Notes

1. Presence subscription requests from linked/trusted peers should be automatically accepted.
2. Presence subscription requests from ignored peers should be shown.
3. When linked/trusted peers are not in the remote roster, they should automatically be added.
4. Removing a peer should, in addition to having the peer being removed from the local roster, probably have as side-effects to cancel any presence subscriptions from the peer as well as removing the peer from the remote roster.

Other remarks

• Presence subscriptions towards linked peers should automatically - to the extent possible/feasible - go both ways. We should therefore probably try to use pre-approval, automatic presence subscriptions, and perhaps also other mechanisms, to try to make sure that users have presence subscriptions both from and to trusted peers.

Design: Local vs Remote roster

The table below shows what to do depending on if a peer is Present (To/From) or Not Present (From/None). These states could only be updated through a roster push or the initial roster retrieval.

	1. Unknown	2. Unlinked	3. Linked	4. Ignored
Present (To/From)	2	2	3	4
Not Present (From/None)	1	1/2 (a)	1/3 (a)	4

a. The user should be presented with a choice to either

• re-add the remote peer
• remove the local peer
• ignore the peer for now