Online Desktop/People apps (short-term)

[Travis Reitter <treitter-dev netdrain com>]

At GUADEC, a number of the people-centric software people (from Soylent,
Banter, Empathy, Telepathy, Mugshot/Online Desktop) got together to
discuss some issues around integrating our work.

Here are some ideas for the short-term implementation, to get us rolling
on integration. Many of these based on other peoples' ideas, but here's
how I think it can all fit together. This isn't exhaustive, and mainly
focuses on issues related to people-centric apps.

Basic Architecture
==================

[Desktop People Apps] <-> [Empathy] <-> [e-d-s] <-> [Online desktop
server]

Desktop people apps will use Empathy to abstract cohesive People
objects. Right now, Empathy just handles Telepathy contacts (dynamic
people metadata), but Xavier has expressed interest in integrating e-d-s
support (static people metadata). For a useful People object, you really
need both the static and dynamic metadata. Simply connecting e-d-s
EContacts with live IM accounts will be a great first start, and Empathy
should serve as a good way to access additional metadata as we add
additional sources.

Offline Functionality
=====================

One important aspect of this system (especially from the embedded/mobile
device perspective) is the need for graceful degradation/useful
operation without an Internet connection. I think, and I believe we
largely agreed in the discussion, that we care mainly about the use
cases with intermittent network connectivity as opposed to use cases of
rare network connectivity. If you rarely have an Internet connection,
the Online Desktop won't be very interesting to you.

Without an Internet connection, we'll want to have a local cache for any
manual changes to our address book. This is for the sort of use case
that someone gives you their business card, and you want to add them to
your address book immediately, without having to wait for an Internet
connection.

As much as possible, I would like to avoid manual metadata entry. The
social networking model works very well for this. That way, you fill out
your own details once, mutually connect with people, and that's it. Each
time your friends update their profiles, your address book is updated
automatically. This substantially beats the old desktop equivalent,
where you have to manually enter and synchronize your contacts' full
profiles on each of your devices.

For the above case, I'd much rather you enter the person's email address
(or other ID), and it trigger a "friend request" when you connect to the
Internet next time. That way, you just enter a short string once, and
then get access to their full profile.

Evolution Data Server will make a decent local cache. Most Gnome apps
that care about an address book right now use e-d-s already, and since
it's based on VCards, it's fairly extensible. I think we all agree it's
not perfect, but it's good enough in the short term. And most of the
flaws I've seen/heard of from other people have been implementation
(some completely internal), not fundamental design problems.

Synchronization and Merging
===========================

Upon connection to the Internet, a daemon will download address book
changes from the Online Desktop provider and merge them into the local
cache (e-d-s). Since the Online Desktop server will be the master, it
will overwrite any older metadata (and probably delete any metadata not
in the Online Desktop data source). The only metadata that should be
pushed from the local cache toward the Online Desktop address book are
1. edits to your own profile and 2. people to add as contacts.

We don't want to expose the option to edit other peoples' metadata,
because that adds a lot of boring information we probably don't want to
edit anyhow. And you are the most authoritative source of your metadata,
so no one would have the right to edit yours (nor would they want to for
any non-malicious case). There are some exceptions (where you would want
to have private metadata for a specific person, like your own private
notes about that person), but I'm trying to generalize to get the bigger
picture.

Privacy and Data Ownership
==========================

Because the Online Desktop server software will be open source, anyone
will be able to run their own server. Distros may want to run their own,
for instance. And completely independent groups/companies could host as
well. You will have the option to choose your provider (including a
server of your own), or none at all (if you want your desktop to be in
"classic mode", without the Online Desktop integration). We hope this
should settle any privacy/data ownership concerns. I'm betting that most
people won't be terribly concerned about this, but I think this is a
good solution.

You probably won't want to switch Online Desktop providers willy-nilly
(since this involves a lot more state than a switch between email or web
hosting providers), but it hopefully shouldn't be too painful. And since
different Online Desktop providers should synchronize to a certain
degree (in the same way that one instance would synchronize with
Facebook, Flickr, etc.), we should be able to avoid fragmenting social
networks, etc.

As far as associating ownership/transmission policies with (meta)data, I
like the idea of the following levels: private, friends, family, public.
That seems like the simplest usable classification scheme. If it seems
useful, I would also suggest a "business" category, which be between
"family" and "public". This ordering is mostly in order from least to
most public, but there are so many exceptions that it may be best to
just consider them an unordered list.

We may want to have a "default license" to apply to anything public. For
legal reasons, this would probably have to default to strict copyright,
but it would be wonderful to be able to set this in one location (with
the ability to adjust on an individual content basis as well). This
would hopefully reduce the barriers to releasing generated content under
copyleft licenses for regular people.

Changes involved
================

1. Empathy needs support for Evolution Data Server contacts. I'm
planning to work with Xavier on this as soon as I finish and clean up
the Empathy <-> e-d-s integration I do within Soylent. By then I should
have a good idea of how they should work together and a decent API.

2. We need an Online Desktop preferences applet (mainly to choose your
Online Dekstop provider (if any)).

3. Something (probably the Online Desktop preferences applet) needs to
set up any private/public keys and Gnome Keyring Manager entr(ies).

4. A daemon to initiate and perform data synchronization and merging.
This could be a modified version of eds-sync (though that requires a
special version of e-d-s (the dbus port, I believe)). Maybe Conduit
could be use for anything beyond the address book - though I believe it
already handles that too. How should these two work together?

5. The Online Desktop server software needs to be generalized,
installable on individual machines, etc. However, this is really mid- to
long-term, and we'd be much better off using the instance that Havoc and
Owen are setting up for Gnome for testing/development until it's ready
for wider release.

Thoughts? :)

-Travis