[sugar] Requirements for activity and buddy properties needed

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Either for Trial3 or shortly afterwards, we want to rethink the design of the
activity and buddy properties Telepathy interfaces, so the code makes more
sense. I want to get this sorted out before we go any further on implementing
activity invitations, since each activity invitation will have to
contain all the activity's properties; even if we defer the redesign til
post-Trial3, we should have the rethought version in mind when
designing invitations.

In particular I'd like input from Eben, since many of these are driven
by UI requirements, and from Dan Williams because of the Presence
Service angle.

Assumptions
===========

Please tell me if any of these are wrong:

Contacts ("buddies") have the following non-transient properties:

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

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)

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.

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.

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.

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)

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.

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.

Questions
=========

Can children change their names?

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)

Can children change their colours?

Can children change their photos?

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

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)

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

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)

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

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?

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFGuLp/WSc8zVUw7HYRAv8YAJ47ZblCBL3+5hbEWOaOT2t3PCU8zACcDjKZ
6hvKMUqytmPJepHwi4eo3sY=
=wYz6
-----END PGP SIGNATURE-----