> Not the geographically distributed customers, (unlike America Online)
AOL existed outside of America.
my fondest memories as a would-be computer hacker in the early-noughts was sitting in a BT phone box in the UK at 3am using the lineman opcode for free local calls to connect to my nearest AOL pop, so I could use one of their trial CDs with a fabricated or stolen credit card (I deactivated the trial before the first payment, I was not a total thief).
Sure but your experience is proof of how different the experience was. You had to call into an AOL pop using POTS and use a trial CD and some proof of payment (credit card) to perform this action. I can send my friend/coworker in Japan a Slack invite to their email and they can get started chatting on their smartphone in a minute or two. As I said, how is any of this really different than my grandfather sending telegrams? Or his father sending mail through the post?
I was making the argument that you made an assumption that didnt hold any weight.
regarding doing what slack can do, I think we do have a bit of collective amnesia about what was truly good and truly bad about what came before.
Slack does a lot of things, but its UX is actually pretty piss poor due to the bolt-ons (threads is just about the worst implementation I have ever seen), walled garden, weird account things (magic links~ if you want to see your other workspaces make sure you use the same email everywhere!), security (goodbye decent realtime bot api) and the client which feels slow despite using more resources than it should given its status as a program that needs to always be running.
To take one example of a worse system: IRC scales to tens of thousands of users on a single machine; doesn't have emoji or picture sharing though- but the bot API is simpler for sure, you can connect in one click if the person has an IRC client (or you pass a webirc link) - no signup needed.
I think the problem with slack is exacerbated in europe (or rest of the world in general), where the latency of fetching thousands of tiny assets or chats is many-many times higher than in California.
Also; the reason I had to do that was because my mum wouldn't permit a home internet connection; broadband was a thing at the time. Dial-up was not mandatory in 2002. IRC with dial-up was faster than slack is today too; you can argue that slack “does more” though.
> I was making the argument that you made an assumption that didnt hold any weight.
I claimed multiple things. Unless you think the single assumption being wrong in magnitude (I still maintain the majority of their customers were American) completely upends the entire thesis, then you're trying to treat this as some counterexample which... doesn't work here.
> Slack does a lot of things, but its UX is actually pretty piss poor due to the bolt-ons (threads is just about the worst implementation I have ever seen), walled garden, weird account things (magic links~ if you want to see your other workspaces make sure you use the same email everywhere!), security (goodbye decent realtime bot api) and the client which feels slow despite using more resources than it should given its status as a program that needs to always be running.
I'm not discussing the UX here I'm trying to talk about what Slack is doing differently than AIM.
What is "extremely high speed"? Do you have latency measurements from back then? I'm in Slack chatrooms with thousands of users. Your argument is essentially "it felt hella fast back then so what changed". Feelings are hard to dispute.
Mobile devices matter because they cannot maintain persistent connections. This by design necessitates a different architecture. AIM and IRC can have a single machine hold open a TCP connection and send and receive messages. A mobile device's modem wakes up briefly, performs some network chatter, then goes back to sleep. It's a fundamentally different requirement on the way the system is designed. IRC has evolved (through add-ons, not in the protocol itself) to shim this by using bouncers or having some sort of push notification based proxy for messages.
The other question is, how reliable was AOL? I have no idea how many outages they had, how long those outages lasted, nor what the impact was. Given the service was meant to be used as entertainment I suspect their SLA was one of best effort rather than the measured kind that Slack is leaning into (wrt using multiple CSes and using consistent hashing to pick which CS to send a message to, so architecture can be scaled as needed.)
I don't work for Slack but I work on high scale systems for a big company for a living. I'm pretty aware of the limitations of networks nowadays and the differences between systems in the dial-up era from now. Just the fact that Slack accommodates devices with push based semantics (mobile devices) and pull based semantics (anything that can open a persistent connection) is itself a large difference between systems of old and systems today.
Btw the TOC and Oscar protocols that AOL used have been reverse engineered and documented online so you can see for yourself at least at a protocol level what's different.
> Mobile devices matter because they cannot maintain persistent connections.
This isn't really a property of the device. It's an OS limitation. Nokia Series 60 didn't have a platform push service, so WhatsApp had to maintain a connection from the app to the servers to get messages without delay; it was not unusual to find Series 60 phones connected for 30+ days when I worked at WhatsApp. The newest versions of Nokia Series 40 had push, but older versions had to long-connect as well. Some mobile networks aren't great at letting connections work for longer times either, but some can.
But yeah, Apple only lets Apple keep connections open. Android doesn't have hard and fast rules, but background connections are likely to die, you should use push if you can. The push services connection is going to try to stay connected for a long time though.
BlackBerry had a working push system without hanging TCP connections. You made an HTTP call to BlackBerry, who then sent a UDP packet over the network direct to the device. It's a shame we've lost this architecture.
Huh interesting. How did the remote know the endpoint to send the UDP packet to? I would expect NAT and firewalls would make it hard to route inbound UDP? Did they do some sort of STUN style negotiation through HTTP?
BlackBerry operated it's own GPRS APN, so all Blackberries registered directly with it from the tower, and so it always had their up-to-date location on the network.
AOL existed outside of America.
my fondest memories as a would-be computer hacker in the early-noughts was sitting in a BT phone box in the UK at 3am using the lineman opcode for free local calls to connect to my nearest AOL pop, so I could use one of their trial CDs with a fabricated or stolen credit card (I deactivated the trial before the first payment, I was not a total thief).