There was a request a few weeks back on the Digsby forums for the ability to have Digsby recognize and interpret aim: links.  AIM Links allow you to add a URL to a webpage which will automatically launch AIM.  You have the ability to specify to “add a specified contact” or “send a message” to a contact.

Examples:

Send a message:

aim:goim?screenname=davux

Output: Send Dave a message!

Add a contact:

aim:addbuddy?screenname=davux

Output: Add Dave to your contact list!

Note:  Alternate aim:// links are also supported.
Usage

This Flexibility works great on message boards and community sites where single-click access to an alternate communication medium is advantageous.

The Catch

This program (like many of my Digsby enhancements) works by simulating a user, and due to some limitations in Digsby itself, I’m unable to gracefully get around this single limitation for the software.  I hope that for most people, it would be trivial.

You must have your AIM account as the primary account in Digsby.

This means that your AIM screen name must be the first one listed when you view your accounts.  You can view your accounts by clicking on Tools and then Preferences and select the Accounts tab.  You can move the account by simply dragging it up or down.

Note: A restart is required for these changes to take effect.

The Software

DigsbyGoIm is easy to use.  You’ll need to install it just once, and it will work without any extra interaction on your part.  There is no need to start run it manually.  Clicking on any aim: link will launch it, and in turn, Digsby.

Once downloaded, copy the executable to a location which you will not accidentally delete it.  The program will register itself to that location, and if you remove or delete the file, links will no longer be handled.  If you do decide to move the program–don’t worry.  Re-running the executable to install will update the references and links will be handled at the new location.

Double-click DigsbyGoIm.exe to install.  You will be prompted with a set of options.

Selecting YES will install the handler.  Note that this will overwrite any current AIM link handler.  You will need to reinstall AIM in order to recover your old link handler.  AIM will continue to function properly in all aspects other than handling links.

If you are using Windows Vista, you will be prompted to elevate.  This is a one-time action and is required in order to add the registry entry to HKEY_CLASSES_ROOT that will allow this program to register itself to handle links.

That’s it!  Links will be handled now, and you can enjoy not having to copy and paste screen names to send messages.  Note that addbuddy link identifier will not actually add the buddy to your contact list, but rather just invoke the Add Contact dialog, and fill in the name.  You will have the option to select an alias and click Add. Also note that the message parameter will be ignored for goim links.

Download

DigsbyGoIm 1.1.0

Due to some demand, I’ve wrapped DigTweet up into a graphical program that runs in the tray.  Optionally, you can still run it from the command line, with some new feature, and some updates to the error detection scheme.

New Features:

• Choose to ignore replies so they don’t end up as your status message.
• Choose the update interval.
• Run graphically or from the command line.
• Save settings between sessions.

Due to some of the limitations of .NET, I’ve compiled two versions, one for strictly graphical users and one for mixed-mode users.  The two versions are functionally equivalent, however the console version will flash the window when launching, whereas the GUI version will not attach to the console window which it is launched from.

Screenshots

Download

DigTweet 1.1 Graphical (Recommended)

DigTweet 1.1 Console

Microsoft .NET Framework v2.0 is required.

DigsbyStatus is included.

As I mentioned in my previous post, I was working on a solution to sync the twitter update status (one-way), with Digsby’s status.  This works great for those that update twitter throughout the day with contact information and such important things.  This is a simple console application that makes use of the DigsbyStatus.exe to update the status.

It isn’t a full XML parser and could probably be broken pretty easily by other RSS feeds, so I wouldn’t recommend trying that.

Using the utility is easy, just make sure the DigTweet.exe and DigsbyStatus.exe are in the same folder, and pull up a command prompt.

DigTweet.exe RssLink

So for example, to sync to my feed, I would enter:

DigTweet.exe http://twitter.com/statuses/user_timeline/14261383.rss

You can find your Twitter RSS feed at the bottom of your personal page (not your homepage, that link will go to a feed of everyone’s status).

If you like, you can make a single-click batch file. Just open notepad and enter the following:

DigTweet.exe http://twitter.com/statuses/user_timeline/14261383.rss

Change the RSS path to your own, and save the file as StartDigTweet.bat. Be careful to not have ‘.txt’ appended to the end by notepad. Click this file and the window will open. You can largely ignore what it’s saying, just minimize it and go on with whatever you’d normally do. Tweets are only updated ONCE, so if it changes the status, and you switch to something else, it won’t be overwritten until a) you restart DigTweet, or b) you have something new in the “top slot” in your feed. (Note: deleting a tweet will cause a sync on the previous tweet)

You can grab a copy of DigTweet today.

There was a request today on the Digsby forums about setting the status based on a twitter feed.  I thought this was a great idea, since this is something I could use.  Normally I don’t use status message at all - but I do twitter.

I set to work figuring out how to set the status from outside the application.  I went with the same approach that I had used before, simulating a local user via Win32 Window messages.  This is a great solution because it doesn’t interfere with any actions that a user may be performing locally - you don’t even know it is happening.

I broke this project up into the two logical components, the part that gets the twitter feed and the part that actually does the work of setting the status.  What I’ve come up with is a little command line utility to set the status.

It can be used like so:

DigsbyStatus.exe "This is my new status message"

Or, to clear the status:

DigsbyStatus.exe ""

Quotes are needed as to simulate a “blank” argument.  The status classification can’t be changed, so you will still be available or away based on the protocol and the last state of the computer.  I figure someone else might find this useful to, say, update status based on some unsupported media player.

Download: DigsbyStatus_100.zip [10KB]

I’ve been using Digsby since it came out in February, and I’ve had the Widget attached to my Facebook profile, but I’ve added it here now.

The Digsby Widget is a little flash application that allows users on a website to directly contact you via Digsby.  This is my widget for this site:

When a user clicks the object to enable it, they show up on my Digsby contact list.

Just type into the widget to send a message!

It’ll show up on my computer, just like a regular IM window:

I’ve never seen anything like this in any other IM client, and although it’s not really all that useful for many people, it’s certainly a cool feature.  Feel free to strike up a conversation with me!

Every time I get on the MAX and ride for more than a few stops, I hear this message, and it always strikes me as a really strange thing, and I couldn’t figure out why until a few days ago.  The message is spoken by a woman:

Proof of payment and a validated fare are required on MAX.

A sentence that you might hear on any other transit system without strict access control (VTA, for example uses an honor system).  I’ve been using the MAX twice (or more) per day since May 31st, and I’ve never had my fare checked.

Anyway, this voice sounds just like the woman that narrates the intro scene in the original Half-Life, I could completely imagine her swapping MAX for The Black Mesa Transit System.  I can’t be the first person to have thought this, Portland is a pretty nerdy area, more than a few people have played Half-Life around here.

I’m pleased to announce the DTG is now fully encrypted.  There is no need to worry about your sensitive conversations being read by ANYONE but you.  The new DTG Client (Build 6b) includes these features:

• Triple DES Encryption on ALL meaningful personal data being sent.  This means contact names, timestamps, messages, open windows– it’s all completely encrypted.  I couldn’t see your information–nobody could.
• Windows Credentials Management - Windows is now in charge of your user name and password.  There is still a settings.dtg file that stores the URL to DTG, but log-on credentials are stored and maintained by windows.
• Windows Vista UAC support.  You’ll no longer have to right-click on the EXE and run it as an administrator to install skin hooks.  The skin installer is now integrated with UAC and you will be prompted when opening it.
• I’ve tracked the WLM bug - there is a bug in Digsby’s skin parser that needs to be corrected before I MSN/WLM contacts (and possibly networks other than AIM) can be shown.  Sorry - I can’t do anything about this.

The web interface may seem slower to load now - the javascript is redundant and not optimized.  It is on my task list but the UI needs to be brought up to snuff before I can do that.

Proceed to the DTG website

I spent upwards of an hour trying to fix this bug that I introduced in some ‘AJAX’ code I was working on.

Basically, this was my original (vastly simplified and error checking removed) code:

function GetData(string url) {
 
req = new XHR();
 
req.open(url);
 
req.onreadystatechange = function() {
 
    if(req.readyState == 4 ) {
 
        document.getElementById('home').innerHTML += req.responseText;
 
        free_XHR(req);
 
    }
 
}
 
req.send(null);
 
 document.getElementById('home').innerHTML += "Waiting for data...";
 
}

This worked just fine, until I changed it to remove the multiple calls to document.getElementById and turned it into this:

function GetData(string url) {
 
req = new XHR();
home = document.getElementById('home');
req.open(url);
 
req.onreadystatechange = function() {
 
    if(req.readyState == 4 ) {
 
        home.innerHTML += req.responseText;
 
        free_XHR(req);
 
    }
 
}
 
req.send(null);
home.innerHTML += "Waiting for data...";
 
}

This had some really strange (or so I thought) effects. No errors were caused, but the home<div> was not properly written to.  It would add the text to that ‘home’ object.. a copy of the home div that didn’t exactly exist on the page. For all subsequent calls to the GetData routine, it would copy the home <div> and then effectively pipe the data nowhere.

The kicker?  req is still a correct reference object in the anonymous function that handles the readyState change., not a copy, but a reference to the req object created in the GetData call.  I’m still not exactly sure why this happens, perhaps it has something to do with the HTMLElement class not being passable in the same way that XMLHTTPRequest is.

This is a list of the current known issues with DTG:

• When there are not any IM windows open, the contact list will be blank and offer no indication that there are not any open windows.
• When a window is closed locally, the remote client does not remove the page.  This functionality is expected, however the ability to Send still exists, even though is will fail.
• There is a case where a window cannot be located even when the window cache is built, I’m working to find this one.
• When another session is created, or the session is cleared, you may receive the You have been logged out. Message more than once.
• If there is an error contacting the web server (From the bridge), that message will be lost.  I am working to build a queue so requests are never lost.
• There is no visual indication in the IM window that DTG is active.  I’m working to build a solution that would show this visually without getting in the way.
• There is not any indication when a new IM comes in to the remote client.  I’m looking for a solution to this.
• Internet Explorer is not supported by the remote client:  This is expected, since the site is currently Gecko/WebKit specific.  I will be building a desktop-browser solution soon.  If anyone is willing to help with this (looking for someone experience in building pretty websites), let me know.
• The client constantly reconnects every X (likely 5 minutes) and checks for messages even though there isn’t any need - this is expected, but will be optimized to not do so soon.
• The bridge application opens slowly: this is due to connecting at startup, this will be fixed soon.  My web server isn’t exactly speedy, and sometimes connect times are relatively high.
• There isn’t any way to see more than 20 (or so) lines on the remote client:  This is expected, however I think I have found a solution which will allow the user to toggle between “functional” and “history” modes, viewing past lines.
• Emoticons are not supported: This will be coming soon, however I am not sure whether it would be best to convert to text, or convert to images, perhaps a setting.
• Login and registration pages don’t look good:  They are temporary, I will replace them with iPhone/browser specific ones when I can.
• UAC does not prompt for elevation for the Skin Installer under Windows Vista: A fix is in the works for this.
• Requests often get queued up on top of each other, and messages are added to the same window twice: I need to figure out how that is possible before I fix it.
• Status messages and “day change” time stamps are displayed strangely - I’ll have a fix for this soon.

With all these changes, I will soon be implementing a version check–you will need to be using the latest build every time you restart the bridge.

If you find any other bugs, please email or IM them to me so I can be aware–and fix them, as fast as possible!

It’s been quite a while since I’ve udpated this, but I’ve spent this weekend working most on the Digsby ToGo project.  I’ve opened it up for a limited beta.  Send me an email containing a user/pass pair if you’d like to get access. Register at the DTG homepage.

How to get Digsby-ToGo:

• Get your username and password. I’ll put a registration page up soon so you won’t have to contact me.
• Download the Digsby-ToGo package from The DTG homepage.
• If you are using Windows Vista, you will need to open the application as an administrator in order to run the Skin Installer.
• Run the Bridge application.

Before you login, run the Skin Installer to install the hooks in the skin that will get your messages into Digsby ToGo.

Select your skin from the menu - change the location if you didn’t install Digsby to C:\Program Files\Digsby\.  Once you select your skin, click Install Hooks.  Once this is do Make absolutely sure you restart Digsby. It doesn’t do any harm - but the results will be inconsistent and erroneous.  If your skin isn’t compatible with the installer, please let me know.  zip a clean version (i.e. no hooks install) without any extra images and email it to me.

Once the skins are installed, you can login to Digsby-ToGo.

The Log tab provides mostly debug information.  You can minimize of close the program and it will go to the tray.  Your IM’s will be routed to my webserver and you will be able to login on your iPhone or iPod Touch and access them.

Please note that there is not any encryption at this time.