On Presence updates/User Profiles/Collaboration
Presence updates
We should aim for a user experience that allows a child to view not only the status of their friends (who is online, what activities they participate in), but also the status of as many other children as possible. It is reasonable not to expect to have thousands of children in a plain mesh network, but it is not this upper limit that should be driving the choice of having mesh network-wide information about all other children and all currently shared activities. Instead, we should aim to constantly provide this information and attempt to drive upwards the upper limit of the children we can support in a simple mesh, before we fall back on a server for centralized information. This would allow children to reach beyond their "friends" circle onto other children that were considered to be "strangers", enlarge their community and make their experience more interesting.
Presence updates are notifications of changes that happen to a user's profile by the user. These notifications MAY contain the new user profile (I can piggyback my new nickname on the notification itself), or MAY trigger a request for a complete update (if I change my picture and this will trigger requests by other users for my new picture - doing the same for just the nickname will have absurd overhead).
Discovery updates (to adopt Scott's terminology) do not bear any information about the user, other than the fact that she is online and reachable. The flow of discovery updates throughout the mesh network allow users to build a list of contacts that are currently reachable within the mesh network, but provides no further information about those users. At this point, matching cached information to unique user IDs in the contact list may provide (potentially stale) profile information about a user.
When a user receives a discovery update from a target user that has not been encountered before, she MAY choose to request a full presence update (includes information about the whole profile) from the target user. The user MAY also cache received profile information about the target user for future reference. If profile information was previously cached, a presence update (hash of current target user's profile) MAY be requested and compared to the (hash of the) cached profile and then act accordingly.
By separating presence updates from discovery updates, we minimize the information necessary to maintain basic information on which unique IDs are present in the mesh network (thus maximizing scalability even without the use of "optimizations" such as only exchange discovery updates with friends, use of a central XMPP server, etc), while we maintain an extensible set of information about the user that may include fields of arbitrary size like large pictures.
User Profile
The user profile is a set of fields describing user information and user status. User information MUST include some basic information such as nickname and colors and MAY include biographical information such as real name, age, sex, class, year, etc. User status MUST include a list of activities that the user is currently sharing publicly and MAY include other information such as a short status ("online", "away", "extended away", etc), and a status message ("feeling sleepy", "I'm bored!").
A change by the user to her user profile, triggers an update within the mesh network as described in the previous section. As a result, we attain central control within the network stack not only of how user information gets locally stored and globally shared by means of presence updates, but we can also reuse the same mechanism as a simple collaboration mechanism: by including the list of shared activities (by the user) in her user profile and propagating presence updates, we have detailed information not only of user information for all other users, but also a detailed list of what activities are being shared and by whom.
Collaboration
When a user chooses to share an activity, her user profile is altered and a presence update is triggered within the network. A row is appended to her user status containing three fields:
| Activity type | Activity ID | reserved field |
The activity type characterizes the "protocol" used by this activity (eg all chat activities may be named differently, may be different forks of some initial chat activity, but as long as they use the same "protocol" they can still interoperate). The activity ID characterizes the specific instance of the activity that is currently shared.
The user may choose to either share an activity, or join a activity that was shared by someone else. When the user shares an activity, a unique activity ID is created (can be based on the current time with ms accuracy). This unique activity ID propagates throughout the mesh network as part of the user's updated profile. Other users that choose to join this shared activity update their own profile and in turn trigger an update. Having joined a shared activity, the underlying collaboration mechanism can now receive data from the activity to be shared with other users participating in the shared activity and maintains a list of those users (as part of the profile updates that were received in the past about users joining the shared activity).
Scaling properties of the above mechanisms
Scalability MUST be at the core of any proposed presence and collaboration mechanisms. A reliable data transport protocol should accompany the above mechanisms in the context of a wireless, mobile and potentially dense mesh network. Scalability should be achieved in the face of all these three properties of a mesh network.
Cerebro achieves those goals by building on the fact that any wireless transmission is by default broadcasted (because of the medium itself) and that unicast is only a logical separation in the wireless medium (as opposed to being a physical separation in a wired medium). The current scaling properties of Cerebro are presented here.
Sharing and joining activities entails quadratic cost (O(n2)): every node joining the activity needs to notify every other node participating in the the activity, for a total of N(N-1)/2 updates. This has a severe effect especially in dense environments. However, the proposed data transport protocol presents a linear cost because it turns the disadvantage of being in a dense environment into a feature. The idea is that "since I am broadcasting by default and this is a dense environment, I only need to send a frame only once before (almost) everyone receives it".
