Activity Sharing

Summary

Little of this is set in stone, but we're fairly certain that we'll be using Jabber (both with a server and without) 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 non-server Jabber
• 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
• Activities working without a server, ~10 participants
• Mixed mesh/server (uncertain if this occurs in practice, see Activity_Sharing#Open_issues)
• Mesh with more than one 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

• Presence service
• Gabble
• Salut
• Jabber server

Presence service

• starting/maintaining connections to the server
• registering with the server
• discovering users + subscribing to their presence
• caching buddy info
• finding activities
  • incoming events
  • enumerate buddies' stuff
• filtering out non-relevant information

Invitations

• incoming channels should be turned into activities by the presence service
• it uses its map of buddies <-> shared activities to work out the corresponding MUC
• it emits a signal which Sugar can use to ask the child whether they would like to join the activity

Python objects

Activity:

• name
• type
• colour
• tubes
• 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 D-Bus messages ("D-tubes") or reliable byte streams or unreliable datagrams.

A tube might be connected to one person, or to a group of people. When a D-Bus tube is connected to a group of people, a mapping is made between the idenities of the people on the underlying protocol and D-Bus names.

It is up to the connection manager how tubes are implemented on top of its protocol.

Joining an activity

When a child joins an activity, we already know

• the type of activity
• who the participants are

The presence service has given us this information. We need to discover

• the colour of the activity
• what tubes the activity has

Any activity-specific discovery is implemented in an activity-specific manner.

Implementing activities in Gabble

• Each activity has a MUC (Multi-User Chat) on the Jabber server
• Each activity has a set of attributes, including the type of activity and the colour
  • Initally, these attributes will be stored by the participants
  • Later, we will use MEP to store the attributes
• Point-to-point tubes are implemented using Jabber stream initiation (SI)
  • No NAT traversal is necessary

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:

• publish one PubSub node per MUC
• map affiliations of the MUC members to t
• enforce permissions on that node according to the affiliations of the channel members

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 TCP sessions are hard to hijack, meaning that we don't need to sign every message when we are connected to the server.

We eagerly cache keys we see in order to provide continuity checking (the Bob I talked to today is the same Bob I talked to yesterday). What do we do when continuity is violated?

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

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