Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decentralizing Trillian

blog.trillian.im

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Decentralizing Trillian

#21

Post by ceruleanscott »

A few notes:

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. :-\

Re: Decentralizing Trillian

#22

Post by ldubinets »

Edvik wrote: post #6
chatmasta wrote: post #2

Who else is thinking "woah, Trillian still exists?!"

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.

The screenshot function is quite a handy tool too.

Re: Decentralizing Trillian

#23

Post by ceruleanscott »

smacktoward wrote: post #14
ndr wrote: post #11

Earlier quoted context omitted.

"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 establis…

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 co…

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. :)

Re: Decentralizing Trillian

#24

Post by mcrider »

acomar wrote: post #8

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?

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?

Re: Decentralizing Trillian

#25

Post by nathcd »

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?

Re: Decentralizing Trillian

#26

Post by kayoone »

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.

Re: Decentralizing Trillian

#27

Post by ricardobeat »

smacktoward wrote: post #14
ndr wrote: post #11

Earlier quoted context omitted.

"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 establis…

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 co…

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).

Re: Decentralizing Trillian

#28

Post by ceruleanscott »

acomar wrote: post #8

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?

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.

Re: Decentralizing Trillian

#29

Post by mweibel »

acomar wrote: post #8

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?

One of cerulean studios' has actually answered this question in a comment on the blog:

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.

Re: Decentralizing Trillian

#30

Post by stormbrew »

MattJ100 wrote: post #16
lambda wrote: post #12

Earlier quoted context omitted.

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/

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 excep…

SMTP is old. XMPP is at best adolescent.
Post reply on HN