>Proposals: >1) & 2) & 3) & My proposal: >... >AOL comes over and decides to be a cheater and signs on as a >user/server. Then it queries the registry directly for the list of servers >and kaboom, all the Smart Forwarders just became Dumb Ignorant Idiots.. >:) Thus I think a certificate-based authorization is required to connect >to the registry. The certificates are only issued to those that are >approved. Bigger overhead, but it will lead to better interoperability. >What do you all think?
That would sort of make the Jabber community more "closed", and even then AOL will still kill it when they see too much traffic coming from one IP adress.. (maybe they'll just do a quick nmap to see if any jabber server is running on it).. It's still a lot of effort for something that's basically at the mercy of AOL. You also forgot to include one proposal, letting the server do the conversion between the xml jabber protocol and the property protocol (like it does now) but then send it back to the client, to let the client send it to the the property format. This however still excludes mobile clients. Maybe a combination of this system and your proposel would work best.. For example let's say my client wants to comunnicate with AIM, it sends a message to the aim transport like it normally would, then AIMt let's the client choose wether it wants to get the converted binary data back itself (you are the "redirector") or wether it wants to choose (or let AIMt choose) another (public) "redirector" for this binary data.. (these two steps could be made into one ofcourse) This requires some work to implement (a bit too much if you ask me) just cause AOL doesn't want to play with us, but it would be the only solution that would hold out for a while (maybe long enough for jabber to grow big). It does need more up to date transport codes, but knowing that all the work you did for it won't be swept away because AOL decides to block server IPs might be a bit more motivating for the developers. Implementing the streams of binary data etc. is ofcourse a lot of work, but I think manny agree that stuff like OOB data needs some work too (out of band data doesn't always have to be file tranfers, can be a full duplex binary stream as well), wich ofcourse could be used for this. Better specifications and implementations (one good lib could be used by all the transports) of OOB data wouldn't hurt anyone I think :) Advantages of this method: - you can choose between privacy & security (the only one who sees your data is you and the server,ofcourse you still need to trust the server, see below) or a client that's not any more complex then todays (for mobiles etc.) that unfortunaly has to trust others with it's property IM sessions. - these public "redirectors" for the binary streams don't have to be full featured jabber clients (maybe they can be, but they don't have to be). They'll be extremly simple programs. With some options to let it limit CPU and bandwith usage I think you can find a lot of people willing to run something like this.. (pissoffAOL@home anyone? :) - almost transparant intergration with todays clients, the redirector program can run seperate from your client on your own machine, so no need for all the clients to implement this on their own. - it works! AOL can't block *every* IP outthere.. espc if you choose to let your own computer handle all the streams. they simply can't block you on the IP level. Maybe they can still find some things that are wrong with the protocol, but this was always the strenght of Jabber, these things can get adjusted serverside, updating all the clients at once. - maybe this model can be used for more then just chat transports.. who knows what usefull things will come out of it :) also some good OOB data specs would be welcomed by the community.. Disadvantages: If you choose to handle your own binary streams (you are the "redirector"): - adds complexity to the client (a bit), still acceptable for desktop machines though - Security: you have to trust the server you connect to, the server has control over binary streams that are send from *your* computer. Restricting your "redirector" to connect to only the IP's you want is a requirment, else it's too much open for abuse like DDOS attacks. This requires a Jabber client to know where the AOL server is wich is a bit against the Jabber design philosophy.. still acceptable though IMHO. With this securty measure in place the only thing it could be abused for is a DDOS attack against eg. AOL (if that's what your "redirector' is allowed to connect to) or that your redirector is used for sessions that are not your own (yey appear to come from your IP). Again.. if you trust the server you connect to this is all not a problem.. if you choose to use a public "redirector": - Security: your data travels over other peoples redirectors.. However if you trust the server, and the server only connects to trusted redirectors (or you can tell the server to connect to one, for example I could use my desktop machine to "redirect" for my cellphone) this could still be within the limits of reasonable security. You always have to trust your server anyway, and if you thought your IM sessions on ICQ, AIM or MSN were safe in the first place you needed the wakeup call anyway. (If they were they'd use something like SSL and it wouldn't be a problem redirecting them over servers you don't trust anyway) The biggest disadvantage of this probably is that noone wants to build it.. for now we'll just play cat and mouse with AOL for a while (there's manny manny different IP adresses we can use for our AIM/ICQ transport.. I wonder if they'll really block them all.. :P). Maybe if it doesn't work out that way we'll free some resources for this.. but for now I doubt I can do it on my own.. (not familiar enough with jabbers internal working yet).. Even though probably noone wants to make something like this for now, it could still be intresting to discuss what the best and most efficiant way of solving this problem is.. :) -- Tijl Houtbeckers GPRS / J2ME programmer Druppel Internet Services, The Netherlands _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
