Indeed, especially if you use it in combination with their desktop applications (win or mac), because the "continuous client" functionality makes switching between devices fluid.
Definitely. I wish Apple would have bought them instead of rolling their own iMessages. Trillian consistently delivers messages to me wherever I am, and keeps everything property synchronized better than any other messaging tool I've used.
the windows client is equally excellent, and it's still the only IM platform (to my knowledge) that supports inline image sending, which I've gotten very used to. Plus the windows version handles IRC elegantly enough.
I use Trillian as my primary client, and have been for a while. Their newest builds sync all of my chats across protocols across clients, which is nice as I frequently switch between my Mac and PC for various things and it's nice to have my chats all sync'd
I must be missing something, because it sounds like they're creating one more IM protocol and claiming it will solve protocol fragmentation. If they want an open and federated protocol, why not back XMPP?
"IMPP is a binary protocol that works by establishing a TCP connection to an IMPP server, authenticating with that server, and then exchanging messages with that server in order to reach other clients. Over the years, best efforts have been made to keep the protocol flow reasonably compatible with XMPP with the long term idea of enabling federation between IMPP and XMPP servers. As such, the general flow for establishing an IMPP session somewhat mirrors that of XMPP: [...]"
That explains what IMPP is, but it doesn't answer the question of how/why it's different from XMPP.
And the "keep the protocol flow reasonably compatible with XMPP" part only makes it more curious. The more similar your protocol is to XMPP, the stranger it seems that you don't just use XMPP.
The answer may be just inertia; the spec says they started working on IMPP in 2001, back when XMPP was still very young. It could be that they've just built a ton of internal infrastructure on top of this thing and can't afford to move it all to pure XMPP. But that doesn't really explain why anyone else would want to use it in 2013.
Yeah, inertia. What we've tried to do with IMPP is to roll all of the features that IM users actually want into the core protocol versus just saying "it's open!" or "it can be extended!" and hoping someone else does the dirty work. We build the server side and we build the client side, which is important; it means we're not off dreaming up pie-in-the-sky features that would be absolutely horrible for a client developer to implemement.
We have some experience reverse engineering the rest of the IM protocols out there as well, and they all have their own issues which we kept in mind when building ours. At the end of the day, our actual motivations were simple: publishing the protocol is the right thing to do and so we did it. It's been on our TODO for 6+ years. :)
Some advantages: binary instead of XML, compression, shared state between devices.
Since Google has dropped XMPP, at this point it's possible that IMPP already rivals it's usage numbers worldwide (no word on users, but Trillian has >40m downloads).
At least one point in its favor is that it's smaller and lighter weight than XMPP. XMPP feels fairly over-engineered, and then you need to trawl through a huge pile of extensions to figure out which ones you will actually need to implement for interoperability.
XMPP is old, and mature. I'm afraid this "over-engineered" feeling comes to just about every successful technology that reaches such an age :)
Technology is full of people reinventing the wheel (sometimes better, obviously), but more often than not, unnecessarily.
Once you start to dig into any domain deeply, you encounter so many details you would never have imagined existed at first glance. Federated IM is no exception, and it's not easy. XMPP still has problems that are currently being solved that any new protocols won't even be thinking of for 10 years yet.
XMPP dates back to the early '00, which puts it right smack in the middle of the XML craze. It is as mature as it is bloated, a very strong subjective hurdle to overcome.
Or even better, are there any technical reasons why we couldn't just use email as an IM protocol? I'm thinking an extra header flag to denote that a message is an IM would be all thats needed to keep IMs out of your inbox (and then your mail app can separate IMs from emails). Or is IMAP not fast/powerful enough to handle this kind of messaging?
Because this isn't a new project for us; if it was, we'd absolutely be using XMPP. Our choices were to dump 10+ years of engineering and spend another two trying to wrangle XMPP to fit our needs (and do so across Windows, Mac, iOS, Android, BlackBerry, and Web), to keep our protocol but publish docs, or to continue to run yet-another-walled-garden.
The maker of an interoperable IM client not running an interoperable IM protocol just felt silly to us, so we decided to spend a week and publish something.
Mikael: Mainly inertia; we started this 10 years ago as well
and have massive amounts of development energy to consider.
What we lack is the peer review that a proper standard
can boast, but switching to XMPP at this point would
be a huge, huge project.
We decided to do the next best
thing (instead of doing nothing and running another walled
garden), which was to publish the documentation
to our protocol; we’re also going to consider building
a federation layer that uses XMPP in the future.
This way we get the best of XMPP in terms of
federation but don’t have to throw 10 years of
client and server work out the window.
1) We are obviously aware of XMPP, having been developing client-side interfaces to it for years.
2) We started this project in 2001 - around the same time Jabber was in its infancy - and as smacktoward notes, the main reason we're not using XMPP today is inertia. XMPP is great, but XML just isn't our personal preference.
We figure being more open with our protocol can't be a bad thing and so it's out there for folks to pick apart and send us feedback, which we'd love! Alot of our protocol was built with an eye towards XMPP federation as well; I actually had Trillian interoperating with Google Talk one afternoon but it seems like that ship may have sailed. :-\",
Could email be considered an "interoperable" instant messaging service? All it would take would be an email client's layout to be presented a bit more like a standard instant messaging layout and it might as well be considered a platform with the "back end glue" that they're talking about in the first paragraph.
On another note - and forgive me, I'm a bit clueless on this - is there any reason why email clients/providers couldn't have a standard way to do audio and video calls across services? Then they could do text messaging, file sharing, audio and video calls/messages. Any reason this couldn't happen?
The email protocol is built for reliable delivery instead of speed. It's not built for realtime communication. It was built so that mail goes through even if the destination's mail server goes down for a day or two. The fact that mail arrives mostly in real time today is purely accidental. There's no guarantee in the protocols to ensure that.
OTOH, I've learned to treat IMs as emails to a degree: often I'll send a message to someone who's online and expect that they'll likely see it. This might be a quirk of the clients we use, but it's very email-like.
The difference is less one of speed and more one of an ephemeral inbox. (In how it's treated by typical use cases; obviously, IM logging makes it less ephemeral.)
i have used trillian years ago and now rediscovered it through this. Their current client looks cool and the cross-plattform stuff seems to work really well and syncs chat histories and everything.
However today most of my IM stuff goes through Skype (still have a 7 digit ICQ Uin that i have been using from 1997-2010) and their mobile clients dont support it. Too bad, i still dont like Skypes offical mobile clients, they seem to be dog slow and eat alot of resources.
Skype is also a massive PITA on multiple machines/devices which i do all the time and it really annoys me.
This is interesting because it seems like they are proposing ways to decentralize existing services. Would it not be possible to add some sort of third party authorization in the app that registers your centralized ids in a decentralized database.
i.e.
(1) Open Trillian (or Adium)
(2) Sign in to each of the centralized services: AIM, Hotmail, Yahoo, etc. For each authorization, save that user name in the decentralized database in some sort of cryptographically signed form. (Maybe some algo similar to Bitcoin's solution to the byzantine general's problem).
(3) Now when someone on another trillian client wants to reach you, they can use any one of your centralized handles to search for you in the centralized database and connect with you directly.
(4) Lastly, some sort of handshake occurs between you and your friends.
I see no reason why this can't be fully compatible with XMPP once authentication has been performed by writing to a block chain and lookup of friends has been performed by reading from the blockchain.
This approach basically rebuilds out the network effect of "skype" and other centralized services via a trojan horse approach.
34 comments
[ 85.1 ms ] story [ 972 ms ] threadSource: https://www.trillian.im/impp/
And the "keep the protocol flow reasonably compatible with XMPP" part only makes it more curious. The more similar your protocol is to XMPP, the stranger it seems that you don't just use XMPP.
The answer may be just inertia; the spec says they started working on IMPP in 2001, back when XMPP was still very young. It could be that they've just built a ton of internal infrastructure on top of this thing and can't afford to move it all to pure XMPP. But that doesn't really explain why anyone else would want to use it in 2013.
We have some experience reverse engineering the rest of the IM protocols out there as well, and they all have their own issues which we kept in mind when building ours. At the end of the day, our actual motivations were simple: publishing the protocol is the right thing to do and so we did it. It's been on our TODO for 6+ years. :)
Since Google has dropped XMPP, at this point it's possible that IMPP already rivals it's usage numbers worldwide (no word on users, but Trillian has >40m downloads).
At least one point in its favor is that it's smaller and lighter weight than XMPP. XMPP feels fairly over-engineered, and then you need to trawl through a huge pile of extensions to figure out which ones you will actually need to implement for interoperability.
However, this does bring to mind the old xkcd: http://xkcd.com/927/
Technology is full of people reinventing the wheel (sometimes better, obviously), but more often than not, unnecessarily.
Once you start to dig into any domain deeply, you encounter so many details you would never have imagined existed at first glance. Federated IM is no exception, and it's not easy. XMPP still has problems that are currently being solved that any new protocols won't even be thinking of for 10 years yet.
Really? MIDI comes to mind, immediately, as a counterexample (it is underengineered, if anything, but it's being used widely to great success).
The maker of an interoperable IM client not running an interoperable IM protocol just felt silly to us, so we decided to spend a week and publish something.
http://blog.trillian.im/?p=2746#comment-31043
1) We are obviously aware of XMPP, having been developing client-side interfaces to it for years.
2) We started this project in 2001 - around the same time Jabber was in its infancy - and as smacktoward notes, the main reason we're not using XMPP today is inertia. XMPP is great, but XML just isn't our personal preference.
We figure being more open with our protocol can't be a bad thing and so it's out there for folks to pick apart and send us feedback, which we'd love! Alot of our protocol was built with an eye towards XMPP federation as well; I actually had Trillian interoperating with Google Talk one afternoon but it seems like that ship may have sailed. :-\",
On another note - and forgive me, I'm a bit clueless on this - is there any reason why email clients/providers couldn't have a standard way to do audio and video calls across services? Then they could do text messaging, file sharing, audio and video calls/messages. Any reason this couldn't happen?
The difference is less one of speed and more one of an ephemeral inbox. (In how it's treated by typical use cases; obviously, IM logging makes it less ephemeral.)
i.e. (1) Open Trillian (or Adium) (2) Sign in to each of the centralized services: AIM, Hotmail, Yahoo, etc. For each authorization, save that user name in the decentralized database in some sort of cryptographically signed form. (Maybe some algo similar to Bitcoin's solution to the byzantine general's problem). (3) Now when someone on another trillian client wants to reach you, they can use any one of your centralized handles to search for you in the centralized database and connect with you directly. (4) Lastly, some sort of handshake occurs between you and your friends.
I see no reason why this can't be fully compatible with XMPP once authentication has been performed by writing to a block chain and lookup of friends has been performed by reading from the blockchain.
This approach basically rebuilds out the network effect of "skype" and other centralized services via a trojan horse approach.