[Telepathy] status of empathy and XMPP in telepathy

[Daniel Pocock]

On 26/04/16 02:45, Michael Vetter wrote:
> Hello,
> 
> I am using XMPP with Gajim and Conversations daily.
> On one device I would like to use mainly GNOME software. I never used
> Empathy because as far as I know it had only basic XMPP capabillities
> with no Extensions.
> 
> So today I took some time to try to research about its actual
> capabillities. Usually I compare clients on [1] an [2] though both are
> of course no guarantee to be up to date. Both do not feature Empathy at
> all.
> 
> I assume, that many people just think it has the same capabilities as
> Pidgin has. I am not sure if that is true at all since the switch to
> Telepathy. Does somebody know about the differences?
> 
> Like mentioned in another thread I have to agree that it sometimes
> looks like not much development is currently going on.
> 
> I would like to dedicate some time to Empathy/Telepathy to help with
> the work for XMPP. For this reason I looked around in the
> telepathy-gabble repo [3].
> 
> So far I never wrote XMPP software, only used it. Because of that I
> wanted to start with implementing a small extension for a start, I
> thought about XEP-0333 [4].
> Then I could see how it goes and hopefully continue from there.
> 
> I would like to ask if there is someone on this list who worked with
> telepathy-gabble/empathy who could guide me in my initial steps, it
> would be quite appreciated.
> 
> Furthermore I wanted to ask if there are any plans about the
> development of XMPP inside Empathy/Telepathy that I might not be aware
> of.
> 

telepathy-gabble appears to be based on the telepathy-glib bindings

A lot of the newer work appears to be using TelepathyQt instead of
telepathy-glib.  My first suggestion would be to look for any attempts
to do XMPP with TelepathyQt or possible start such an implementation.
Look at how I started the telepathy-resiprocate project for an example.

Secondly, telepathy-gabble has a focus on the Google Talk version of
XMPP, especially for voice and video.
- the NAT traversal parameters are hard-coded to use Google servers,
making it useless if neither user is a Google account
- this Google emphasis is irrelevant now anyway, since Google is not
supporting XMPP properly at all any more.
Bottom line: don't be afraid to lose the Google support, go for standard
ICE and TURN.

Finally, for media streaming, it would be good to come up with a common
solution for both telepathy-resiprocate and telepathy-gabble (or a
TelepathyQt-based successor to it).  This would potentially mean using
the same TURN server parameters for either protocol.  Maybe Farstream is
relevant to this, but I haven't looked at that closely enough yet.
Whatever approach we use for media streaming, we should aim to
eventually have full WebRTC interoperability, one way to get that is to
use the media stack from Chromium.

Regards,

Daniel