[sugar] Telepathy IM/VOIP Framework

[Marco Pesenti Gritti]

Robert McQueen wrote:
> Hi folks,
>
> I'm Rob McQueen, one of the founders of an open source consultancy in
> Cambridge, UK called Collabora Ltd (5 of us in total, 3 in Cambridge).
> For the past year or so we've been working on a D-Bus based abstraction
> layer for IM and VOIP services called Telepathy. I had a chat with Chris
> Blizzard at GUADEC about our work and it seemed that there was
> potentially a really good match between what OLPC needs from messaging
> and presence, and what the Telepathy project has done and is looking to do.
>
> Telepathy is fundamentally a D-Bus API for talking to IM/VOIP servers.
> Your connections are established by backend processes called connection
> managers, which implement the API and present an abstraction which is
> the same whatever the underlying protocol. UI components are implemented
> as seperate programs using this D-Bus API, gaining immediate benefits
> like isolation from the protocol, language (and even license) of the
> backend code, as well as the ability to share the same connections
> between different processes, or not run parts of UI code when no
> communication activity is taking place.
>
> The Telepathy framework forms the basis of the Google Talk and Jabber
> implementation on the 2006 OS release on the Nokia 770. This means we
> already have a mature Jabber/XMPP backend component, and also a
> GStreamer-based streaming engine for establishing GTalk voice calls,
> both implemented in C with glib.
>
> We're looking now at integration of these components into the GNOME
> desktop, integrating presence into address book components, file
> transfers into Nautilus, porting Gossip to speak Telepathy (and hence
> any protocol you can think of) etc. People in the community are working
> on other backends including IRC, SIP, MSN and Oscar (AOL/ICQ/iChat), and
> we're working on adding video calls, file transfers, avatars and such
> like to the spec and our XMPP backend.
>
> Chris showed me some of the ideas about messaging and presence which the
> OLPC project has been working on, with the multicast protocol,
> sketching, avatars, and activities which people can collaborate on,
> which all looks cool, and has a really good overlap with things we've
> been planning to work on.
>
> The XMPP protocol already defines a mechanism for link-local messaging
> (JEP-174, http://www.jabber.org/jeps/jep-0174.html), using mDNS for
> advertising presence and your buddy icons, and sending point to point
> messages by bringing up direct peer to peer connections. We've been keen
> to implement this in our XMPP backend, and it's easy to conceive of some
> extensions to XMPP (that's what the X is for :D) which would allow the
> activities to be supported.
>
> As well as this the Jabber community is working on standardising
> Jabber-based whiteboard/sketching based on Jabber, which we'd love to
> see in Telepathy as well. One thing we'd need to look into would be
> working out a way of forming ad-hoc multi-user chats using multicast,
> but it's something which we could put forward as a JEP once we'd worked
> it out, and gain interoperability with desktop or other mobile (770 and
> friends :D) Telepathy implementations.
>
> Pondering scalability, on larger scale deployments, adding an XMPP
> server would allow the same stack to be used with a minimum amount of
> disruption. You could even leverage Telepathy's protocol support to
> implement a backend that's used in ad-hoc configurations that wasn't
> necessarily XMPP-based, but use XMPP when a server was available.
>   

Hi Robert,

Dan Williams has been looking in telepathy/galago. Also he has been 
focusing on the presence/communication part of sugar. He is in vacation 
right now but I'm sure he will answer in a more complete way than I can 
do when he is back.

Anyway, here is some (not so informed) brain dumping... There are a few 
things in telepathy that I think could be beneficial to sugar:

- The streaming engine. Supporting voip is in the plans but we have no 
code for it yet.
- XMMP communication protocol support. We have been to move to it at 
some point.
- User identification.
- Server support for scalability.
- Code reuse.

Things I don't think will matter that much to us:

- Support for multiple chat protocols.

Problems to solve:

- There are two basic use cases for the network that we need to keep in 
consideration (a simplification admittedly):

1 In school use, lots of users, server available.
2 Home use. Small groups of kids, no server available.

As far as I can tell Telepathy does not cover 2, That's a major problem. 
Is it solvable?

- Presence in Sugar is more than buddies presence. Activities are 
present. Services and buddies are present inside the activity. Buddies 
owns services. This somewhat map to the concept of group in instant 
messaging (and I suppose in telepathy) but it's not quite the same.
Dan API writeup can give you a good idea of our requirements:
http://wiki.laptop.org/go/Presence_Service_DBus_API

- Sugar communication API needs to be capable of more than IM and voice. 
It should be easy to implement a shared whiteboard or cooperative text 
editing on the top of it. Hopefully this is already covered.

- Sugar presence API need to be very simple to use and tidied to the 
framework. We don't want to expose D-Bus to the poor kids :) The 
solution to this might just be to implement our presence API using 
telepathy rather than exposing telepathy API directly.

- How does user identification work without a server? (This is totally 
an open issue for sugar too)

Finally, Ivan and his group needs to be involved in this. (Hopefully 
some of them are subscribed to this list). I don't know that much about 
their plans but a few weeks ago I think one of the main points was to 
have presence/communication API usable from web browser javascript, 
through a local web server.

Web Browser  -> Web Server -> Telepathy ?

Anyway, great to see you interested. Let's keep talking!

Marco