Buddy properties are published in PEP. As currently implemented, all XOs subscribe to the presence and buddy properties of all other XOs on the same server.

The buddy properties currently supported are ip4-address, key and color.

Subscribers receive the change notification, as usual for PEP. (For all the other PEP nodes described in this document, the process is the same, and has been omitted from this document for conciseness.)

The Neighbourhood view on the OLPC groups XO icons by their current activity, so XOs must notify each other of current-activity changes.

As currently implemented, this is done for both public and private activities, which represents an information leak. (FIXME)

Note that the 'type' attribute is in fact the activity ID; the name is for historical reasons.

For activities to be handled by the Sugar environment, certain properties are needed. Because there is no server-side storage corresponding to a chat room and accessible by all participants, participants each publish the properties of all their activities.

To keep participants' idea of the activity properties in sync, when the properties change, the participant making the change MUST send a broadcast message to the chatroom, notifying other participants of the new properties.

This <message/> MUST be sent before updating the PEP node with the activity properties.

For public activities, the participants all announce all their activities and their properties in a PEP node.

When an activity becomes private, the participants all delete it from their activity-properties PEP nodes.

The participants all announce all their list of activities in yet another PEP node, for backwards compatibility. This mechanism will be removed in a future version of this protocol.

Note that again, the 'type' attribute is in fact the activity ID; the name is for historical reasons.

When an activity becomes private, the participants all delete it from their activity-properties and activities PEP nodes. In this example, the XO whose JID starts with 11111 makes the activity whose ID starts with aaaaa private, and removes it from their PEP nodes; the XO whose JID starts with 22222 responds by removing it from their PEP nodes too.

To a third XO observing the PEP nodes, this is indistinguishable from both XOs leaving the activity simultaneously, which is what we want.

Before inviting a buddy to an activity, OLPC users are expected to send them the activity properties. These are sent in a <message/> stanza referred to as a "pseudo-invitation". If the activity is private, then this is the only opportunity the invitee has to get the activity properties.

If the activity properties change before the invitee joins the activity, the inviter must notify the invitee by re-sending the pseudo-invitation (only).

If the inviter leaves the activity before the invitee joins, the invitee can no longer rely on being notified about any changes; if the activity was private, the invitee can't even rely on being able to see whether it exists. Accordingly, the inviter should cancel their invitation; if all invitations to a private activity have been cancelled, the invitee should assume that the activity has disappeared.