Re: [JDEV] Lurker Steps Forward

[Jeremie <jeremie@jabber.org>]

> Well I talked on this list for a while when it first started, and then I
> lurked for a long time mainly due to school and other projects. 

Yes, awesome, glad to see you back en-force! ;)

> A long while back there was talk about the AIM transport.  I work a lot
> with aim and libfaim because I code on two aim clients (gtkfaim and the
> yet released bullseye). I was beginning to picture the transport in my
> head because I don't think it would be that hard to quickly put together
> but there is one problem.  AIM believes that each user has a single
> connection.  To connect to aim your first must connect to an authorizer
> type facility and login, then you get tossed over to a new IP that acts
> as your server.  Once all that is complete you are actually online. 
> This makes it slightly difficult for the transport to handle multiple
> users.  I have thought of a few solutions to this and thought I would
> throw them out here before I start coding because each requires a
> different implementation. 
> 
> 1)  Have the transport open a new connection for each users duration of
> activity.  This is possible with the library I use (libfaim) and I believe
> with the TOC protocol, but this is going to cause a lot of connections to
> open, especially on a large system.  I see this as a last ditch effort to
> get a working transport.

Why would this be last-ditch?  Seems like a logical way to go, and not all
Jabber users will be using the AIM transport, and the AIM connections
would drop when the Jabber user for that connection goes offline...
doesn't sound like the outgoing connections would get TOO out of hand for
most purposes :)

> 2)  Have the transport open multiple connections to AIM but set a timeout
> on them so that they will die off and not just idle taking up sockets ont
> he server.  There are a few things that have to be watched in this
> scenario, the connection rate cannont be too fast or AIM get's mad and
> will not let you connect for a while. 

Does this connection-rate blocking thing act based on the the source IP
and userid tried, source IP and "failure", or just on source IP?  This
could be a problem for a busy transport... I'm wondering, are there
multiple auth servers(dns round robin or the like) and do you get rejected
by one or all of them when this happens?

> Also this would require some sort
> of password storing so that the user does not get angry and have to enter
> their password every time they wish to relogin to AIM to send a message
> (although some security nuts like myself really wouldn't mind).

Yes, that is an evil aspect of transports, if you store the password to
make it convenient for the user, you end up having a large DB of passwords
and become a target.  I wonder if some of the crypto stuff can't help out
here... Also, a fairly simple solution could be using the query proposal
from a few weeks ago, where the transport would query the client software
for the credentials, so the passwords would be stored on the
client(although I don't like making the two rely on each other).

Based on the security and ecommerce products I've seen, they all seem to
be happy with encrypting the data everywhere, and using a single private
key to decrypt it in ram as it's needed.  Then all you have to keep safe
is the private key which is a common thing anymore.

> It's late and my mind is kind of warped, so this is the best I could come
> up with.  The only other problem that crossed my mind (I remember this in
> old mailing list conversation) is the problem of allowing jabber users to
> create a new aim user.  This is less of a problem than is with ICQ because
> AIM does not a have a direct facility to signup other than the web page,
> so it seems that the user would have to create a user on their own to be
> able to use this.  Anyway, these are my warped thoughts and I would really
> appreciate comments and especially new ideas for the connections to AIM.
> If I'm stepping on anyones toes or others would like to help me be sure to
> contact me.

Thanks for jumping back in here... an AIM transport, or even a prototype
one that kind of works, would be a major bonus.  I had one working at one
point but it was ridiculous :)

I'd like to create some sort of "specification" for how a transport would
work, what it needs to understand, how it can approach the translation and
user interaction, etc... Actually building a transport while doing this
would help tons.  Maybe I'll find a few minutes and get something started
and we can go from there.

Also, let me know if/when you want CVS access, I'd be happy provide space
for the code ;)

Jer