Idea for Adium iPhone

[Ken Raeburn]

On Oct 17, 2009, at 01:46, George Lambrou wrote:
> As much as I like your idea, Augie, I see one fatal flaw: from what  
> I understand, this idea would require that Adium be both running and  
> on a computer within range of the iPod touch/iPhone, defeating the  
> purpose of the iPhone version itself. It would require that the user  
> own a Mac (as far as I'm aware, most iPhone/iPod touch users do not)  
> in order to use desktop (for lack of a better term) version of  
> Adium. While in theory I believe your idea could work, it lacks the  
> practicality necessary for a portable application.


Brandon Vogts's idea ties into an idea I've had percolating in the  
back of my mind for a while, which unfortunately would take a lot of  
work, and a lot better understanding of the Adium internals than I  
have, if it's even practical.

The core idea: Separate the Adium UI from a back end proxy that talks  
to the various chat servers.  Make the back end support talking to  
zero, one, or more UI front ends at a time, including the iPhone app,  
and portable to non-Mac systems.

Some goals:

* Share chat room state, conversations in progress, maybe logs, etc.,  
between my desktop Mac and my laptop, in real time.

* Don't tie a chat session to a specific UI app on a specific machine,  
in case both parties go idle for a while, one switches machines, and  
the other wants to resume the conversation.

* Keep signed on, available to get messages and record chat rooms, but  
let my desktop machine go to sleep or my laptop get disconnected from  
the net; just mark me as "away" or "idle" if there are no currently- 
connected UI front ends.  Maybe use wake-on-LAN to wake up the desktop  
machine for certain messages so Adium can squawk in case I'm just in  
the next room.

* Allow non-Mac front ends talking to the same services with same  
configuration data: iPhone, Linux, Windows, whatever.  Maybe a cute  
web browser app too.

* Keep the proxy in my control, so I control password access, iPhone  
notification policy, etc.

* In the degenerate case of one back end and one UI front end running  
on one machine, the user experience should be basically what we have  
now.

* Different UIs can choose how much data to request of the back end,  
so for example the iPhone only downloads a little stuff to display  
unless you indicate you want to go back through logs.

I've tried using the Screen Sharing app; it gets me access to the  
desktop Adium invocation, but the UI experience is poor, and you lose  
sound notifications (and dock-icon too, if your view of the remote  
desktop doesn't happen to encompass it).

Leaving the proxy software in control of the user allows for creating  
arbitrary policies about when notifications are generated, limited  
only by the user's programming skill and/or a UI designer's  
cleverness.  It also lets people experiment (to a limited degree) with  
adding support for new IM systems without having to work directly on  
the iPhone app.

Having an open-source arrangement of this sort would allow other app  
developers to experiment with different phone UIs, even if they have  
to get their own certificates and run their own servers to use a  
different app ID.  (Maybe there's some way around that, but that's a  
separate issue.)

If the software run on the permanently connected host is *just* a  
proxy, it doesn't need to be Adium, nor necessarily running on a Mac,  
just any system supported by libpurple and whatever else is required.   
It might even fit into some small appliance like a programmable router.

I haven't thought too much about the iPhone angle, or how you'd want  
to handle things like bonjour.  And there are lots of UI issues like,  
if a chat with a contact is visible on two machines and you close the  
window on one, should it be closed on the other, or should the chat  
session only be terminated when all UIs close it?

Sorry if this is rambling a bit.  It's just the start of an idea I've  
had brewing for a while...

Ken

[1] Even if some of the iPhone apps use a challenge-response  
arrangement that keeps the password itself from going to the proxy,  
they don't tend to advertise all that on the app store pages, and I'd  
bet the proxy would see all the message traffic in cleartext anyways.