5 ms·

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 ope

by acomar 13y ago

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?

frenchy 13y ago
Indeed, I was expecting that they'd come up with a solid reason why XMPP couldn't do this. I don't see how IMPP is really any different.
ndr 13y ago
"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: [...]" Source: https://www.trillian.im/impp/ https://www.trillian.im/impp/
- smacktoward 13y ago
  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.
  - ceruleanscott 13y ago
    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. :)
  - ricardobeat 13y ago
    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).
- drivebyacct2 13y ago
  If anything it makes the original question even more pertinent. It's the "what" but not the "why".
lambda 13y ago
I was wondering this myself. 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/ http://xkcd.com/927/
- MattJ100 13y ago
  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.
  - marssaxman 13y ago
    The over-engineered feeling tends to be present from the start with technologies based on XML...
  - stormbrew 13y ago
    SMTP is old. XMPP is at best adolescent.
  - huhtenberg 13y ago
    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.
  - tripzilch 13y ago
    > XMPP is old, and mature. I'm afraid this "over-engineered" feeling comes to just about every successful technology that reaches such an age :) Really? MIDI comes to mind, immediately, as a counterexample (it is underengineered, if anything, but it's being used widely to great success).
mcrider 13y ago
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?
ceruleanscott 13y ago
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.
mweibel 13y ago
One of cerulean studios' has actually answered this question in a comment on the blog: http://blog.trillian.im/?p=2746#comment-31043 http://blog.trillian.im/?p=2746#comment-31043 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.

by acomar 13y ago

frenchy 13y ago

Indeed, I was expecting that they'd come up with a solid reason why XMPP couldn't do this. I don't see how IMPP is really any different.

ndr 13y ago

"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: [...]" Source: https://www.trillian.im/impp/ https://www.trillian.im/impp/

smacktoward 13y ago
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.
- ceruleanscott 13y ago
  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. :)
- ricardobeat 13y ago
  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).
drivebyacct2 13y ago
If anything it makes the original question even more pertinent. It's the "what" but not the "why".

lambda 13y ago

I was wondering this myself. 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/ http://xkcd.com/927/

MattJ100 13y ago
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.
- marssaxman 13y ago
  The over-engineered feeling tends to be present from the start with technologies based on XML...
- stormbrew 13y ago
  SMTP is old. XMPP is at best adolescent.
- huhtenberg 13y ago
  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.
- tripzilch 13y ago
  > XMPP is old, and mature. I'm afraid this "over-engineered" feeling comes to just about every successful technology that reaches such an age :) Really? MIDI comes to mind, immediately, as a counterexample (it is underengineered, if anything, but it's being used widely to great success).

mcrider 13y ago

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?

ceruleanscott 13y ago

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.

mweibel 13y ago

One of cerulean studios' has actually answered this question in a comment on the blog: http://blog.trillian.im/?p=2746#comment-31043 http://blog.trillian.im/?p=2746#comment-31043 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.