Slashdot Mirror

For those who are interested, I managed to get a couple more images of this interface here and here.

Bonus points if anybody can figure out where the shots came from and shut them down.

For those who are interested, I managed to get a couple more images of this interface here and here.

Bonus points if anybody can figure out where the shots came from and shut them down.

If you are using AIM, third parties have extended the functionality of the network to allow offline messaging. Take a look at DoorManBot. While it does not (currently) have integration with the native AIM client, TerraIM has it integrated, and even without integration its a great tool when you need it.

The headline makes it sound like these bots were sending messages out advertising themselves to users.

I was afraid this would give useful "push" services a bad name.

DoorManBot does this, but only to deliver actual offline IM's to users from their buddies.

However, it looks like AOL was just having their System Message service notify the user of the change, without even mentioning the specific bots. As far as I can tell, that's pretty far from spam.

They say they will be opening up to third party developers.
I checked the acccore.dll file, and seems to have some pretty extensive hooks. All the same, this is entirely client-side.

Recently, they have been clamping down more and more on third-party developers of services on the network. For example, a free offline messaging service, DoorManBot was forced offline for a few days recently. Hopefully, this new spirit of being open to developers will carry through.

While you can send offline messages on AIM with something like DoorManBot, the offline messages are stored at that third party, and is not done by AOL.

I keep logs of all messages sent through DoorManBot, which allows offline messaging on AIM, but I do that through special software only for the system.

For normal IM logging, I use Middle_Man, an AIM plugin. Other AIM plugins do this too, so take a look around.

While offline messaging is already available through third-party systems such as DoorManBot and some clients, such as TerraIM already have it integrated, it would be nice if AOL would actually make it native to their default client.

I hope their statements of supporting additions to the service will truly be open and not restricted to those the company already does business with. By making it open, the afford the opportunity of the broad support enjoyed by open source projects, where users feel they have some power.

Bankers may not love proprietary systems, but they do have some nice advantages.

A system like AIM is not going to go offline for days at a time, and leaves the organization without the hassle of managing an extra set of servers.

And AIM might not have message queuing built in, but systems like DoorManBot allow the function to be added.

Then again, Open Source is always nice, but I'm for a stable system any day.

Putting all discussion of what this could do to GAIM aside, I'm not sure if downhillbattle.org really considered if this could be done. I run DoorManBot on AIM, so I've run into many problems which will prevent them from being able to do this.

The issue is that on a network such as AIM, clients talk only to the AIM servers, not to each other, leaving no room for behind-the-protocol interactions between clients.

This means that the plug-in would need to be able to identify buddies also using the plug-in through something such as a tag in the user's profile; not the cleanest thing to do, though still doable.

Now comes the biggest problem. How will the plug-in communicate with others to do searches? Inter-client communications can only be done via the basic IMs that are sent between users. This would mean a new IM popping up every time one of your buddies decides to search for a song. Even if the search was hidden inside invisible tags, the IM would still need to present itself. This alone, I believe, would drive off any potential users.

Unfortunately, MSN and Yahoo! are just as bad as AIM in this respect, leaving any potential plug-in to work only with a different protocol. But with that, the user base is lost, destroying the purpose of the plug-in in the first place. A great idea, but sadly without hope.

AOL even uses some controls beyond the ones most people see.

I run DoorManBot, which relays messages to offline users, making it look like a SPIMer sometimes, so I've run into these.
For one, AOL restricts the number of messages you can send out without getting responses (links in your messages make that happen more quickly).

Buddy lists, which are commonly used for SPIMers to keep track of targets signing on, are limitted in the number of buddies you can add and remove in a certain period of time.

Best of all, these two "invisible" restrictions don't give an error message, so the SPIMer thinks everything is working fine.

And yet, even with all this, there are still problems.

It would seem that through this initiative, if all 3 platforms were merged, they would each get the features of the others. For example, AIM users under this project would be able to finally send offline messages! That would definately be a boost in security vs. having offline messages sent through services like DoorManBot, which while it works wonderfully, does not support encryption.

Then again, would Microsoft really put offline messaging for AIM into their "hub", or would it just get transfered from AIM to Yahoo, wait for the hub to see the AIM user sign on, then tell Yahoo to send it back, where it would send it to the AIM user? I don't know, that seems pretty messy, and considering Microsoft, I doubt this project will result in much more than a basic connection between the three, leaving AIM users without those much-needed improvements

About using an IM protocol... A friend of mine recently installed a computer in his car for the purpose of playing his MP3's off of it. I wrote up a small program that reports whenever it is connected to the internet with a new (external) IP. To do this, it logs into AIM using some custom code (though Perl:AIM will work just fine). The one downside to using AIM is the reliance on this friend being signed on at the time, so I have the message, containing the external and internal IPs routed through DoorManBot (Check the site out or the SN DoorManBot3 if you haven't used it) to ensure that they are notified. The program stays connected to AIM, creating a tunnel through any possible firewalls that may be in the way, and will execute commands coming from any of a set of Screen Names (keyed to his ScreenNames, as opposed to signing each message going out, so he can execute commands as if he were at the command prompt). I hope this shows how AIM can be useful for creating a backup back-door

As for away messaging, you can get that functionality by using an offline message service on AIM such as DoorManBot