Activity Sharing

== Summary ==

Little of this is set in stone, but we're fairly certain that we'll be using XMPP (both with a server and link-local) and that we'll be using Telepathy. Much of the protocol uses existing Jabber communications primitives, extending them where necessary. Telepathy abstracts the details of the underlying protocol from the activities.

Rationale: Telepathy

• has existing implementations of both server and link-local XMPP
• is based on D-Bus
• can be used from Python
• has support for voice/video calling using GStreamer
• is known to work in resource-limited environments

Priorities

In order:

• Activities working with a server, ~30 participants in the activity, ~100 contacts on the server.
• Activities working without a server, ~10 participants in the activity, ? contacts visible on the mesh.
• Mixed mesh/server (uncertain if this occurs in practice, see Activity_Sharing#Open_issues)
• Mesh with more than one RF channel (see Activity_Sharing#Open_issues)

We want to cover all these cases, but it's more important that we cover the ones towards the top sooner.

Components

• Sugar library & Telepathy python bindings
• Presence service
• Gabble (Telepathy XMPP server backend)
• Salut (Telepathy XMPP link-local backend)
• XMPP server (probably ejabberd or wildfire?)
  • Needs to be IPv6 compatible
  • Can't use non-free JVM if Java

Presence service

• starting/maintaining connections to the server
• registering with the server
• discovering users + subscribing to their presence
• caching buddy info (buddy icon, public key, nick, etc)
• finding activities
  • incoming events (i.e., invitations to activities, chats, voip calls, etc)
  • activities will be discovered by getting all present buddies on a server, then building a list of the activities which buddies report as their 'current activity'. Activities seen on the local link will be added to that list. Question: if an activity exists but is not anyone's "current" activity (i.e., all buddies switched to a different activity but still have the inactive one running in the background), does the PS care about that activity at all?
• deciding which information is relevant and retrieving it for sugar
  • For bandwidth and scalability reasons, the PS will have to filter or not subscribe to some presence information for buddies. It needs to figure out which buddies and which activities are more relevant to Sugar and only deal with those. It also needs to have an element of randomness for explorability and variability though.

Invitations

• incoming channels should be turned into activities by the presence service
  • one-to-one channels like an IM or a voice/video call can be made into a private activity
  • multi-user channels should be looked up in the map of buddies <-> activties to work out what shared activity they correspond to
• Emit a signal which Sugar can use to ask the child whether they would like to join the activity. Sugar should turn this into a visible Invitiation in the frame.

Python objects

Buddy:

• name
• colour
• avatar
• public key
• activities and which one is current

Activity:

• name
• type
• colour
• tubes that make up this channel
• chat (Telepathy text channel)

Tube:

• type (DBus, dgram, stream)

Tubes

A tube is a new Telepathy primitive for sending and receiving data, which can be to one person or to a group of people. Tubes can carry reliable byte streams or unreliable datagrams by analogy to TCP or UDP, although some different semantics such as reliable datagrams might be more appropriate for a multi-user case. It is up to the connection manager how tubes are implemented on top of its protocol.

A more advanced idea is to represent the multi-user tube as a D-Bus bus, and have the connection manager make a mapping between the participants in the tube and D-Bus bus name. Clients can then take advantage of D-Bus's serialisation and the bindings so that they have to do less protocol work.

In terms of the Telepathy API, we will create a new channel type which will have methods for enumerating existing tubes and requesting new ones. The channel might be attached to an existing channel (such as a MUC), in which case it will be automatically closed when the underlying channel is closed.

Joining an activity

Before we join an activity, the presence service should be able to tell us:

• the name, type and colour of the activity
• the Telepathy channels that comprise the activity

When we join, the library will find out from the Telepathy backend:

• the tubes active within the activity
• the full list of participants

Implementing activities in Gabble

• PEP (Personal Eventing Protocol) will be used for buddies to publish their information such as name, colour, key, avatar and current activities.
• Point-to-point tubes are implemented using Jabber stream initiation (SI)
  • No NAT traversal is necessary currently
• Each activity has a MUC (Multi-User Chat) on the Jabber server
  • Multi-user tubes are implemented by sending messages over the MUC
  • Initially, each participant broadcasts tube information in his MUC presence
  • Later, we will use MEP to store the tube information
• Each activity has a set of attributes, including the type of activity and the colour, which we need to get from somewhere.
  • Initially, we could publish it in the per-buddy PEP nodes.
  • We should move it to some per-MUC storage.

Implementing activities in Salut

We haven't thought about this in detail. It might use Sjoerd's Link-local MUC.

MEP

MEP is something we have made up in order to store activity metadata on MUCs.

MEP stands for MUC Eventing via PubSub, by analogy to PEP (Personal Eventing via PubSub). MEP simplifies PubSub for MUCs, much as PEP simplifies PubSub for personal information.

A MEP-compliant MUC server will:

• provision one PubSub item per MUC
• map affiliations of the MUC members to to node editing permissions

Voice/Video

Use of voice/video is limited by the fact that Gabble only supports point-to-point voice/video calls. Salut currently does not support voice/video calling.

Trust model

We assume that we can trust the server, and that encrypted TCP sessions are hard to hijack, meaning that we don't need to sign every message when we are connected to the server, and can trust that JIDs belong to their owner.

We eagerly cache keys we see in order to provide continuity checking between server and mesh contacts, and mesh contacts at different times (the Bob I talked to today is the same Bob I talked to yesterday).

Privacy

Can we do friends-only activities? Two parts to this:

• hiding the presence of the activity
• guarding the MUC with e.g. a password

Open issues

• how do we implement migration of activites from the mesh to the server, and do we need to?
• how do we register accounts with the Jabber server when laptops are activated?
  • how JIDs are assigned
  • what happens if a laptop is moved between activation servers
• are participants in an activity equal, or is there one person who is hosting each activity?
  • this may be different depending on the needs of specific activities; games may want to have a 'master' who hosts, but chat-type communication is less structured
• is formatted text (XHTML Basic) a requirement, or is plain text sufficient?
• is the Jabber presence model appropriate for our needs, given that it requires that we subscribe to everyone in order to be able to see them?
  • will we be able to discover activities if we are not subscribed to the participants' presence?
  • is it ok because we have presence from link-local contacts we are not subscribed to anyway?
• what does the Sugar API look like?
• Finding your friends when you have more than one mesh channel and more than one server:
  • If you're sitting next to someone and want to make them your friend, but you're both on different mesh RF channels, you won't see them on the link-local. Can we do something better than searching a directory?
  • Maybe we can put something on the screen (a visual tag of some sort) which encodes their identity (a JID or key or whatever) which can be photographed with the camera and then we can deal with finding the person on the server or mesh.
• Inconsistent mesh/server presence (mixed mesh/server)
  • By definition if you can see the server then anybody you can see on the mesh can also see the server. However, depending on what the mesh frame hop limit is, it is conceivable that (server - you < hop limit) and (you - them < hop limit), but (server - them > hop limit), leading to them not seeing the server. We need to know more about the low-level operation of the mesh before knowing if this will be a real problem.
• What do we do when key continuity is violated?

Implementation plan

Getting from here to there.

Phase 1

Basic multi-user chat, some regressions from existing presence service.

Sugar (or telepathy-python)

• API for chats

Presence Service

• Connecting
• Registering
• Discovering users + subscribing
  • colours
  • key
  • nick
• Discovering activities

Telepathy Spec

• PEP Buddy Info (OLPC-specific?)

Gabble

• PEP Buddy Info
• PEP Avatars

Server

• List people

Phase 2

Telepathy Spec

• Tube interface

Gabble

• Extend MUC presence with tubes
• MUC tubes

Sugar (or telepathy-python)

• API for tubes

Phase N

• Add tubes to Telepathy D-Bus API
• Gabble
  • implement point-to-point tubes
  • implement IM->MUC migration
• choose between Ejabberd and Wildfire for the server
• video conferencing activity