Handle multiple legacy accounts per user per transport

Description

Imported issue was from daniel:
Some folk have multiple AIM, ICQ, etc accounts and it would be nice if there were a way to log into all of the accounts at the same time via the transport. In theory AIM supports this in the newer AIMs, linking I believe is what they call it, but behind the scenes, from what I can tell, the client is just logging you into multiple accounts at the same time.. no real magic there. The idea of multiple accounts per person is unfortunately extremely complex and may require some XEPs to be written to flesh out the logistics. It'll be a long time coming probably. but it's on my list.

Another alternative, albeit crappy, is to allow for multiple iterations of the AIM transport. (aim, aim2, aim3) That means, however, that the administrator would need to know how many accounts max any of their users have. (or set an arbitrary cap) Besides that, it's an ugly solution, I'd like to come up with something "pretty".

Environment

None

Activity

Show:
daniel vultur
November 20, 2008, 4:16 PM

I just dropped Peter some mail. Hopefully I'll start up a dialog.

daniel vultur
November 20, 2008, 4:16 PM

=) Well I actualyl don't think it's that ugly anymore. I think it might be a good way to accomplish what I need to accomplish and it's something I could turn into an XEP proposal. Hopefully it wouldn't get shot to hell. Might see if I can get up with psa to run it by him to see if it's even worth writing up.

I think multiple iterations of the transports themselves is a "quicker' solution, but it's also one that requires some reworking because of the way the databases are set up right now.

Sigh.

=)

daniel vultur
November 20, 2008, 4:16 PM

From Jeremy Rose:
The ugly solution might be ugly, but it would certainly be a welcome alternative to having the jabber client open plus an extra MSN client, to log into the other account, for example. I'd certainly be all for having aim2.aaa.com and aim3.aaa.com, etc, if that's what it took to get it working relatively easily and to reduce the amount of work required on your part.

daniel vultur
November 20, 2008, 4:15 PM

Some of the issues that may be faced are questions of "what account do I use for this". For example, lets say I'm logged into AIM as acct1 and acct2. Both have friend1 on their list. I want to IM friend1, now the transport needs to decide whether acct1 or acct2 would be best to use. What if I disagreed? What if I wanted to force acct2 to send?

With PyAIMt, I had thought about something using resources... so I could do any of the following:

  • friend1@aim.example.org - picks 'best' account to send with, might just be the first in the list

  • friend1@aim.example.org/acct1 - sends with acct1

  • friend1@aim.example.org/acct2 - sends with acct2

  • friend1@aim.example.org/acct3 - bounces, no acct3 logged in

Since the transport contacts don't use resources, there doesn't end up being a conflict there, and the resource can theoretically be used for things it wasn't intended for. ;D In this case it would be used for routing of sorts. Is there a better way? I'm not real sure, I've never come up with a cleaner solution. If the concept here were presented as an XEP then clients could cope with the concepts.. maybe.. and let you pick and choose which account you want to send from in a "clean" fashion. Likewise, clients that don't support said XEP would already support sending to an arbitrary JID so users who knew what to do could even force it themselves.

And that all said... would the average end user even really care about what account their message was coming from so long as it got there?

Assignee

Daniel Henninger

Reporter

Daniel Henninger