iChat A/V is back from the dead, and it's a warning about your stack

What happened

Someone sat down with a packet capture, a copy of macOS Tiger, and a stubborn refusal to accept that iChat A/V was gone. The write-up on pipetogrep.org walks through what it took to get video calls flowing again between vintage Macs in 2026 — more than a decade after Apple quietly deprecated the service and turned off the AIM-backed presence infrastructure that iChat leaned on.

The short version: iChat's A/V stack looked like SIP from a distance and like a one-off from up close. Session setup rode on top of AIM's OSCAR protocol for presence and signaling. Media negotiation borrowed enough SDP-flavored vocabulary to be legible, but with Apple-specific extensions and quirks that no off-the-shelf SIP server will emit. The media itself was H.264 over RTP — a real standard, finally — but wrapped in RTCP feedback behavior that modern libraries don't speak without coaxing. The author describes rebuilding the signaling path from scratch, stubbing out the AIM dependency, and poking the client until it stopped hanging up on the first SIP INVITE equivalent.

There is a working demo. Two Power Macs, one modern Linux box pretending to be the AIM relay and the STUN helper, and a video call. It is not production software. It is a receipt.

Why it matters

The interesting thing isn't the nostalgia. iChat A/V shipped in 2003. For a brief window it was the easiest video calling experience on any consumer OS — plug in an iSight, double-click a buddy, done. Skype was clunkier. Google Talk's video came later. Microsoft was still shipping NetMeeting. Apple built that experience on a tower of custom protocols, custom NAT traversal, custom codecs-with-asterisks, and a centralized directory service — and when any one of those pieces went away, the entire user-visible product died with it.

That's the pattern worth sitting with. The protocols weren't secret in a cryptographic sense; the author got them back by reading bytes off the wire. They were dead because the services around them were dead. The AIM directory is gone. The STUN helpers Apple ran are gone. The push notifications that woke the client are gone. You can hold the client binary in your hand and it is still inert, because the half of the system that lived on Apple's servers has been garbage-collected.

Compare that with the stuff from the same era that still works. IRC from 1988 still works. SMTP from 1982 still works. XMPP, which Google Talk briefly federated with before pulling the plug, still works between the servers that stayed up. The thing those protocols have in common isn't age — it's that they were specified before a single vendor controlled the deployment. Nobody can turn off IRC. Someone can, and did, turn off iChat.

The HN thread leans heavily on 'Apple abandoned us' — which is true but not very interesting. The more useful read is that every real-time communication product shipped in the last five years has the same shape as iChat A/V. Zoom, Teams, Meet, Discord voice, FaceTime, WhatsApp calls, Slack huddles: a thin client that is useless without the vendor's signaling fabric, their TURN relays, their push wake-ups, their account directory. The protocols are often standards-adjacent — WebRTC, SRTP, Opus — but the glue that makes a call actually connect is proprietary and operated. Pull the glue and the client is a museum piece.

What this means for your stack

If you ship a real-time product, the useful question this project raises is: what does the ten-year archaeology look like for *your* system? Not whether you'll still be running it — you probably won't — but whether anyone could get it working again from the client side alone.

For most teams the honest answer is 'no,' and the honest fix is to notice which pieces of your stack are genuinely replaceable versus which ones have quietly become single points of permanent failure. The signaling server you wrote in a weekend is replaceable. The managed TURN service with a vendor-specific auth scheme is not. The 'login with Google' button that you treat as free infrastructure is not. The push notification pipeline bolted to APNs and FCM is not. None of this is wrong to depend on — it's wrong to pretend you aren't.

The second takeaway is narrower and more useful: when you have the choice, pick the boring open standard over the shinier proprietary one, even when the proprietary one is faster to integrate. SIP is awful. XMPP is awful. SMTP is awful. They are also the formats that will still parse in 2041, which is more than you can say for whatever your current vendor's SDK is emitting. The engineers who picked boring standards in 1998 are the reason you can still read a thirty-year-old email.

The third takeaway is for anyone archiving software. The iChat work only became possible because the author had a copy of the client, a copy of the OS it ran on, hardware that could still boot it, and packet captures from when the service was alive. Any one of those missing and the project is dead. If you care about this kind of recovery being possible for the current generation of apps, the time to grab the artifacts is now, not after the EOL announcement.

Looking ahead

None of this will stop the next iChat from happening. The economics of running a real-time service pull every vendor toward centralization, and the user experience of a well-tuned proprietary stack genuinely is better than a federated open one — right up until the day it isn't a stack anymore. What this project really demonstrates is that 'the client still runs' and 'the product still works' are completely different claims, and that the gap between them is where almost every piece of consumer software built in the last twenty years is going to end up. The question for anything you're shipping today is whether you want future users to need a packet capture to say hello.