<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>Assumptions<br>===========<br><br>Please tell me if any of these are wrong:<br><br>Contacts ("buddies") have the following non-transient properties:
</blockquote><div><br class="webkit-block-placeholder"></div><div>First thing, we may choose a term other than "buddy." Any suggestions? "xo" seems reasonable, since that's how we refer to them in general everywhere.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">* a name to be displayed in the UI (Unicode string)<br>* a public key (binary data)<br>* a color (ASCII string constrained to be in the format #xxxxxx,#xxxxxx
<br> where x is any hex digit)<br>* a JID (Jabber ID, which is the unique identifier in XMPP) on the server<br> (for people you see on the server this is obvious, for people you see on the<br> mesh you want to be able to remember it for future reference)
<br>* an "avatar" photo or image (binary data, JPEG or PNG, ~96x96 pixels)</blockquote><div><br class="webkit-block-placeholder"></div><div>This may be quite silly, but if it's 90x90 px it will fit cleanly into the grid we've been using for designs. Since it's not a power of two, I'm not sure why 96 is the blessed number. Are there technical reasons here?
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">* an IPv4 address for legacy activities (ASCII string, "<a href="http://123.45.6.78">123.45.6.78
</a>",<br> deprecated)<br><br>Properties will only be added slowly, so it is acceptable if each new<br>property needs changes to the connection managers and to Presence Service.<br>Properties beyond the above will be optional.
<br><br>Each child has a "home" XMPP server which is (at least initially) the one they<br>were assigned to when their XO was activated. The server has a globally<br>unique DNS name (I'll assume here it's
<a href="http://foo.schools.laptop.org">foo.schools.laptop.org</a>) and the child's<br>JID is of the form <a href="mailto:something@foo.schools.laptop">something@foo.schools.laptop</a>.org.<br><br>Whenever the child's XO and the XMPP server both have unrestricted Internet
<br>access, the XO will be able to log in to the XMPP server - they aren't<br>forced to log in to the nearest XMPP server, the same way you can log<br>in to <a href="http://olpc.collabora.co.uk">olpc.collabora.co.uk</a>
(which is in London) from America. Whenever<br>the XO can't make a TCP connection to its "home" XMPP server, it will<br>only have link-local connectivity using Salut, with all the restrictions<br>that imposes.
<br><br>Activities are implemented as chat rooms - there is a 1<->1 mapping<br>between (shared/shareable activity instances) and (chat rooms). The chat<br>room implements the text messaging and Tubes interfaces.<br>
<br>A child can be in multiple activities.<br><br>Shared/shareable activities have an ID which is pseudorandom, assumed to<br>be globally unique, and immutable.</blockquote><div><br class="webkit-block-placeholder"></div>
<div>They will also have a version identifier of some kind, which may need to relate to the activity identifier when we decide what is actually represented on the mesh. We're still discussing details in this area. </div>
<br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Activities have the following properties:<br><br>* Name (human-readable Unicode string, changeable)<br>* Color (string in the same format as buddy color, immutable)
<br>* Type (string in the format of a D-Bus service name, immutable - this<br> is what sets the icon in the mesh view)<br>* Tags (list of human readable Unicode strings, semantics unspecified at the<br> moment, changeable)
</blockquote><div><br class="webkit-block-placeholder"></div><div>A few notes on activity properties. I'm not sure how exactly these map to above, so I'll lay them out as best I can. We want to know the Name of an activity (eg. "My shark painting"; also Name above), the Kind of the activity (eg. "Paint"; not listed above), and the Icon (Type above seems to relate here, but I think we need to directly associate the icon and not just its identifier; how does this work?)
</div><div><br class="webkit-block-placeholder"></div><div>As for color, we have put some thought into the version history system, and have a potential use for associating different color pairs with different versions in the history. This is still immutable from the perspective of the kids, of course.
</div><div><br class="webkit-block-placeholder"></div><div>Regarding tags, I won't get into details here, but we also have ideas around tags which require each tag to have an associated identity (unique ID for a buddy and a color pair) for use in displaying the tags. If we do follow this approach, we'll need a more complex data structure for the tag list.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">which are set when the activity is created, and are required to be<br>visible in the mesh view to children who have not joined the activity.
</blockquote><div><br class="webkit-block-placeholder"></div><div>It won't be required that every child see every activity. Only activities which the child is able to join should be shown in the mesh (at the moment, this simply means any shared activity, but in the future we may have more scopes which limit who can see what on the mesh).
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">No other information is required to be visible in the mesh view, and<br>properties will be added sufficiently slowly that it's acceptable to require
<br>changes to Gabble, Salut and PS for each new property.</blockquote><div><br class="webkit-block-placeholder"></div><div>We also have a notion of an activity Description, though semantics are not defined here either. This description could appear on the mesh, and also has a place in the Journal. We're not sure how to reconcile different Descriptions across versions and across different kids' Journals.
</div><div><br class="webkit-block-placeholder"></div><div>We also need to associate the list of participants with an activity, regardless of how this is shown in the UI. Obviously we would like to group the XO icons around their active activity. We may also want a list of the names of the participants in the rollover for an activity on the mesh.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">It is acceptable if changes in the activity name aren't visible in the<br>mesh view for a minute or so, but they must be reflected in the mesh
<br>view eventually.</blockquote><div><br class="webkit-block-placeholder"></div><div>Sounds perfectly reasonable; I don't expect any changes in the mesh to be immediate, though the less lag the better. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
If activities need activity-specific "properties" these will not be needed by<br>the mesh view, and the activity will have to use its Tubes channel (or<br>something) to propagate these. (Loosely: they're not our problem. :-)
<br><br>Activities can either be:<br><br>* unshared (from Telepathy and the PS's point of view, equivalent to not<br> existing)<br><br>* invite-only (exists as a chat room, but not publicized; does not<br> appear on the mesh view unless you've been invited; does not appear in
<br> server room listings; any participant can invite others to join in)<br><br> (This type does not exist at the moment, but is a goal for Trial3)<br><br>* public (may appear on anyone's mesh view; anyone may join)
</blockquote><div><br class="webkit-block-placeholder"></div><div>There is a 4th kind which might also be a trial 3 goal. We'd like "group" activities, such that all the members in a given group can see any activities that are shared with that group, without needing an explicit invitation. As an addition, any activity should allow invites of individuals into the activity, even if those individuals don't match its current shared scope. Private activities are basically invite-only activities with one participant, though the technical details can be different. Inviting someone into a private activity should implicitly share it non-publicly.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">When someone is invited to an activity they will be sent enough<br>information to put it on their mesh view.
<br><br>If buddy groups are implemented, we plan to make them purely a UI thing -<br>if sharing an activity with "My Class" is implemented at all, the UI<br>should do this by creating an invite-only activity and sending
<br>invitations to everyone in the group "My Class". This keeps the<br>Telepathy interface relatively simple.</blockquote><div><br class="webkit-block-placeholder"></div><div>Hmm, my above comment contradicts this, unfortunately. We're not sure that explicit invitations are necessary or desired for every group activity. However, I don't really see a problem with implementing that way especially if it's easier. I do want to point out, however, that any activity to which you've been invited should remain on the mesh even if you decline the invitation. It should always be accessible to you in the future.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Children who are not in an activity can't change anything about it<br>and if Presence Service tries this, it should expect it to fail.
</blockquote><div><br class="webkit-block-placeholder"></div><div>Agreed. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Questions<br>=========<br>
<br>Can children change their names?</blockquote><div><br class="webkit-block-placeholder"></div><div>We talked a lot about this in terms of security. I think the current idea here is that children CAN'T change them, at least without a reasonable amount of effort. When they change their name, they essentially take on a new identity and need to be reintroduced to everyone. Short answer is no.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">If so, how acceptable is it for other children to continue to see the old name<br>indefinitely? Required, recommended, acceptable, grudgingly allowed,
<br>unacceptable? (We can reduce traffic significantly if we're allowed to<br>save the child's original name to the XMPP roster)</blockquote><div><br class="webkit-block-placeholder"></div><div>We also talked about the possibility of a pet-name system by which a child would be locally known with a particular name.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Can children change their colours?</blockquote><div><br class="webkit-block-placeholder"></div><div>
Yes, but no UI for it is available yet. This will be mutable. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Can children change their photos?</blockquote>
<div><br class="webkit-block-placeholder"></div><div>Yes, same as above. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Can the child's "home XMPP server" change,
i.e., can their JID change?</blockquote><div><br class="webkit-block-placeholder"></div><div>I assume this is the registration question. There is a ticket about it, and the current idea is to present a "register" action within the secondary rollover for a school server, so that a child can re-register when needed. I don't know the technical details.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Is ip4-address still required or can we drop it? Is an IPv6 address required<br>in buddy properties?
<br><br>Do we need the concept of a buddy's "current activity"? (Currently it's<br>implemented, but in practice is write-only)</blockquote><div><br class="webkit-block-placeholder"></div><div>Absolutely. Once we have the grouping UI implemented in the mesh, we need to associate an XO icon with only a single activity at a time. The "current activity" provides this possibility. The granularity with which this property is known on the mesh is arbitrary. I don't think it needs to be event based, necessarily.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Who is allowed to cause a change to an activity's name? The initiator?<br>Anyone in the activity?
</blockquote><div><br class="webkit-block-placeholder"></div><div>Anyone. Equal share in tags, description, name, metadata, etc. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
How do tags work? Who can change them? If a child adds a tag, can a different<br>child remove it? (We're unlikely to support these for Trial3 anyway, I think)</blockquote><div><br class="webkit-block-placeholder"></div>
<div>This gets back to the subject of identifying tags by XO. In keeping with an "equal share" model, I think that the tags should remain in sync to the extent that the documents themselves do, though we need a little more discussion on that. I think that adding and removing of tags should be allowed by all.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Who can change the "sharing level" of an activity? Which transitions<br>between states are allowed?
</blockquote><div><br class="webkit-block-placeholder"></div><div>Again, anyone can. We're going to assume a basic trust model, with anyone in the activity being trusted to perform such operations. Scope can always be expanded. Scope can also always be contracted, but no one will ever be evicted from an activity once they are in it. The scope determines only who may join from this point forward; those within the activity must leave on their own will, and beyond that we will resort to social interaction.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">When a child is invited to an invite-only activity, how many of that<br>activity's members must they be able to see? The simplest thing to
<br>implement would be that they see that the inviter is in the activity,<br>but they don't know who else is in the activity until they join. An<br>alternative is that they see everyone in the activity at that moment (because
<br>the inviter tells them), and their mesh view continues to show those<br>members indefinitely. Are either, both, neither of these acceptable?</blockquote><div><br class="webkit-block-placeholder"></div><div>I prefer the latter in the sense that I'd like to know who is in an activity before I join it. On the other hand, I don't like the idea of transmitting a list of participants which could soon become stale. Ideally, the act of receiving an invitation (without yet opening it) should render the associated activity within the mesh just as the rest are represented. That would require a grouped list of XO icons and the list of participants as well. Again, I respect technical limitations here. If we can't dynamically represent the true list of participants on the mesh, then I would prefer to represent only the inviter rather than have the list get stale.
</div><div><br class="webkit-block-placeholder"></div><div>Also, we should probably revoke an invitation if the inviter leaves the activity. Ideally, the invitation would simply disappear as though it hadn't ever existed when this occurs. This automatically handles the case when the activity is no longer present on the mesh at all, which is a concern even if we don't revoke it when the inviter leaves.
</div></div><br><div>- Eben</div>