Blog

Instant Messaging Software Ideas…

Having several machines (at least a laptop and a workstation) and multiple OS’s can be a pain if you use Instant Messaging software. It usually isn’t because IM most software doesn’t allow multiple clients to be connected at the same time with the same account, but that doesn’t mean you’ll actually receive all your messages. Power failures, a rush suspend (close laptop lid and go away) or even distraction can make you lose some potentially important messages. On top of that, running the same IM account on several boxes can prove to be a mess if you wish to save the conversation logs, there is no way I know of to synchronize and centrally store all those conversations.

The only application that I believe is close to this goal is Google Chat, and I’m not even sure it completely stores all conversations, but things are really more problematic when multiple IM protocols are in use.

On the other hand, why am I limited to be connected with one client at a time? What if I’m in a big office with several workstations of my own (or even running some virtual machines). Eventually I would like to get the messages where I’m at the moment even if I just flipped my chair 180º.

This, I believe, if a nice playground for software like Pidgin (former Gaim). While there is cool software like Beagle that indexes conversations, there is still the short leap of actually storing them (all IM protocols) in a central repository, similar to Google Sync. As far as this feature goes it would be rather simple to implement, even because most of the code can be shared from Beagle.

The other feature (multiple connected clients) would be more difficult to implement as it would require a central communication server (something like Microsoft Exchange provides). Again, Pidgin would be a likely candidate for this job, and I’m certain it would be a very nice attractive for corporate users.

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

7 Responses to “Instant Messaging Software Ideas…”

  1. z says:

    i actually thought about the same idea a few days ago. i have 3 computers i work on and i would appreciate it if pidgin would store the logs in a central
    place..

  2. Joe Audette says:

    I’m kind of old school myself and hardly ever do any instant messaging so my input is probably out of touch, but I think if I were getting more into instant
    messaging I would look into meebo, http://www.meebo.com/

    I’m not sure it meets any of your requirements, but it might be worth a look.

    I’m considering integrating it into mojoPortal as a way
    to add an easy chat feature.

    Cheers,

    Joe

  3. Dave Foster says:

    A friend of mine, Andrew Yates, submitted a proposal for Google SOC that tackles
    pretty much this very idea.. unfortunately it was not accepted. His method involved modifying a jabber server, I think, or something similar. Unfortunately I can’t find his proposal, but drop by
    #l3ib on freenode and talk to us (andrewy and nightm4re) and see if we’re on the same page.

  4. Andrew Yates says:

    This is something I’ve been
    interested in for awhile as well.

    I’ve looked into it at length and believe Jabber/XMPP would be best suited to handle this. Jabber is capable of communicating with all the major IM networks via
    transports (for example, AIM contacts show up to clients and can be communicated with as username@aim.jabberserver.org), can store logs on the server, supports protocol extensions, and already has
    the infrastructure in place to handle this. This has the added benefit of increasing Jabber’s appeal and hopefully encouraging people to switch to it.

    Several steps would be required to implement
    it (not necessarily in this order):
    – a XEP (Jabber’s equivalent of an RFC) detailing the protocol extension would need to be written
    – support for the XEP would need to be added to at least one
    jabberd
    – support would need to be added to clients

    I proposed this to the XMPP Foundation for the summer 2008 Google Summer of Code, but unfortunately was rejected. This is a preliminary
    document I wrote up describing it: http://www.andrewyates.net/misc/xmppsync.html and here is a copy of my GSoC proposal with irrelevant information (why I want to write it, my programming background,
    etc.) removed: http://andrewyates.net/misc/xmppsummary.html

    As you can see, some of the supporting technologies (server-side logging in particular) are not fully implemented in all the daemons and
    clients. They really need to be before a good implementation of this can be completed, so that may have contributed to my proposal’s rejection. I’m still interested in working on this, but don’t
    currently have the time to. I’d still be interested if anyone else attempted it and would certainly help them sometime in the future.

  5. Brett says:

    Hey,

    I faced the same issue and solved it to by partial
    satisfaction by using ctrlproxy amd bitlbee

    Ctrlproxy runs on a central server and acts as an irc proxy. Bitlbee acts as an irc server and allows access to most im networks.

    By pointing
    ctrlproxy to bitlbee I can have multiple irc clients connected to ctrlproxy at once all seeing the same data, with all messages logged to a central location. IRC clients generally aren’t as nice as
    IM ones, but I have found ones on each platform that I am pretty happy with.

    Hope that ramble made sense and is potentially helpful.

    Regards,
    Brett

  6. I think Live Mesh has potential to provide a framework for solving your
    problem. You use the repository as storage and it automatically syncs your clients when online. The only issue is multi presence…how does the system know which client to send a message
    to?

  7. Lynn says:

    I could live without server centralized logs and synchronized logs at
    first – those would be really nice but add complexity and effort and really aren’t as important as receiving my messages everywhere I have a client connected to an IM server. Alex, I’m not clear
    how a client side program like Pidgin could solve this unless it actually chooses what machines to send the messages to. I would guess it could be done by an IM server program, like a Jabber
    server, that would decide where to route a message. I wish the IM server would route the message to every client that is connected for a user. If there were no server message log, each client side
    message log would only show the messages actually received at that client. As for sending ‘offline’ messages (which are received at server when user not connected at all), not sure exactly how
    that works today but perhaps they could be considered delivered when delivered to any client/host.

    Currently I use Pidgin and connect to some type of Jabber server, and it’s very
    frustrating that messages seem to randomly go to one or more (but not all) of my active Pidgin clients running on different machines. It doesn’t even seem consistent, or at least I can’t figure
    out the pattern of how it chooses which machines to send the message to. Sometimes the ‘user X is typing’ message is sent to a different client than the message when it is sent which seems
    bizarre.

    When I googled on this subject (because I work on different machines and struggle with this issue), I saw that Sun Java System Instant Messaging has a (too) complex way of handling
    this with ‘priorities’, e.g. Sun IM’s web page says:

    —-
    When enabled, this option allows you to select the length of time your current session is idle or away when you are inactive.
    Once your status changes to idle or away, your messages are routed to the active session on a machine or device that has a higher priority.

    If you are running Instant Messenger on multiple
    machines, a session ID is assigned to each machine when you login. Depending on which machine you are using, you may set your session priorities such that alerts come directly to your active machine.

    For example, you log onto your workstation in the morning. During a meeting, you log into your PDA and chat with a co-worker through your Java chat client. At that point, you define message
    priority so that inbound messages will reach your PDA not your workstation. When you return to your office, you catch up with the Instant Messaging traffic that, by default, was routed back to your
    workstation when you exited your PDA. Finally, you go home and log in from your home office, routing inbound messages to reach you at home rather than at the office. The office session stays logged
    in at all times when no other higher-priority client is logged in; it receives inbound messages by default.

    ———— (end quote from Sun’s web page)

    Personally, I wouldn’t want
    to have to change a ‘priority’ every time I switched machines. It think it would be simpler and better just to route the message to every connected client for the user whether it is idle or
    not.

Leave a Reply

For spam filtering purposes, please copy the number 5712 to the field below: