[MichaelGG]

But aren't most of those messages point-to-point? Not that I'm trivializing 70M/sec! But for the most part, it's pretty straightforward right? No multi-client support (so no desktop client that requires server sync). Most messages(?) are to one recipient only, right? So send the message, send an ACK, deliver message, deliver read ACK? It seems like the perfect thing for a scale-out architecture. Even group chat can probably just be split into multiple messages, one per recipient.

Not that it's not a lot of work, but isn't most of it just hard work engineering? Add hardware, deal with bottlenecks. Versus having to come up with some novel new datastructures and inter-server communications?

SMTP sends a ton of messages, too. I don't see why an IM system couldn't take essentially the same concept, where one small cluster of services is responsible for the mailboxes for certain individuals.

[rdtsc]

Phone signaling is also just making calls point to point. Very simple. Well except that making it not crash, making it scale, handling corner cases, legacy devices, regulatory stuff.

One can sort of take a high level look at a large class of system and just say "it sends messages from one part to another". A financial transaction sends one message from one account to another one. A lot of sites and businesses are "just" get data from database send to web page, then send updates back to the database. Pretty simple.

The devil is in the details and in the proof of work. If it is simple, ok, do it. Not being facetious, you might actually succeed. Just try it. Erlang is a good choice for it, start with that.

[nly]

> SMTP sends a ton of messages, too. I don't see why an IM system couldn't take essentially the same concept,

Hint's in the name: instant messaging. For the most part, nobody stops using SMTP if it takes 2 minutes to deliver an e-mail

[coldtea]

>Hint's in the name: instant messaging. For the most part, nobody stops using SMTP if it takes 2 minutes to deliver an e-mail

Well, I don't think anybody would stop using IM too, if it took say 10 or 20 seconds to deliver an IM.

[mjmahone17]

Honestly, you might not immediately, but if it happened often enough, you probably would switch clients. Back in the day, if AIM managed to screw up enough of mine and my friend's conversations by not sending messages quickly enough (and then sending 30 all at the same time), we'd have moved off it if something better was found.

[atgm]

I think this was a big factor in why AIM trumped ICQ in America. ICQ had that "sending mail" icon that took a few seconds (or more) to "send" your message and it didn't quite feel instant.

[krrrh]

It was also a ui issue. ICQ originally had an interface which didn't show a running log of the conversation. It was more like sending email with presence indicators and a 450 character limit. Though it also had an IRC-like mode that was rarely used. I remember finding AIM and MSN so different when they emerged as the 'instant' aspect, typing indicator, and running log encouraged rapid-fire short messages and gave a conversation-like feel.

[atgm]

> ICQ originally had an interface which didn't show a running log of the conversation.

The earliest version I remember, before 98a, had a history button that would show the running log on the top of the message box window, which was nice.

The nicest thing about ICQ for me back then was the fact that the message disappeared when you sent it -- it wasn't there filling your taskbar or occupying your mindspace.

[31reasons]

Good! you got the technology, now go get those 450 million users :)