Open OSCAR Server: Bringing Classic AIM and ICQ Back to Life on Your Own Hardware

A Server for the AIM and ICQ Nostalgia Niche

Open OSCAR Server solves a narrow but real problem: keeping classic AIM and ICQ clients usable after AOL shut down the original servers. It implements the OSCAR protocol in Go, so old clients like AIM 5.x or ICQ 2002 can connect to your own machine instead of a dead endpoint. The intended audience is clear from the README: people who still have those clients installed, hobbyists running LAN parties, and retro-computing enthusiasts. It is not a general-purpose messenger. There is no mobile app, no web client, and no modern feature set. If you want to chat with friends who never used AIM, this server will not change their minds. But if you have a soft spot for the buddy list chime and the away message, it gives you the infrastructure to recreate that experience on your own terms.

How the OSCAR Compatibility Works

The server speaks the OSCAR wire protocol, which is the protocol that AIM and ICQ clients used to talk to AOL's servers. Instead of connecting to login.oscar.aol.com, you point your client at the IP and port where Open OSCAR Server listens. The README does not specify the default port for the OSCAR listener, but the Management API examples all use localhost:8080, so that is likely the admin port. The server handles the session state: it tracks buddy lists, chat rooms, away messages, and user profiles. For AIM, it supports multiple protocol versions, from v1.x to v7.x, each with its own quirks. For ICQ, it covers versions from 98x through 5. The implementation is not a proxy or a gateway; it is a from-scratch reimplementation of the server side. That means you cannot just point any old client at it and hope. The README links to per-client setup guides, which suggests the compatibility is tested and tuned for specific releases.

Getting It Running: Commands and Config

The README points to quickstart guides for Linux, macOS, and Windows, but those guides are not included in the material I have. What is concrete is the Management API, which you can drive with curl or PowerShell. To create a user, you send a POST to /user with a JSON body containing a screen name and password. For AIM, the screen name is something like MyScreenName; for ICQ, it is a numeric UIN like 100003. The server also exposes endpoints to list users, delete users, change passwords, list active sessions, and create public chat rooms. For example, to create a public chat room named Office Hijinks, you POST to /chat/room/public with a JSON body. These commands assume the server is already running on localhost:8080. The README does not show the build or launch command, but the Development section links to a BUILD.md guide. So the practical path is: clone the repo, follow BUILD.md to compile, run the binary, then use the API to create accounts.

The Management API: Simple but Unauthenticated

The Management API is a plain HTTP REST interface. It lets you administer users and chat rooms without touching a database or config file. That is convenient for scripting. But the README examples show no authentication headers. There is no mention of an API key or token. If you expose port 8080 to the internet, anyone can create users, delete users, or change passwords. That is a severe security limitation. The README does not address this, so you must assume the API is intended to run on a trusted local network or behind a reverse proxy with its own auth. The OpenAPI spec in api.yml might define security schemes, but I cannot confirm that from the material. If you plan to run this on a VPS, you should put the Management API behind a firewall or a proxy that adds authentication. This is not a criticism of the project's purpose, but a practical warning for anyone deploying it beyond a home LAN.

What Is Missing: File Sharing and Modern Security

The feature list is honest about gaps. File sharing is marked as LAN Only for Direct Connect and Get File, with Send File working over LAN or internet via the Rendezvous protocol. That means large file transfers over the internet may be unreliable or unsupported depending on the client. More importantly, there is no mention of encryption. The OSCAR protocol from the 1990s and early 2000s had no transport security by default. The server likely sends messages in plaintext over the wire. That is fine for a retro LAN party, but it is the wrong tool for sensitive conversations. Also, there is no mention of federation or bridging with modern protocols like Matrix or XMPP. You cannot connect an AIM client to a modern chat network through this server. It is a closed loop for legacy clients only. If you need to talk to people outside your server, you will have to run a separate bridge, which is not part of this project.

Alternatives: The Gap Between Emulation and Modern Messaging

The closest alternative is not another OSCAR server; it is a protocol bridge that translates modern messaging to legacy clients. For example, you could run a Matrix homeserver and use a bridge to let AIM clients connect to Matrix rooms. That approach gives you encryption, federation, and mobile apps, but it requires more moving parts and does not preserve the original AIM experience. Another option is to use an emulator like a virtual machine running Windows XP with the original AIM client, but that does not give you a server; you still need a backend. Open OSCAR Server is the only project in this material that reimplements the server side directly. The trade-off is authenticity versus extensibility. You get the exact client behavior, but you are stuck with the old protocol's limitations. If you want modern features, you are better off with a bridge, but if you want the authentic buddy list and away message flow, this server is the more direct path.

Maintenance, License, and Upgrade Costs

The project is under active development, with the latest release v0.24.0 pushed on 2026-06-07. That suggests a steady cadence of updates, roughly every two to three months based on the release dates. The license is MIT, which means you can use, modify, and distribute the code freely, even for commercial purposes, as long as you keep the license notice. There is no donation or revenue model, per the disclaimer. The maintenance cost for you depends on how you deploy. If you use the pre-built binaries from the quickstart guides, upgrading is a matter of downloading a new version and restarting the service. If you compile from source, you need to follow BUILD.md each time. The API endpoints are stable enough that the README examples have not changed between recent releases, but I cannot guarantee backward compatibility. Before upgrading, check the release notes for breaking changes, especially if you rely on the Management API or specific client versions.

Editorial conclusion

Adopt Open OSCAR Server if you run vintage AIM or ICQ clients on Windows, Linux, or macOS and want a local, MIT-licensed server with an HTTP admin API. Skip it if you need modern messaging features like end-to-end encryption or mobile push, because the protocol is frozen in the 2000s. Before deploying, verify that your exact client version is listed in the docs, since support varies from v1.x to v7.x for AIM and from 98x to 5 for ICQ. Also confirm that the Management API's default port 8080 is not exposed to untrusted networks, as the API has no authentication in the README examples.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes