Open OSCAR Server: an open source AIM server in 2026
Open OSCAR Server is an MIT-licensed, Go-based chat server that speaks the classic AIM and ICQ protocols. The nostalgia is the least interesting part of it.
An open source AIM server is not something I expected to be reading code from in 2026, but here we are. Open OSCAR Server is an MIT-licensed project written in Go that reimplements OSCAR, the protocol behind AOL Instant Messenger and ICQ, well enough that decades-old Windows clients connect and work.
The nostalgia angle is the obvious one and also the least useful one. What caught my attention is what this repo is as an artifact: a complete, working, readable specification of a protocol that its own owner deleted.
🔍 What it actually supports
The project describes itself as "an open-source instant messaging server compatible with classic AIM and ICQ clients written in golang," and is explicit that it is independently developed and not affiliated with AOL or Yahoo. The client coverage is wider than I assumed:
| Client family | Supported versions |
|---|---|
| AIM (Windows) | v1.x through v7.x |
| TOC1 protocol clients | Quick Buddy, gaim, TiK |
| TOC2 protocol clients | vAIM, Miranda, iEM |
| ICQ (Windows) | 98x through 2003x, versions 4–5 |
The feature list is not a stub either. It covers Instant Messaging, Buddy List, Away Messages, Chat Rooms, "Public & Private Chat Exchanges", "Buddy Icons (v4.x, v5.x)", User Profiles, "Privacy (allow or block specific users)", "User Directory Search", "Warning", File Sharing via Direct Connect / Get File / Send File, plus Offline Messaging and Presence Statuses for ICQ. There are quickstart guides for Linux x86_64, macOS on both Intel and Apple Silicon, and Windows 10/11, and a management API over HTTP for administering users and chat rooms. At the time I looked, the repo showed 1.5k stars and 111 forks.
Key takeaway: File transfer and directory search are the hard parts of OSCAR, not the message-passing. A reimplementation that ships those is a serious reverse-engineering result, not a toy.
📚 Why this is better study material than most tutorials
If you are a UCSC, Moratuwa, SLIIT or NSBM student trying to actually understand networking beyond the exam, this repo is worth more than another socket-programming tutorial. Here is the difference.
A tutorial gives you a protocol someone designed to be teachable. Open OSCAR Server gives you a protocol designed in the late 1990s by a company that never intended you to read it, then recovered from packet captures and client behaviour. That means you get to see:
- Binary framing done for real. OSCAR is TLV-structured binary, not JSON over HTTP. Most working Sri Lankan devs have never parsed a length-prefixed binary frame in anger.
- Stateful, long-lived connections. Presence, buddy lists and away messages are a distributed state problem. Your REST CRUD instincts do not transfer.
- Multiple client generations against one server. Supporting AIM v1 through v7 plus two TOC dialects means version negotiation and compatibility shims are in the code, visible, with the compromises intact.
- Idiomatic Go concurrency at connection scale. Reading how one Go service holds thousands of stateful sockets is a genuinely transferable skill for anyone building a WhatsApp bot, a game backend, or an IoT gateway.
You cannot get points 1 to 3 from a modern codebase, because modern codebases mostly wrap someone else's SDK.
💰 The self-hosting math actually works here
The reason I think this is practical and not just interesting: it is a service you can run at home in Sri Lanka without a foreign card or a monthly USD bill. A single Go binary with no heavy runtime will sit happily on a Raspberry Pi or a retired laptop.
Rough continuous-draw arithmetic, which is just wattage × 24 × 30 ÷ 1000:
| Hardware | Typical continuous draw | kWh per month |
|---|---|---|
| Raspberry Pi 4/5, idle-to-light load | ~7 W | ~5.0 |
| Mini PC / thin client | ~15 W | ~10.8 |
| Old laptop, lid closed, battery removed | ~25 W | ~18.0 |
To convert those into rupees at the current CEB domestic tariff, including the block-rate jump that catches people out, run the numbers through our Sri Lanka appliance electricity cost calculator. The important detail is the block: adding 18 kWh a month is cheap if you are in a low block and much less cheap if it pushes you into the next one.
Watch the CGNAT problem before the electricity one. Most SL home broadband gives you a shared IPv4 address, so a server at home is not reachable from outside without a tunnel or a small VPS as a relay. On a LAN, campus network or lab, none of that applies.
🛠️ What I would actually do with it
Not run a public AIM revival. Three uses that hold up:
- A protocol lab you control. Point Wireshark at your own server, break something deliberately, watch the client's error path. You cannot do that to Slack or WhatsApp.
- A closed-network chat system. A school computer lab, a hostel, a hackathon venue, an office with no internet dependency. The clients are tiny, run on ancient Windows machines, and need no accounts with anyone.
- A contribution target. The project says it is under active development and welcomes contributions, and has a Discord. A merged PR on a 1.5k-star Go networking project reads far better on a CV than five tutorial clones. If you are also polishing that CV, our LaTeX CV maker is free and needs no signup.
I would not put private conversations on it. OSCAR is a 1990s protocol and nothing about reimplementing it faithfully makes it modern in its security assumptions. Treat it as a lab and a learning surface, not as a Signal replacement.
💡 What this means for you
AOL shut OSCAR down and every account, buddy list and chat room on it stopped existing. The protocol survived only because people outside the company documented it. That is the actual lesson, and it applies to whatever SaaS your team is building on right now.
Concretely:
- If you are learning: clone it, run the Linux quickstart, connect a client in a VM, and read the frame parser. One weekend gets you further than a semester of slides.
- If you are building: ask what happens to your users' data the day your provider turns the service off. Open protocols and self-hostable servers are the answer, and this repo is proof that the answer stays possible even after the vendor leaves.
- If you are hiring or being hired: this is what real systems work looks like. Point at it.