Open OSCAR Server: a self-hosted AIM and ICQ server in Go

What Open OSCAR Server replaces, and for whom

AOL Instant Messenger and ICQ clients do not speak a modern protocol. They speak OSCAR, and they expect to reach a login server, an authorization host and a set of service hosts that AOL and ICQ once operated. When those endpoints went away, the clients became unusable no matter how well the binaries still ran. Open OSCAR Server is a Go implementation of the server side of that conversation, so a genuine AIM 5.x or ICQ 2003 client can connect to an address you control.

The README is explicit that this is an independent project, not affiliated with or endorsed by AOL or Yahoo! Inc., and that it is non-commercial and accepts no donations. That framing matters for who it is for. The audience is people who still own the old clients, or who want to study how OSCAR works, or who run retro computing setups where the point is the client, not the server. It is not aimed at teams looking for a chat backend for a new product, because nothing in the repository describes a modern client library or a mobile application.

The OSCAR protocol surface the server implements

The feature list is the clearest statement of scope. On the AIM side the README ticks off Windows clients from v1.x through v7.x, away messages, buddy icons for v4.x and v5.x, buddy lists, chat rooms, public and private chat exchanges, instant messaging, user profiles, privacy controls for allowing or blocking specific users, warning, user directory search, and TOC1 and TOC2 protocol clients such as TiK, gaim, vAIM and Miranda. File sharing is split by reach: Direct Connect and Get File are marked LAN only, while Send File is documented for LAN and internet use through a rendezvous flow described in docs/RENDEZVOUS.md.

The ICQ side covers Windows clients from 98x through 5, instant messaging, profiles, user search, presence statuses and offline messaging. Two things stand out. First, the client compatibility is enumerated per version rather than asserted in general, which suggests the protocol behaviour differs enough between releases that each one needed attention. Second, offline messaging is listed for ICQ but not for AIM, so a message sent to an offline AIM buddy has no documented delivery path here. Treat that as a real gap rather than a packaging detail.

Installing Open OSCAR Server and creating your first account

The README does not publish a single install command. It points to platform quickstart guides for Linux x86_64, macOS on Intel and Apple Silicon, and Windows 10/11 x86_64, and to docs/BUILD.md for compiling from source. The repository also ships a Dockerfile and a docker-compose.yaml, and the compose file shows the shape of a deployment: a cert-gen service that runs openssl to produce a root CA and a server certificate with subjectAltName entries for api.oscar.aol.com, login.oscar.aol.com, api.aim.net and the ICQ equivalents, an nss-gen service that imports the CA into an NSS database with certutil, and an open-oscar-server service that publishes ports 5190, 8080, 9898 and 1088 plus 4000/udp. Those hostnames in the certificate are not decoration: old clients are built to call them, so the certificate has to match what the client expects to reach.

Once the server is running, accounts are created through the management API on port 8080 rather than through a client. The README gives this curl example for an AIM screen name:

curl -d'{"screen_name":"MyScreenName", "password":"thepassword"}' http://localhost:8080/user

An ICQ account uses a numeric screen name in the same endpoint, which the README illustrates with the value 100003. To confirm the account exists, list users:

curl http://localhost:8080/user

You should see the screen name you just posted in the response. The README also documents listing active sessions with curl http://localhost:8080/session, which is the quickest way to check whether a client actually authenticated. From there, point your AIM or ICQ client at the server and log in; the README's client guides cover that side. If you prefer PowerShell on Windows, the README gives Invoke-WebRequest equivalents and warns to run them from PowerShell rather than Command Prompt.

The management API is HTTP and unauthenticated in the README

Every administrative example in the README is a plain request to http://localhost:8080 with no token, header or login step. Creating users, deleting users, changing passwords, listing sessions and creating public chat rooms are all shown as bare curl or Invoke-WebRequest calls. The README does not describe authentication for that API, and it does not describe binding it to a loopback interface only. That is a deployment decision the operator has to make: if port 8080 is reachable from a network you do not control, anyone who can reach it can create accounts or change passwords.

The OpenAPI specification lives in api.yml, so the full surface is documented even where the README is not. The practical consequence is that you should treat 8080 as an administrative plane and keep it behind the same boundary as the server itself. The docker-compose file publishes it alongside the client ports, which is convenient for a first run and worth revisiting before anything is exposed.

Where Open OSCAR Server is the wrong tool

The clearest limitation is the client set. Nothing in the README mentions XMPP, Matrix, IRC or any modern protocol, and there is no mobile client. If your users are on phones, this server cannot reach them. The compatibility list is a list of discontinued desktop programs, several of which need Windows and a specific version to behave.

File transfer is the second constraint. Direct Connect and Get File are marked LAN only. Send File is documented for LAN and internet, but it depends on the rendezvous flow in docs/RENDEZVOUS.md, which is a different path with its own failure modes. Anyone expecting a general-purpose file transfer service will be disappointed.

The third is operational. The README does not document backup, restore or rollback procedures, and it does not describe how state is migrated between releases. The repository does contain a golang-migrate dependency in go.mod and a state/ directory, which implies schema migrations exist, but the README does not walk through them. Before trusting it with data you care about, read the migration files and test an upgrade yourself. Finally, the project is not archived, but the last push was on 2026-06-07, so the code is not moving quickly and you should not expect rapid fixes.

How this differs from running a modern XMPP or Matrix server

If the goal is simply self-hosted chat for people today, a modern server is the better comparison. XMPP servers and Matrix homeservers target current clients, support federation between independent deployments, and have documented paths for end-to-end encryption. Open OSCAR Server does none of that: the README describes a single server that classic clients connect to, with no federation and no encryption layer mentioned.

The trade-off runs the other way too. A modern server cannot log in an AIM 5.9 client, because the protocol does not exist there. Open OSCAR Server exists precisely because the client is fixed and the server had to be rebuilt. If your constraint is the client, this is the category you are in; if your constraint is the users, it is the wrong category. The MIT licence also means you can read and modify the Go source, which is a reasonable option when a client does something undocumented and you need to see how the server responds.

Licence, maintenance and upgrade cost

Open OSCAR Server is MIT licensed. That is permissive: you can use, modify and redistribute it, including in closed products, provided the copyright notice and licence text are preserved. The README adds a disclaimer that the project is independent and unaffiliated with AOL or Yahoo! Inc. That disclaimer is a statement about the project, not a legal opinion about your use of AIM or ICQ client software, and trademark questions around those names are separate from the MIT grant. If you plan to distribute something built on this, get your own advice on the names and the clients.

Upgrade cost is low in code terms and higher in operational terms. Releases are tagged, with v0.24.0 on 2026-06-07, v0.23.0 on 2026-03-25 and v0.22.0 on 2026-01-31, so the cadence has been roughly every two months. The last push was on 2026-06-07, which is more than three months before today, so describe the project by that date rather than as actively developed. The Dockerfile builds from golang:1.26.2-alpine and runs the binary on alpine, and the Makefile wraps GoReleaser in a container with SKIP_CODE_SIGN defaulting to 1, so a local build does not need signing infrastructure. The upgrade work is in the database migrations and in re-testing the specific client versions you care about, since the compatibility list is version-specific.

Editorial conclusion

Adopt Open OSCAR Server if you want a private OSCAR endpoint for genuine AIM or ICQ clients, or a lab to study the protocol. Do not adopt it for production messaging: the README documents no federation, no end-to-end encryption and no mobile client, and the last push was on 2026-06-07. Verify first that your chosen client version appears in docs/CLIENT.md or docs/CLIENT_ICQ.md, then confirm the Docker image builds and that the management API on port 8080 answers a GET /user request before you hand out accounts.

Frequently asked questions

Official sources

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