Activity Sharing

WARNING: The content of this section is considered DEPRECATED and OBSOLETE It is preserved for historical or documenting reasons. see Activity sharing for current information 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 participate in as seen from their PEP node. 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: real name (permanent once the user account is created) nickname (alias in Telepathy-speak) colour buddy icon (avatar in Telepathy-speak) public key (permanent once the user account is created) activities current activity Activity: name activity ID (SHA256 hash) type colour tubes that make up this channel default activity 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. When a tube is to a group, some different semantics may be more appropriate, since a shared stream is not coherent. 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 have created a new channel type which has 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 default activity chat channel Tube negotiation channel When we join, the sugar activity module will find out from the Telepathy backend: the tubes 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). Buddy nicknames (and colours?) can be changed at will; the buddy's real name cannot change, and is used to identify them in the UI. 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 do we need to migrate activites from the mesh to the server, and if so, how do we do it? on the interface side, This could be a button next to the one that closes an activity, or it could be in the wired network box. how do we register accounts with the Jabber server when laptops are activated? how JIDs are assigned as of 2007-05-14 we generate JIDs using a hash of the public key 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? the protocol supports both, activity authors can do whichever they prefer 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? It looks like GTK's gobject, with a finite set of special modules for dbus, viewer, and other services. I'll add a link when I have more documented. 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? How do we implement searching for people as described in the HIG? Specification issues: "Plural" methods to save D-Bus round trips "Give me signals" methods? (cf RequestAvatars) Why do we use a(su) for activities? Shouldn't it be a{su} or a{us}, since the activity ID and room are both meant to be unique? Should activity/current-activity migrate to be part of activity properties? 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