[sugar] Obtaining Buddy objects as contacts are encountered

[Simon McVittie]

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

At the moment the Presence Service API assumes we're subscribed to the
presence of every contact we'll ever encounter, which obviously can't scale to
a school.

When child joins an activity we're in, the presence service needs to be able
to give us a Buddy object for them without making network round-trips -
otherwise the activity will have no way to identify them. We can't just ignore
them (omit them from the GUI) until we've made network round-trips to ask
the server about them, because they might start participating in the activity
before we get the server's reply, and it would be confusing to get messages
from an apparently nonexistent buddy (also, activity authors are
unlikely to handle this correctly).

At the same time, we don't want to have two Buddy objects in the PS process
representing the same child, and have to do some sort of coalescing process
when we work out that they actually represent the same person; so from just
the information we immediately have when we first encounter someone,
we should be able to make the decision whether two contacts are in fact the
same.

For the server case, the JID is constructed as follows:

	hex(sha1(public key)) + '@' + configured server

To avoid spoofing we need to require that the server will only create new
accounts (or almost equivalently, allow login to an account) if the client can
demonstrate knowledge of a private key for which the public key's hex SHA-1
is the username part of the desired JID.

For the link-local (mesh) case, I believe the idea is that the public key
and other OLPC info is in the mDNS record, so by the time we can interact with
someone, we already have all relevant information about them? If so, and we
put the corresponding server-JID in the mDNS record, then we can again always
know which child we're talking to.

Again, to avoid spoofing we need to require that the mDNS record demonstrates
knowledge of the private key; perhaps it could include a signature of the IP
address or IP:port or whatever, and a timestamp, made using the private key.

Given this, we should be able to create Buddy objects from arbitrary Telepathy
handles (a handle represents the unique ID on the instant messaging system)
and know at least whether they're distinct; the Buddy object can then have
signals it emits as its alias, colour, etc. arrive. The worst case in the GUI
will be that a grey XO with no name appears and starts participating, and
shortly afterwards, its colour changes to the right colour and it gains the
right alias.

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

iD8DBQFGQzsTWSc8zVUw7HYRAh0vAKC9jDBXbJRaLSV9+YMeF/SMdn/+aQCg7Tkh
2QSiCi/K46rR+pRVEbOdb8k=
=m749
-----END PGP SIGNATURE-----