There seems to be a lot of confusion about what the Telepathy-KDE project is and what it has to do with Kopete. I’ll try and explain in this blog post everything, so that it is clear to everyone.
First of all, Telepathy is a framework for writing applications that can use real-time communication and collaboration features. In Telepathy, there are the so-called connection managers that connect to IM and similar networks and the clients that use those connections over D-Bus. This allows dividing the several tasks of an IM client to several applications, which makes it easier to reuse code and easier for applications to add collaboration features without caring about protocols, contact lists, presence status and all that stuff.
In Telepathy-KDE what we are trying to do is to integrate Telepathy with the KDE Plasma desktop. What we imagine is not to have a monolithic IM client like kopete or empathy but to integrate all the features of an IM client directly into the desktop. For this reason, we are going to add the following components into the KDE SC:
- A presence plasmoid. This will be a plasmoid sitting in your notification area or somewhere else, showing your online status and allowing you with a popup to change status, to enter a status message, etc…
- A contact list application. This will be a standalone application that will just show the contact list. It will of course have all the necessary actions to start a chat or a call or do something else with any of your contacts.
- A chat window application. This will be a standalone application providing just the chat window. When a new chat starts, it will be auto-launched via D-Bus service activation and allow you to chat.
- A VoIP call window application. This will again be a standalone application providing the call window, also auto-launched to handle calls. This is actually KCall, what I wrote in last year’s summer of code, but it won’t have the contact list and won’t be named “KCall”.
- An approver daemon. This will be a daemon sitting in the background and listening for incoming channels. When somebody requests that you start doing something with him (be it chat, video call, play a game together, share your desktop, etc…), it will show a KNotify popup allowing you to accept or reject the request.
- A file transfer daemon. This will be a daemon that will be auto-launched like the chat and call windows when you want to do a file transfer to or from one of your contacts and handle that file transfer for you.
- The nepomuk integration daemon. This is an implementation detail, really internal, not shown to the users. This will allow you to have metacontacts by pushing all of your contacts into the nepomuk database and defining relations between them. It will also allow at some point sharing contacts with akonadi and other cool stuff.
In the future, other components could be added, such as a logger daemon that logs all your chats into files or into a database or something like that and of course it will be very simple to add collaboration features to other applications for doing anything with your contacts. For example, krdc already has telepathy integration and it is possible that if someone requests you over telepathy to share his desktop, you could use krdc to view his desktop, without caring about firewalls or anything. Unfortunately, the server side of this is currently only implemented in gnome, so only a user using gnome can currently share his desktop with you, but that will be fixed in the future.
As a sidenote here, telepathy also allows you to share D-Bus connections over the IM network, which makes it extremely easy to add collaboration features to an application that has no idea about networks or protocols. With this feature, called D-Bus tubes, all you have to do in your application is to expose a D-Bus interface which will be called from the remote side using normal D-Bus calls, as if the other side was running on the same computer. With this feature, we could add collaboration features to many KDE applications in the future very easily. Unfortunately, this currently requires a patch in Qt that has not been merged yet and it is not yet certain if it will make it for Qt 4.8 (which actually screws the whole feature, but we can still hope it will be in Qt 4.8, so that we can start using it in KDE 4.7 or 4.8).
To get to kopete now, as you realize, there is no much place for kopete in all this. So, as soon as we merge all this in the KDE SC, kopete is going to get out of there. All in all, it has not received much development in the last years and even many of its former maintainers are now looking towards Telepathy-KDE, so I don’ t think we have any reason to keep it around. In addition, kopete’s code is not very much reusable in its current form, so we are not going to use it at all. Many people have stated that this may be a bad idea, but we have actually tried to port code from kopete and it didn’t really work, so we decided to do a new implementation from scratch.
I hope that pretty much explains everything now. Let’s stop talking about kopete and let’s start working on Telepathy-KDE 😀
PS: If you want to get involved with it, come and find us on irc in #kde-telepathy on irc.freenode.net.
Gkiagia's Blog 
Wow, nice feature-list. Thank you very much!
Great! Can’t wait 🙂
Just a question.. all those features like DBUS tubes, cool desktop sharing and such stuff: Do they depend on the usage of a certain protocol? I somehow doubt that it will be possible to share my desktop via ICQ. It simply sounds too god 😉
As far as I know, it is possible with any protocol. The protocol is not really used for anything else than just find out where in the world the other peer is and find out how to bypass firewalls etc, and then a p2p tcp socket is used that has nothing to do with the protocol. At least all protocols that support voip should be able to support that, since it’s basically the same thing in the network level, the only difference is what type of data is sent over the connection. I don’t know many details about that though, and I could be wrong, but that is what I believe it works like.
“As far as I know, [desktop sharing] is possible with any protocol”
Not true, sadly; you need a somewhat extensible protocol to use Tubes. Currently, Tubes are implemented on XMPP and link-local XMPP. In principle they should also be implementable in MSN (which is proprietary, but has a mechanism for application-specific streams!) and in SIP (which is open and extensible, so it could be extended).
“The protocol is not really used for anything else than just find out where in the world the other peer is and find out how to bypass firewalls etc”
That’s not currently true, although when we enhance the XMPP implementation to be more like that, application authors shouldn’t notice any difference, apart from improved performance 🙂 This sort of thing does need a bit of protocol support.
Ok, thanks for making this clear Simon. I wasn’t sure at all about that.
This is awesome… I really like the improvements you guys are doing to the KDE SC… the one and only problem is that I never know if I can Install kde to my people because all this changes… every version is better than the previous one… I thought that 4.6 woul be enough… but I’ll wait till this and the octave cantors backend are ready to start spreading kde… sorry for my bad english… i’m late and i’m going, I cant check it
This sounds nice but I have 1 question:
Will you develop a new application which uses telepathy so that I can still have something like kopete/kmess but with telepathy on the background?
I don’t really like the idea of having to put a plasmoid on my desktop every time I want to chat, and evel less the idea of having it there, also don’t really want to go to the tasbar if I want to change state and then to another place to see contact list, etc.
I’m not saying it’s a bad idea I may use it sometime, but I chat rarely and I’d like something simple.
We are not aiming at a monolithic application, but this will be transparent to the user. You will still do everything in the normal way that you are used to with kopete, but the only difference is that the system tray icon will actually be a plasmoid, so you won’t start it like you do with kopete, but you will just add it there and then set yourself as online.
Of course it would be possible to have a status application that is not a plasmoid, and it may be done at some time later, but it’s not a priority at the moment.
Kopete is essentially replaced by the contact list application and chat window application. Of course, Telepathy is much cooler because you won’t NEED the contact list application open to see who’s online or to initiate a chat, you can do that through a plasmoid or potentially through applications (think: “I want to work on this Calligra Words document with someone on my contact list”).
Sorry I misunderstood contact list was not a plasmoid was an app, but will it have options to change states?
The cool thing about telepathy is that you don’t manage stuff from one specific application, so you could change the presence from the plasmoid and also from any other application that can manage the presence (it could also be in kontact or even in kword if you want, but it doesn’t make much sense)
So, this looks to me a “feature request” more than a question… we should investigate if people will be scared if they are not able to set the presence from the contact list.
Yes I guess it is a feature request now that I think about it, and yes I would definitely be scared if I’m not able to change status in the same window that I have contacts. and about configuration, like creating account, will the wizard be accessible through the contact list? or also from the status plasmoid.
“In Telepathy-KDE what we are trying to do is to integrate Telepathy with the KDE Plasma desktop.”
Just to be clear: would Telepathy-KDE be runnable *without* bringing in libplasma (let alone the Plasma shell!), say if I wanted to write a Telepathy-KDE-based KDE IM app that would run under non-KDE desktops like GNOME, XFCE etc?
All parts will be runnable except obviously the presence plasmoid. As I just said in another comment above, it would be possible to write a replacement for the presence plasmoid that does not use plasma, but that’s certainly not a priority. We already have the presence plasmoid almost ready and we will just use it.
Regarding other applications, for example krdc or a game or something like that, you can still use their telepathy features without using Telepathy-KDE. There are other IM clients that use telepathy as well, such as empathy, which is a monolithic application at the moment. If at least one application is there to put your accounts online, then all the other applications will be able to use these connections.
Now the “Telepathy-KDE-based KDE IM app” is something that doesn’t really make sense to me. “Telepathy-KDE” is not a framework, it is a set of clients that will offer telepathy integration in KDE. If you want to write another KDE-based IM client that uses the telepathy framework, that’s fine and it has nothing to do with our project, probably.
impressive. looking forward to it. i hope it will be better maintained than kopete. If it is, then kde makes another revolution on the desktop 🙂
Yes. …and imagine the possibilities of an integration with the other PIM apps. 🙂
This all sounds great!
Kopete is a HUGE application that does all the instant messaging in your desktop. This means that is very hard to maintain.
Telepathy-KDE is not “an application”, is “a SET of small application” that follow the Unix philosophy[1]: “Do one thing and do it well”
So there will be several applications that just do one small task (a contact list application, a chat application, an approver application, etc.)
This means that each application will be easier to maintain because the code will short and therefore easier to understand
[1]http://en.wikipedia.org/wiki/Unix_philosophy
OK, I’m scared.
First, anyone who writes software designed to work around my firewall scares me. I have my firewall in place for *a reason*. If I want an app to have access to the network, I want to have to explicitly enable that myself.
Second, AFAIK, DBus was not designed with remote access in mind. What are the security implications here? Has the extra attack surface been mapped out and studied? What is being done to block new attacks made possible by this tech?
Well, if you want to have total control of the firewall, then just don’t use this feature and do the whole thing manually. Nobody forces you to use it. It is just there for convenience, for people that have no idea of what is this firewall thing that they probably have on their router that was given to them pre-configured by their ISP. But this is just fine imho, because it just enables the correct port at the correct time and then closes it again when it is finished, so I don’t see any issue at all. This is what you would do manually anyway.
I have no idea actually about the security of D-Bus tubes, maybe somebody else with enough knowledge can answer that. I don’t think you are the first one to think of this, so it is probably secure enough.
ICE (which is what Tubes use to do direct peer to peer connections) is not about going around firewalls, it is to go through NATs. NAT make it easy for client-server connections to go through, but not for peer to peer connections. And NATs are not firewalls (although often the same software can do both), don’t confuse a NAT for a security device.
Yep, thanks for the correction. I actually had NAT routers in mind when I was talking about firewalls.
A few comments about security
1) You actually need to be a “friend” of someone else adding him to your contact before being able to do anything.
2) You can actually block any incoming or outgoing channel using an approver. If you are a system administrator you probably want to allow some channels and filter others (gkiagia, we should definitely also add some setting for “admin” blocking before “user” blocking and before “user accept/refuse” popup for both incoming and outgoing channels to the default approver)
3) Please note that “dbus protocol” and “dbus server” are two different things. DBusTubes create a “peer-to-peer” dbus connection, that is just a “connection that uses the dbus protocol to communicate (the format of the messages that are sent between applications)”. The DBus server is completely outside this. I could have a similar thing using a streamtube (that is just a tcp socket exported using the im protocol as an additional network layer) and using xml-rpc (for example) as protocol
So what you have is NOT something that can use a remote dbus server, but just a CONNECTION BETWEEN 2 APPLICATIONS that talk to each other using the dbus protocol.
So again: NO you can’t access remote DBus Server using DBusTubes, you could access only the application on the other side. And NO, you won’t se the application on the other side on your DBus server.
Also for additional security you can have xmpp encrypted with SSL/TLS, so also tubes will be encrypted.
4) About firewalls, as it was already said in the previous comments, you are just bypassing NAT not a firewall.
Well, that’s OK then. Because none of my friends use Windows or ever get hit with malware.
I’m not sure what form these approvers will take yet, but ok.
Ah, OK then. I misread the article to mean that they effectively proxied a connection into your session bus. If it’s just IPC then that’s a lot saner.
Ah. Traversing NAT is totally different from (and much less scary than) bypassing firewalls. Cool.
Thanks for clarifying.
Great news.
Also it would be great if the upcoming logger will be able to import logs from other IMs (I have in mind the Kopete and Pidgin clients).
I forgot to mention that, there will be a kopete migrator just like the migrators used for migrating KDE PIM data to akonadi that will import everything from kopete if you like, so this will probably be supported. I’m not sure about pidgin though, but we’ll discuss that in time.
What protocols will be supported / are supported already by telepathy? Are there e.g. plans for native skype support? (don’t know whether that’s legally possible…)
I think integration with akonadi is a really important point because it fits very well into the kde desktop vision. It would be really nice and quite logical to me if i would be able to add IM contacts via the addressbook and other PIM related applications could make use of this data.
In general this separation of protocols and presentation is a good idea. Using this it is conceivable to create (without too much effort) a plasmoid that presents a facebook-style contactlist that can be opened from the taskbar, a krunner plugin that starts a chat or filetransfer integration into dolphin…
There are existing connection managers for jabber (including gtalk and facebook), msn, sip, link-local xmpp and all the protocols supported by libpurple (yahoo, msn, gadu, icq, whatever…). It’s a big list. Not all of them support all the features though, but at least text chat is supported everywhere.
Skype support is neither legally nor technically possible without license and specifications from skype, which is never going to happen. Of course, if skype wants, they could make their own closed-source connection manager, however, it will still not be possible to do voip through this connection manager because voip is actually handled by the UI client, not by the connection manager (as an exception to the whole design of telepathy). So, I don’t think this will ever happen.
Integration with akonadi is in the plan, don’t worry about it.
Actually there already exists at least one non-free Skype connection manager. It is shipped on every Nokia N900. So it is definitely possible, that said. That won’t be on standard Linux distributions unless Skype dramatically changes it’s licensing.
I saw some blog posts a few days ago about skype revealing the encryption algorithm used by skype so I think that it might technically be possible to have an open source skype connection manager now, but I don’t know anything about licenses and legal issues though.
There is an existing connection manager for Skype, in use under Maemo, but it is closed source: http://maemo.org/packages/view/telepathy-spirit/
Would be nice if they could release telepathy-spirit for other common architectures (technically that shouldn’t be a problem)…
Also I found this thread: http://blogs.skype.com/linux/2009/11/skype_open_source.html
I mean it is already quite old, so I don’t know what the status is…. did it already happen? Anyway, if there would be something like a closed source core that UI-developers could use for an own skype gui implementation, I imagine that it would be possible to wrap this very library in a telepathy connection manager, wouldn’t it?
Ah, just found that they *did* release something: http://developer.skype.com/public/skypekit
its still beta, but that could be a way to go maybe, right? Maybe I’ll take a look at it if I have some time left…
Nice plans, but I see problems in practice: who will do the “dirty” work, and reimplement all the protocols from kopete? This is realy hard work. Even in kopete/kde4 we are still missing some protocol plugins like IRC from kopete/kde3. Please don’t remove kopete before not all functionality is provided by telepathy.
Actually telepathy currently provides more protocols than kopete, and in a far better state. IRC is supported too. See my other comment above as well.
Why don’t you keep the Qt patch in kde-qt patches? For example, before compiling plasma, you can check for a file created by this Qt patch at build time, and turn telepathy support on if that file exists.
This Qt patch adds two new public methods, which is bad but unfortunately necessary. If we add those public methods in kde-qt, then that will mean that kde-qt will be binary incompatible with the vanilla Qt, and if distributions ship that and then the nokia guys decide that this patch should be different and these methods should not be there or with that signature, that means distributions will have to break binary compatibility, something that they are struggling to avoid.
Won’t this waste an enormous amount of resources, and make things slower? If I just chat with a couple of people there will be several applications running, duplicating lots of runtime data, and DBus messaging introduces latencies.
And what about Non-KDE desktops? Does this mean I can no longer use KDE Technology to chat while e.g. using FluxBox? The Plasma stuff won’t be available then.
It may actually consume some more resources (I don’t have facts, but I imagine this is true), but it is worth it because this design gives much more possibilities. This is not just about having a chat window, but about having any kind of communication and/or collaboration feature in any kind of application.
For the thing with other desktops, I have already replied in previous comments. It would be possible to write applications that substitute all the plasma-specific stuff, but we are not aiming at this at the moment.
On the topic of other desktop or desktop technologies, I think it would be best to point out that it is not a matter of “substitute all plasma-specific stuff”, but rather either using an already existing alternative implementation (I am pretty sure at least a GObject/GTK+ based one exists for all components, right?) or creating such an implementation with whatever technology stack is deemed appropriate (e.g. Python, Java, whatever, as long as it supports D-Bus)
Yep, this is all true. And yes, a GTK telepathy client exists, this is empathy.
what about KCall backend which was using gstreamer, do you think you will be able to use phonon? Is that issue resolved?
No, the call UI will still use GStreamer. In my opinion, this is not an issue. GStreamer is fine. All people in the telepathy meeting have accepted it and also many other kde multimedia people have accepted it as well as the best solution in this case, so I don’t see any problem at all there. Phonon is not designed for such use cases, it is designed to be simple and handle simple application needs.
|GStreamer is fine
What about gstreamer0.10-plugins-good’s dependencies on gconf and gnome libs in most distros?
Well, we’ll have to live with these dependencies. Anyway, Qt itself already depends on glib and all the underlying telepathy components (telepathy-mission-control, telepathy-gabble, etc…) also use glib and other gnome libraries (gnome keyring, gconf, etc), so we’ll just live with them.
I would actually be surprised if GStreamer or its plugins had any dependency on GNOME libs. First because it is supposed to sit at a level lower in the stack and second because there is ongoing work to move all sharable parts of GNOME into GLib/GTK+ and get rid of the libgnome* ones
I really hope they’ll remove these dependencies. How can you be a low level API, standard or whatever if you *depend* on DE level libraries?
Have to live with it is kind of loser’s way. Maybe we’ll just require full gnome to be installed to use KDE, no? *
* There is a sarcasm here somewhere.
There is no gnome dependency in gstreamer, except for gconf in gstreamer-plugins-good because of the gconf audio/video source/sink elements. These are special wrapper elements that construct the relevant audio/video source/sink element that the user has selected in gstreamer-properties, which is part of gnome and saves these preferences in gconf. Packagers could easily split those elements in a different package if it pulls in many gnome stuff, just request it from them.
I’ve set exactly that above. gstreamer and it’s plugins should not depend on gconf, Gnome, KDE, or whetever else. It’s not logical to do.
Besides, thay can in theory(?), but they do not in practice. Nobody seems to care enough to do it. Yes, there are bug reports.
WTF?!? So, I’m going to need 3 separate media backends to run KDE?
DragonPlayer (well, as of 4.4.5 at least) depends on Xine. KCall depends on GStreamer. And although Phonon has xine and gstreamer backends, they are deprecated and have problems which I don’t think are going to be fixed (e.g. FLAC/Vorbis files get the first (or was it last?) couple of seconds cut off in playback) so I’ve got VLC installed for that.
Xine, GStreamer, VLC. Three media backends, each with their own plugins for all the same codecs. What. The. Fuck.
That’s complete asshattery.
OK, it may not be your asshattery. So I could be ranting in the wrong place. But it would be nice if someone in KDE could take responsibility and clean this shit up.
DragonPlayer does _not_ depend on Xine.
You only need to have Phonon-Gstreamer installed, at which point you only have 1 media backend.
Actually moving to Phonon-Gstreamer from Xine is a good idea anyway as Xine does not work normally (sound issues with notifications) and causes knotify4 to eat ~100 Mb of RAM (on my X86_64 system at least).
I’d prefer mplayer backend though, but it does not exist in Debian’s repository.
The Debian packagers disagree.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491622
Yeah, dragonplayer does some hacks with xine there… Just get rid of it and use vlc. Xine is a dead project anyway.
You’re wrong. Just ldd /usr/bin/dragon | grep xine
Also, I thought that phonon-vlc was the way to go. I’ve certainly read other KDE devs indicate that vlc is more stable than the others, and that more work will be going into that backend in the future. e.g.
http://amarok.kde.org/blog/archives/1171-Rapid-Progress-in-KDE-Multimedia.html
So, uh, which backend should I be using again?
You should use phonon-vlc for phonon. Hopefully, the other backends will slowly die and then we will have solved the long standing phonon problem that one needs to code the same feature in a thousand backends to get it working.
Phonon-gstreamer would have been nice to have though, but there is no maintainer for it and it is a pain to use it on other platforms (while vlc can be used quite easily), something that means that we would still need other backends for windows and mac.
So basically, yes, you will need to have two multimedia frameworks installed together with the kde sc, vlc and gstreamer. The world is not perfect, especially when it comes to multimedia support in linux… I think I’d blame the GStreamer guys for that, for not targetting cross-desktop and cross-platform (well, they say they do, but they don’t convince me…). If they did, we wouldn’t have so many multimedia frameworks around and maybe phonon wouldn’t exist as well 🙂
Whatever you’ve heard from the Phonon people, its a lie. Phonon is strictly an abstraction for simple media playback. The GStreamer backend just uses one GStreamer element (playbin). So really Phonon is in no way comparable to GStreamer.
“Whatever you’ve heard from the Phonon people, its a lie.”
If I were you I would retract that. Sounds like you imply Phonon developers are purposefully spreading wrong information.
“So really Phonon is in no way comparable to GStreamer.”
Which, given its design, is obvious, isn’t it?
GStreamer is a multimedia framework, Phonon isn’t.
Dude, chill out :p
That’s obviously true, and isn’t being implied anywhere (let alone directly said).
uhm.. I haven’t tried it, so obviously I can’t really say if I like it or not, but generally speaking I prefer a monolithic application for IM.
Anyway I’m not using Kopete since long time so it’s departure doesn’t change much to me. I’ll stick with Pidgin in KDE if all this shouldn’t please me.
Awesome architectural effort anyway!
It sounds really great and I’m looking forward to it.
Kopete is pretty crappy overall, so don’t worry if you hear a few people trying to keep hold of it. You guys are doing the right thing! Kill kopete with fire.
Cheers!
Can I request a look at missing but desirable protocols to be added to this new IM framework? I *have to* use MS communicator at work and currently I have to fall back on pidgin because it provides a SIPE plugin.
Yes, there is already an open bug for this vis-a-vis Kopete, btw!
Anything supported by pidgin also works with telepathy. We have the telepathy-haze connection manager that is able to load pidgin protocol plugins.
Do you know how one gets this working i.e. telepathy-haze to use pidgin protocol plugins?
Thanks.
Normally you just install telepathy-haze and then both the empathy account creation dialog and our telepathy-accounts-kcm list pidgin protocols as available. If this is not working for you, try asking the telepathy mailing list or #telepathy on irc.freenode.net.
I read that telepathy-haze exposes libpurple protocols and yes it does — except the one i’m really looking for: sipe plugin!
I’ll check this on IRC. Thanks.
I hope it supports proxy.
Sure it does.
This sounds all pretty promising! I’m just not sure about the separate application thing… on slower machines it takes easily several seconds for applications to start up. I wouldn’t be pleased, if I had to wait that long every time I open a chat window… Just something to keep in mind, when developing new and shiny technology.
And is it planned to integrate IM logs with desktop search?
I don’t think we’ll have serious performance issues with that design, but we’ll keep it in mind. Maybe we could try to do this via kdeinit somehow to speed it up a bit.
Integrating IM logs with desktop search makes total sense to me, so probably yes.
As a former Kopete maintainer, i’m not really looking forward to telepathy. But well…
Whoops, I’m sorry, it’s my fault. I didn’t mean it. I should have used different wording to allow space for others. I actually had in mind Duncan Mac-Vicar, Matt Rogers and Will Stephenson, but that is probably not all of the kopete guys. I will edit it.
Kphone uses gstreamer as backend. What backends are for example QuteCom and Twinkle using? Is it possible to take code from them to use Phonon and its independency?
That would mean to reinvent the wheel and implement again all the network streaming stuff in our handler. No way. I prefer using farsight and gstreamer that work out of the box.
What kind of interface is planned for telepathy-irc? Moreover how does it compare to other IRC clients like Konversation. Or does irc mean something different in this context?
IRC will be shown in the interface in the exact same way as a Jabber conference room.
You’ll have a standard list of people in the room, messages will appear like any other chat.
I don’t intend to go out of our way to support many IRC specific features, (typing /kick or /away or anything), if you want a feature rich IRC client, stick to an IRC client.
Hi, sorry to hear that fixing bugs in kde is so unpopular, all those “developpers” can think about is reinventing the wheel and make promises which are never fullfilled (remember 4.0 should be released with kdepim based on akonadi? current status? i am not even thinking about this).
But hey! Waste the users’ and developpers’ time! A decline on those numbers is super tabu in the community.
I cant wait for this final realise of app
for now, there is no history for conversations
I cant synchronaise contact in gadu gadu account
So I am looking forward for what You give to us in future
Hi, I read this toady and I’m wondering if this framework will replace microblog stuffs, such as choqok?
No, this is out of scope for telepathy, at least for the moment.
I found a strange thing with KDE Telepathy IM chat client. I installed Fedora Core 17 on my laptop 2 days back. Yesterday when I started the laptop, I found my status as ONLINE in this messenger and was showing around 90 contacts. I did not configure any of the accounts but I found 2 accounts automatically got configured.
It looks like the accounts were using my unix username. Can you please help me on this? Is this something strange or this is a normal behaviour? Are there any default chat rooms which automatically get configured? I am little bit worried as I feel this might be dangerous. Please help.
Many Thanks,
Nikhil
This is not something that usually happens, but it could happen in certain cases:
1) You are or were using Empathy either in this installation or a previous installation with the same $HOME. Empathy accounts should also appear in KDE Telepathy.
2) Your distribution patches KDE Telepathy to have certain accounts there by default (I could think of link-local XMPP and perhaps irc, although that sounds like a terrible idea)
3) You or someone else with access to your computer did configure accounts and you don’t know/remember it.
Most likely it’s #1
Thanks for reply !!
It is a fresh installation including complete disk partitioning. Also, I did not configure any of the accounts in Empathy too. I am the only one who access the laptop and hence there is no possibility of anybody else configuring their own account. Also, I did not provide my email address anywhere during the installation process.
Is this something to worry about? Please reply.