Ok everyone. I’ve done it. I’ve got the retro, open sourced AOL Instant Messenger server working on a server.
Tested it using some really old AIM clients. Yes, it works from Windows 3.1. It’s awesome.
But the question I have now is… how do we want to handle user accounts on it?
Accounts on this server can be created one of two ways:
Simply logging into the server (using any old AIM client) will auto-create a new account with the user name and password you select.
Or we can turn off that “auto create a new user” option, and have new accounts only created via a terminal command by an administrator.
Those are really the only two options at the moment. There’s no web admin UI. There’s no quick way for us to tie the user accounts into another system (at least not without a fair bit of work).
I mean… in theory we could update the code for the AIM server so that it checks something like this Discourse server to authenticate the user before auto-creating the user account in that first option. That would limit the users to only people with forum accounts (and thus only to subscribers).
But I haven’t yet looked into what that would entail (no idea what the “use Discourse as a login verification system” workflow would even be like… I’m assuming folks have done that before somewhere).
In a perfect world, it would be nice to have the backend account integration tied into existing user accounts. However, we’re talking about a 20+ year old protocol that never had security in mind as a goal, so I say just send it!
Well, since the kiddos aren’t old enough to intern as AOL administrators, I guess the real question is: how much time do you have to spend creating AIM accounts? How much additional workload is that going to put on you to satisfy the influx of users?
I suppose the bulk of the burden will be up-front, as you try to onboard all the existing subs (there are already 150 users on the discourse). But once that tidal wave is over, maybe you can just staple an AIM account creation to every new sub you already have to create, as an ongoing thing.
Alternatively, I guess @leebase has the easier option: let us all create our own accounts (maybe leave it open for a week or so), and then shut the tap off once we’re all onboarded?
The problem with that, is that you’re VERY LIKELY to get sleeper trolls. People who will sign up silently, and then just wait for the tap to be shut off to start causing trouble, or just lurk there for the screenshots. So, that’s going to be a serious privacy concern for some users…
I say 1st option. Then if it becomes a problem I think an intermediary script to interact with the Discourse API and the retro AOL server to create/verify accounts would work.
I’d also be cautious about reusing the same password from the Discourse within the AIM Server. The AIM protocol is not going to have modern encryption like your web browser.
Also, it’s kind of crazy that an x86 Windows app can be made to run fairly natively on an ARM Mac running the latest Mac OS. WINE with a grafted on x86 emulator?
It’s sad that Apple has no concern for backwards compatibility - there are so many PowerPC Mac OS X apps, or even x86 32-Bit Mac OS X apps, that will never run on a modern Mac OS. I remember patching the PowerPC AIM client to remove the ads…
The backwards compatibility is for Intel x64 Mac apps too via Rosetta 2. Yes, PPC and x86 32-bit apps are not supported. I understand that Whisky is a pretty good off-the-shelf way of using Wine. I’ve used it to run some old Windows apps.
I wrote a quick python script to access this site and show me all my unread messages, it actually allows login, keeps the cookies in a sqlite database for later use. I’m pretty sure we nerds here could figure out a way to use the discourse login to authorize an AIM account maybe via that terminal system.
I’d also be cautious about reusing the same password from the Discourse within the AIM Server. The AIM protocol is not going to have modern encryption like your web browser.
