[sugar] Requirements for activity and buddy properties needed

[Eben Eliason]

>
>
> Assumptions
> ===========
>
> Please tell me if any of these are wrong:
>
> Contacts ("buddies") have the following non-transient properties:


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.

* a name to be displayed in the UI (Unicode string)
> * a public key (binary data)
> * a color (ASCII string constrained to be in the format #xxxxxx,#xxxxxx
>   where x is any hex digit)
> * a JID (Jabber ID, which is the unique identifier in XMPP) on the server
>   (for people you see on the server this is obvious, for people you see on
> the
>   mesh you want to be able to remember it for future reference)
> * an "avatar" photo or image (binary data, JPEG or PNG, ~96x96 pixels)


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?

* an IPv4 address for legacy activities (ASCII string, "123.45.6.78",
>   deprecated)
>
> Properties will only be added slowly, so it is acceptable if each new
> property needs changes to the connection managers and to Presence Service.
> Properties beyond the above will be optional.
>
> Each child has a "home" XMPP server which is (at least initially) the one
> they
> were assigned to when their XO was activated. The server has a globally
> unique DNS name (I'll assume here it's foo.schools.laptop.org) and the
> child's
> JID is of the form something at foo.schools.laptop.org.
>
> Whenever the child's XO and the XMPP server both have unrestricted
> Internet
> access, the XO will be able to log in to the XMPP server - they aren't
> forced to log in to the nearest XMPP server, the same way you can log
> in to olpc.collabora.co.uk (which is in London) from America. Whenever
> the XO can't make a TCP connection to its "home" XMPP server, it will
> only have link-local connectivity using Salut, with all the restrictions
> that imposes.
>
> Activities are implemented as chat rooms - there is a 1<->1 mapping
> between (shared/shareable activity instances) and (chat rooms). The chat
> room implements the text messaging and Tubes interfaces.
>
> A child can be in multiple activities.
>
> Shared/shareable activities have an ID which is pseudorandom, assumed to
> be globally unique, and immutable.


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.

Activities have the following properties:
>
> * Name (human-readable Unicode string, changeable)
> * Color (string in the same format as buddy color, immutable)
> * Type (string in the format of a D-Bus service name, immutable - this
>   is what sets the icon in the mesh view)
> * Tags (list of human readable Unicode strings, semantics unspecified at
> the
>   moment, changeable)


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?)

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.

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.

which are set when the activity is created, and are required to be
> visible in the mesh view to children who have not joined the activity.


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).

No other information is required to be visible in the mesh view, and
> properties will be added sufficiently slowly that it's acceptable to
> require
> changes to Gabble, Salut and PS for each new property.


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.

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.

It is acceptable if changes in the activity name aren't visible in the
> mesh view for a minute or so, but they must be reflected in the mesh
> view eventually.


Sounds perfectly reasonable; I don't expect any changes in the mesh to be
immediate, though the less lag the better.

If activities need activity-specific "properties" these will not be needed
> by
> the mesh view, and the activity will have to use its Tubes channel (or
> something) to propagate these. (Loosely: they're not our problem. :-)
>
> Activities can either be:
>
> * unshared (from Telepathy and the PS's point of view, equivalent to not
>   existing)
>
> * invite-only (exists as a chat room, but not publicized; does not
>   appear on the mesh view unless you've been invited; does not appear in
>   server room listings; any participant can invite others to join in)
>
>   (This type does not exist at the moment, but is a goal for Trial3)
>
> * public (may appear on anyone's mesh view; anyone may join)


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.

When someone is invited to an activity they will be sent enough
> information to put it on their mesh view.
>
> If buddy groups are implemented, we plan to make them purely a UI thing -
> if sharing an activity with "My Class" is implemented at all, the UI
> should do this by creating an invite-only activity and sending
> invitations to everyone in the group "My Class". This keeps the
> Telepathy interface relatively simple.


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.

Children who are not in an activity can't change anything about it
> and if Presence Service tries this, it should expect it to fail.


Agreed.

Questions
> =========
>
> Can children change their names?


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.

If so, how acceptable is it for other children to continue to see the old
> name
> indefinitely? Required, recommended, acceptable, grudgingly allowed,
> unacceptable? (We can reduce traffic significantly if we're allowed to
> save the child's original name to the XMPP roster)


We also talked about the possibility of a pet-name system by which a child
would be locally known with a particular name.

Can children change their colours?


Yes, but no UI for it is available yet.  This will be mutable.

Can children change their photos?


Yes, same as above.

Can the child's "home XMPP server" change, i.e., can their JID change?


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.

Is ip4-address still required or can we drop it? Is an IPv6 address required
> in buddy properties?
>
> Do we need the concept of a buddy's "current activity"? (Currently it's
> implemented, but in practice is write-only)


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.

Who is allowed to cause a change to an activity's name? The initiator?
> Anyone in the activity?


Anyone.  Equal share in tags, description, name, metadata, etc.

How do tags work? Who can change them? If a child adds a tag, can a
> different
> child remove it? (We're unlikely to support these for Trial3 anyway, I
> think)


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.

Who can change the "sharing level" of an activity? Which transitions
> between states are allowed?


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.

When a child is invited to an invite-only activity, how many of that
> activity's members must they be able to see? The simplest thing to
> implement would be that they see that the inviter is in the activity,
> but they don't know who else is in the activity until they join. An
> alternative is that they see everyone in the activity at that moment
> (because
> the inviter tells them), and their mesh view continues to show those
> members indefinitely. Are either, both, neither of these acceptable?


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.

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.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070807/3d5ac45a/attachment-0001.htm