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

31–36 of 36 posts

Re: Decentralizing Trillian

#31

Post by Wilya »

nathcd wrote: post #25

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/provi…

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.

Re: Decentralizing Trillian

#32

Post by huhtenberg »

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…

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.

Re: Decentralizing Trillian

#33

Post by tripzilch »

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…

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

Re: Decentralizing Trillian

#34

Post by saraid216 »

Wilya wrote: post #31
nathcd wrote: post #25

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/provi…

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

Re: Decentralizing Trillian

#36

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

Post reply on HN