Activity Sharing: Difference between revisions
(activity ID is a hash) |
No edit summary |
||
(14 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{Deprecated |see [[Activity sharing]] for current information}} |
|||
⚫ | |||
⚫ | |||
Little of this is set in stone, but we're fairly certain that we'll be using [http://xmpp.org XMPP] (both with a server and link-local) and that we'll be using [http://telepathy.freedesktop.org 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. |
Little of this is set in stone, but we're fairly certain that we'll be using [http://xmpp.org XMPP] (both with a server and link-local) and that we'll be using [http://telepathy.freedesktop.org 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. |
||
Line 55: | Line 57: | ||
Buddy: |
Buddy: |
||
* real name (permanent once the user account is created) |
|||
* name |
|||
* nickname (alias in Telepathy-speak) |
|||
* colour |
* colour |
||
* buddy icon (avatar in |
* buddy icon (avatar in Telepathy-speak) |
||
* public key |
* public key (permanent once the user account is created) |
||
* activities |
* activities |
||
* current activity |
* current activity |
||
Line 77: | Line 80: | ||
== Tubes == |
== 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 |
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. |
||
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. |
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 |
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 == |
== Joining an activity == |
||
Line 90: | Line 92: | ||
* the name, type and colour of the activity |
* the name, type and colour of the activity |
||
* the Telepathy channels that comprise the activity |
* the Telepathy channels that comprise the activity |
||
** default activity chat channel |
|||
** Tube negotiation channel |
|||
When we join, the |
When we join, the sugar activity module will find out from the Telepathy backend: |
||
* the tubes |
* the tubes within the activity |
||
* the full list of participants |
* the full list of participants |
||
Line 138: | Line 142: | ||
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. |
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). |
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 == |
== Privacy == |
||
Line 149: | Line 153: | ||
== Open issues == |
== 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 do we register accounts with the Jabber server when laptops are activated? |
||
** how JIDs are assigned |
** 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 |
** 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? |
* 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 |
|||
**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 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? |
* 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? |
||
Line 160: | Line 166: | ||
** is it ok because we have presence from link-local contacts we are not subscribed to anyway? |
** is it ok because we have presence from link-local contacts we are not subscribed to anyway? |
||
* what does the Sugar API look like? |
* 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: |
* 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? |
** 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? |
||
Line 166: | Line 173: | ||
** 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. |
** 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? |
* What do we do when key continuity is violated? |
||
* How do we implement searching for people as described [[OLPC Human Interface Guidelines#Shared_Activities|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 == |
== Implementation plan == |
||
Line 225: | Line 238: | ||
* choose between Ejabberd and Wildfire for the server |
* choose between Ejabberd and Wildfire for the server |
||
* video conferencing activity |
* video conferencing activity |
||
[[category:Telepathy]] |
|||
[[category:Collaboration]] |
Latest revision as of 11:45, 13 June 2008
SummaryLittle 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
PrioritiesIn order:
We want to cover all these cases, but it's more important that we cover the ones towards the top sooner. Components
Presence service
Invitations
Python objectsBuddy:
Activity:
Tube:
TubesA 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 activityBefore we join an activity, the presence service should be able to tell us:
When we join, the sugar activity module will find out from the Telepathy backend:
Implementing activities in Gabble
Implementing activities in SalutWe haven't thought about this in detail. It might use Sjoerd's Link-local MUC. MEPMEP 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:
Voice/VideoUse 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 modelWe 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. PrivacyCan we do friends-only activities? Two parts to this:
Open issues
Implementation planGetting from here to there. Phase 1Basic multi-user chat, some regressions from existing presence service. Sugar (or telepathy-python)
Presence Service
Telepathy Spec
Gabble
Server
Phase 2Telepathy Spec
Gabble
Sugar (or telepathy-python)
Phase N
|