

Decentralizing Trillian - jamaicahest
http://blog.trillian.im/?p=2746

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

------
acomar
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?

~~~
ndr
"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
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
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. :)

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

~~~
CrazedGeek
Not me. Trillian's iOS IM client is one of the few that's any good.

~~~
spartango
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.

~~~
uptown
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.

------
JeffJenkins
Obligatory: [http://xkcd.com/927/](http://xkcd.com/927/)

~~~
duskwuff
And "instant messaging" is even one of the examples it uses!

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

------
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?

~~~
Wilya
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.

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

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

