Skype, Reverse engineering and MSN/YM!
Here's some ways to think about this. The first point is to understand what interop means. There are 3 ways of linking IM/Audio/Video networks.
1) At the network level. Transparently route chat, voice and video by linking the networks. Skype can't do that because there is no central network. MSN, YM! and AIM have a big centrally controlled part of the system even though a lot of the communication is P2P so they can, at the cost of running that big central system.
2) At the server level. This is what some Jabber servers do. Because all comms go partly through a server they can be switched. It's the same as 1) except that anyone can run a jabber server.
3) At the client. GAIM, Trillian and others let you have one client that speaks multiple protocols. You need an official account with any system you want to talk to but it blurs the differences between them.

So if there's a library that can be built into cient code that duplicates the Skype protocols, 3) can be built. And 2) can be built where it's appropriate (eg Asterix PBX)

Then look at two conversations that are happening on the Skype forums already. Building audio/video stream access into the Skype API and release of a Naked Skype which is a library that provides the API without having to have the Client.

So if you can reverse engineer the protocol, there's no point in trying to build a better Skype client when Skype are shipping a new one every 2 months. You're just getting involved in a code race. If you can produce a naked skype API library with more capability, you can fill in the holes that Skype can't address. This might be something like a Linux version or a Nokia Series 60/80 version or a Skype that runs on a Linksys Wifi router. But again you're up against a potential code race. By producing something, you'll identify a market for Skype who will then produce it or bolt your new capability into their next release.

So we can begin to see that Skype don't need to open the protocol. What they do need to do is to make that protocol widely available in forms people want. Which means a naked Skype library with full access to chat, voice and video. And a friendly licensing regime to go with it. Then we can have Skype in GAIM/Trillian, 3rd party Skype-SIP gateways, Skype on weird platforms and so on.

A note about Security. If Skype have built their encryption properly (and I believe they have), then exposing the code and protocol will make *NO* difference to the strength of the encryption. Which means that if the USA/UK require backdoors for government access they're out of luck. if Skype put a backdoor in, the 3rd parties will produce a version with no backdoor. So I think this announcement of reverse engineering the protocol will keep Skype honest and keep the governments out. At least for Skype to Skype conversations even though Skype to POTS will still be at risk because you can always tap the POTS interconnection.

So all in all I see this as doing nothing more than providing a spur to Skype to keep writing code, building innovation and shipping it. As long as they keep doing that, there's no stopping them, and no downside for the users. And the fact that the protocol is reverse engineered will make no difference.

Now look at that idea of a naked API library. This is exactly the unfulfilled promise of LibJingle. Skype have had 9 months now to replicate it. I think they'll ship something before there's any use of LibJingle outside the official GTalk client.

[ << Damn Bots ] [ Keeping Skype honest >> ]
[ 16-Jul-06 8:54am ] [ , , ]