[sugar] Requirements for activity and buddy properties needed

[Dan Williams]

On Tue, 2007-08-07 at 19:44 -0400, Eben Eliason wrote:
>         
>         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.

Fine, we just pick one.  However, the term "Buddy" has been in the API
forever, so it means everyone using any presence stuff would need to
update their activity.

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

My feeling is that if avatars don't get into FRS, so be it.  We have
larger fish to fry.

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

Right; how activity versions get represented in mesh view/on the network
(if at all) is an area of active debate right now.  We need to take a
hard look at what we can do for Trial-3 + FRS.

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

If we want some sort of tags in Trial-3/FRS, we may have to just have
pure text tags.

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

This has the same issue as tags.  If the property is shared across the
network, you must reconcile them.  Perhaps we pick "last person wins" :)

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

For trial-3/FRS, we'd talked about doing this via filtering and not any
real encryption, since the encryption stuff was still up in the air
(obviously, that's an implementation detail and neither activity authors
nor children would see a difference with or without real encryption).

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

Right.  This means that (like Simon probably really wants) that name is
network-immutable but locally-mutable.  Like AIM; your nick is always
the same, but I can make you show up as Eben.  That's fine.  Makes some
things simpler.  Ah, the 'pet names' thing you mention below.

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

I think lag is more acceptable here since the data set is larger.  We
may be able to do this as pull rather than push.  I feel like photo
changes shouldn't really be pushes.

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

This could be difficult.

Dan

>         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
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar