Jabber on Notes

Google Talks, bullshit walks

melo@simplicidade.org (Pedro Melo) — Wed, 24 Aug 2005 11:06:50 +0000

Ok, it’s out for real. First things first: question 15 of their FAQ, first paragraph, last sentence:

We can say this, though: we believe strongly in user choice and open standards, and we are committed to letting users access Google Talk using the client and platform of their choice, as well as to enabling our users to talk with users from other service providers.

Emphasis mine. The entire point is clearly stated in question 16 though: we are in business to open up IM networks. The developer FAQ is also filled with “service choice” questions and answers. But it’s also filled with federation stuff. They want to balance openness with security. I’ll guess we need to wait to see what that really means.

So although the SRV DNS records for server-to-server are still MIA, I suppose its just a matter of time. The subject of SRV recored is specifically covered in the developer FAQ.

I haven’t downloaded the Windows client, being on a Mac myself, so I’ll check the other reviews to figure it out some more. Main features seem to be: no ads, voice (SIP in the future, according to the developer FAQ, and we can speculate that the door was left open to IAX), Gmail address book integration.

For me, working at Sapo in the XMPP area, and being in the team that launched a XMPP/VoIP client last July, it’s exciting to see some of our decisions validated by Google. Also, it’s nice to see some of our regrets also validated by Google. They are not using SIP for signaling, they are using some custom made signaling protocol over XMPP. There is a rough standard to do SIP over XMPP called TINS, but Google seems to have taken their own route. We can only hope the they will honor the community by writing a JEP about this custom signaling protocol.

In terms of Codecs, we are compatible with Google using iLBC, and G711. They don’t have Speex yet, though.

Some reviews, more to come:

Julian’s take: no offline messages, also talks about the custom voice signaling protocol Google is using, and possible iChat integration in the future. This one seems a no brainer as long as Apple and Google agree to it: they are both using Jabber.
Nat’s O’Reilly Radar entry: that get’s the quote of the day so far: make MMS messaging on cellphone look like a W3C hot-tub party.
Russell Beattie about Y! and XMPP, we are all pulling for you, Russel
Download Squad: speculates to new features, we should see a lot of that in the future :)

Some first comments about the client from the reviews:

900kb download (!!), that’s impresive. Must check if it’s just the installer or the real thing;
very clean interface.

Google Talk is live

melo@simplicidade.org (Pedro Melo) — Wed, 24 Aug 2005 00:42:55 +0000

Google Talk service is now live although you still get a 404 at the site. I was able to connect with Adium using Jabber as the account type, and my gmail login.

Some notes:

this is NOT jabber, it’s XMPP: Google Talk requires TLS for connection at port 5222;
Server-to-server is not yet operational, don’t know if it will: SRV DNS records are still MIA;
Port 5223 is open and Psi with SSL can connect. I used “Allow plaintext password”, but I’m not sure if it is required;
Disco queries and Jabber:iq:agents return 503 for now;
Gmail address book integration: your buddies appear in your contacts inside GMail;
The other way around: Gmail contacts with a @gmail.com address appear in your roster with subscription none. Current clients don’t send the invitation automagically for now :).
1:41 WET: got kicked, server restart or premature err… launch? :); 2:33 back on.

Some other articles about this:

Smash’s world: I found out from this article
Rui’s take, although he hasn’t updated yet it’s page :). Ok, now he did, but use this instead
My dear friend pfi, to the point as usual :)
Celso’s point of view, lot’s of good stuff that I won’t duplicate here with one exception: federation not good.
Bob Wyman at his best: use XMPP to track XMPP news. And also talking about Yahoo! and XMPP.
A new edition of Jabber Journal, with lot’s of cool information

My take: I’ve been following XMPP for some years now, and tomorrow it will be a big day for all of us who believe that it is a excellent technology for IM and presence applications.

Although the service is still pretty basic, we are still poking in the dark to see what is out there. The small Gmail address book contact is something that a lot of people have talked about, but it might be the tip of the iceberg yet. I personally can only think about a Google-scale pubsub service. Imagine all those Google APIs with a push model to your desktop, using your XMPP stream. Bob Wyman is also talking about this.

Also, notice that server-to-server connectivity is still not there. And that’s the big one for me.

Will Google open up it’s network? I really really hope so.

In the following days and weeks to come, I’m going to find it interesting to see Yahoo, Skype and AIM response. MSN will be fun to see, at best.

AIM already has a server-to-server XMPP connectivity, but only to Jabber.Inc customers and the price point is not something to brag about, I’ve been told.

Yahoo and Skype don’t seem to have many technology barriers to implement a XMPP server-to-server gateway: all their clients share a single domain name under their control.

As for MSN, well, the only domains that they can open up to XMPP is the ones they control: hotmail.com. All the other MSN users that use their own email address to authenticate themselves into the MSN network are out of luck.

This new service, for those of us who work in the instant message area, is not a small issue, and it’s not hype. IM networks have been for some time isolated, closed islands, in which the only ways to interop are reverse-engineered software bridges like pyMSNt, pyMSNt or pyICQ, to name just a few.

But having a big name such as Google opening up it’s network, we get traction. Maybe enough of it to level the playing field.

It’s going to be a hell of a ride…

Technorati Tags: google, jabber, talk, xmpp

Forked files and Tiger Server

melo@simplicidade.org (Pedro Melo) — Mon, 02 May 2005 13:15:44 +0000

AFP548 - Tiger Server Overview: > Another welcome feature is a new API that lets traditional UNIX tools such a cp, mv, tar, and > rsync work with forked files. This should open up a much easier world of scripting > for Mac OS X.

This is way cool! At last! Can anyone confirm that rsync that comes with Tiger Client is already using this API?

Update: More information from Michael Tsai - Blog - Random Tiger Notes: > A Mac-savvy rsync was, for me, one of the most anticipated features of Tiger. Unfortunately, it’s been unreliable so far. Nearly every time I use it to sync a large folder using the -E flag, it either crashes or stops with an internal error. > The Mac-savvy tar, cp, and scp rock. So does BOMArchiveHelper.

Again from the AFP548 - Tiger Server Overview: > Secondly, we have synchronized mobile homes now! Macintosh Manager > had a “Check Out” feature that would sync your data down to a > workstation and then sync it back when you checked it back in. Tiger > brings a new feature called Portable Home Directories that allows > us several ways to synchronize the mobile home to the network one. > You can define how the sync takes place in Workgroup Manager’s > Mobility preferences. The Portable Home Directory is synchronized > on it’s first login after creation and is then kept synchronized in > several ways. You can define a periodic background sync, or a login > or logout sync. Also the user can select Sync Home Now from the menu > bar at any time. You can also specify rules to determine what gets > synced, for example you might not want to sync the Safari cache folder.

This is so cool. I have to find a way to put a 10.4 server at the office, even if inside a Mac mini.

The bad part: the VPN server did not change much. We are using the 10.3 version at the office and I would like to have firewall and routing tables per user. Doesn’t seem that we are getting them.

Also the XMPP server included is based on Jabberd 1.4.x, which is too bad. I was hoping for a more recent server, maybe one of the new ones in Java. Hoping for ejabberd was a bit too optimistic.

Johannes Ernst's Blog

melo@simplicidade.org (Pedro Melo) — Sat, 30 Apr 2005 13:45:52 +0000

Johannes Ernst’s Blog:

I’d like to suggest that some of the world’s most successful distributed software architectures are neither client-server nor peer-to-peer when you look at them closely. They follow an architectural pattern that I’d like to call the 4-Point Architecture.

I like his point of view. Yet, I don’t think that all of the rules make sense. In particular:

No dark point ever interacts directly with another dark point, they always go through their respective bright points first.

That’s not right. I mean it does not scale. Imagine VoIP or other stream-oriented medium to high-bandwidth protocol. It just doesn’t scale unless you throw huge amount of bandwidth to the problem.

Most of the architecture presented seems right, but the bright points should also allow for point-of-meeting to the dark points so that they can agree on a direct connection if at all possible due to NAT/Firewall restrictions.

Update: Johannes comment (thanks, btw) below that it’s true that dark points can talk to each other due to performance issues. He’s right, that should be the only reason. Of course, my comment about his architecture was just a minor pet peeve. I do agree with him about the rest.

Psi nightly builds

melo@simplicidade.org (Pedro Melo) — Fri, 15 Apr 2005 11:38:14 +0000

So I’m a lazy bastard, so far nothing new. But I also want to look at the latest Psi, ze mozt powerfull Jabber client out there, releases for Mac, and lo and behold they have nightly builds…

This is the script I ended up with to update my Psi every day:

melo@RoadRunner(~/Desktop/psi-night-build)$ cat update_psi.sh
#!/bin/sh
#
# Updates Psi with latest nightly build
#

today=`date +%Y%m%d`

if [ -d "psi-mac-$today" ] ; then
  echo "You already have build $today, restart your Psi to use it, maybe?"
  exit 1
fi

curl -O http://spike.ulyssis.org/psi/mac/psi-mac-$today.zip

unzip psi-mac-$today.zip
rm psi-mac-$today.zip
rsync -a into_frameworks/ psi-mac-$today/Psi.app/Contents/Frameworks
rm -f psi-latest
ln -s psi-mac-$today psi-latest
growlnotify -n "Psi Nightly build updater" -s -a Psi 'Psi is updated!' <<EOF
You Psi was updated with the latest nightly build, $today. Please Quit and restart you Psi.
EOF

Make sure you chmod 755 update_psi.sh.

Now you just need to restart you Psi every morning after the nice growl notification appears. I keep ~Desktop/psi-night-build/psi-latest/Psi.app on my Dock.

Couple of notes: on the directory where you run update_psi.sh, you must have a directory into_frameworks. Inside you need to put all the Frameworks required to run Psi. Right now, you need to have the libqt-mt.3.dylib (found on the same directory where you can find Psi nightly builds), and the Growl framework.

I used the copy of the Growl framework that comes with Ecto. Use locate Growl.framework to find a copy on your system, and copy it into into_frameworks.

My into_frameworks looks like this:

melo@RoadRunner(~/Desktop/psi-night-build)$ ls -la into_frameworks/
total 18376
drwxrwxr-x  4 melo  melo      136 15 Apr 11:01 .
drwxrwxr-x  9 melo  melo      306 15 Apr 11:29 ..
drwxr-xr-x  7 melo  melo      238  4 Apr 04:17 Growl.framework
-rw-r--r--  1 melo  melo  9404804 16 Aug  2004 libqt-mt.3.dylib

The main directory where I keep update_psi.sh looks like this:

melo@RoadRunner(~/Desktop/psi-night-build)$ ls -la
total 128
drwxrwxr-x   9 melo  melo    306 15 Apr 11:29 .
drwx------  23 melo  melo    782 15 Apr 11:21 ..
drwxrwxr-x   4 melo  melo    136 15 Apr 11:01 into_frameworks
lrwxrwxr-x   1 melo  melo     16 15 Apr 11:12 psi-latest -> psi-mac-20050415
drwxr-xr-x   5 melo  melo    170 15 Apr 02:25 psi-mac-20050415
-rwxr-xr-x   1 melo  melo    598 15 Apr 11:27 update_psi.sh

Although the Growl framework is required in latest builds, I cannot seem to get it working. If you know how, xmpp me at melo funnychar simplicidade.org.

Update: Growl works very well if you use the Remko versions. See his Psi page.

Update 2: small bug in the if [ -d ... in the script, change “ to “”. Thanks go to rebarbado.

Do you know your friends?

melo@simplicidade.org (Pedro Melo) — Sat, 09 Apr 2005 12:41:14 +0000

I was looking at the demo video of Locus and talking with Rui.

Locus analyses your chats (Jabber-based but you could use over anything, even multi-protocol) and creates a bayesian profile of your friends. It’s then able to create connections between friends sharing the same interests.

The interesting part of the idea is that you could extend it beyond chat, into mail. You could link all your own friends interactions (mails, chats) to find hidden links between people.

That would be…. interesting.

An extreme example from my chat with Rui: “Locus wants to know if you’d like to meet Mandy. Mandy is an air hostess that enjoys Macs, scuba diving, raw photography and bayesian filtering”.

A dream come true to a special common friend of ours.

Examples of notifications via XMPP

melo@simplicidade.org (Pedro Melo) — Fri, 03 Dec 2004 14:37:45 +0000

Yesterday, I wrote an unusually long article about IM systems as a transport mechanism to notifications.

I got a comment from Bob Wyman, of PubSub.com fame, getting my attention to PubSub usage of JEP-0060 as a prospective search mechanism.

Well, I didn’t forget. I use it everyday. I have a pubsub subscription on “JEP-0060” and less than 30 minutes after I posted my article, my pubsub feed was telling me that I had a new article, my article. So it works extremely well.

PubSub is without a doubt the largest implementation of JEP-0060 I know about. The other big implementation is also a service I use a lot: Mimír. It sends me messages whenever certain feeds have new items. It also does aggregation of items while I’m offline, and send’s me a summary whenever I get back online. It’s an excellent service, and it’s also supported with JEP-0060 (ralph, the Mimír creator, is also the creator of Idavoll). Since I subscribed to mimir, I dropped a lot of subscriptions from NetNewsWire, and my RSS reading in the morning is now much more managable.

Both of these systems work very well, and with a decent IM client, I also get Growl notifications of the items. Is pretty cool.

One thing I wonder is if Mimír receives updates via JEP-0060 from pubsub.com? That would interesting. It doesn’t seem so, looking at the architecture of it.

XMPP, Jabber and Growl: notification systems

melo@simplicidade.org (Pedro Melo) — Thu, 02 Dec 2004 13:30:44 +0000

Updated: fixed all the links, sorry, I’m a markdown beginner. Thanks Ralph.

Rui did some work on growl remote notifications, and then he made a question: why don’t we make this a standard? In doing that, he also talks about Jabber and the failure of that project. I don’t agree with the last part at all, and I’ll try to answer his question.

First, let’s talk about Growl. I really really like Growl, I think it is the second best thing that has happened to the Mac this year (the first being Quicksilver). I like the fact that with it I can have a single app and a single prefpane that controls all my notifications. I even changed IM clients (from Proteus to Adium) because I could not find Growl support in Proteus, and Adium 0.7 had it.

But Growl has some problems. First, I don’t have a history of notifications. Sometimes I’m away from my TiBook, and I lose notifications. I don’t have a place where I can see the last 20 minutes of notifications.

Second, when I’m offline, I cannot receive notifications, and while the servers could keep on trying to send them, it wouldn’t work very well. The moment you get online, you’re bombarded with notifications, so you’ll probably just skip most of them. If you want to see what I’m saying, download Rawr-endezvous, connect your Mac to a local network with lots of other Macs, and fire it up. Expect to be looking at several screens worth of notifications.

Third, you can specify a title and a text for each notification, but you cannot follow it through to the tool/site/server where you can fix the problem. Growl really needs support for a URL, a clickable one. The lack of a “tell me more”-action limits the usefulness.

Fourth, I have 200+ systems, in several places, behind several types of firewalls. My own laptop is behind another corporate firewall, and I don’t expect the local firewall admins to open up yet another port for notifications. Also, I don’t think it is reasonable to have systems on the other side of the planet sending me notifications directly to my laptop.

Growl is the last mile of notification systems. It’s a personal notification system, not a network notification system. Does it need to receive events from the network? Sure! Should we create another protocol for that? Maybe not.

A network notification system needs a lot more than displaying the notifications. It needs aggregation of events, it needs to know that the user is online or offline, to route the notifications to the most available person to handle it. And that brings us to IM systems.

If you use an IM system for transport of notifications, you get a lot of those things for free. When I say IM system, I don’t limit myself to XMPP/Jabber. You can use SIMPLE if you want. I really don’t care. I use XMPP/Jabber because that’s what I know. I’ll use XMPP in the rest of this article because of that. Fell free to s/XMPP/IM system/g.

With XMPP you get a lot of things out-of-the-box: * You get an extensible protocol; * You get all the authentication stuff (with TLS support); * you get a bi-directional protocol, so you can ask the source of the notification “Tell me more”; * you get a global scalable reliable protocol; * you get powerful publish/subscribe primitives.

Let’s look at each of these in turn. XMPP is an extensible protocol and that allows you to define new packets (stanzas in XMPP lingo) to transport all the information and semantic hints you want.

You can ask people who know me, I’m not a big fan of XML. I think it is over-hyped and over-used. It seems that, like IBM mainframes in the 60’ and Cisco gear in the 90’, you won’t be fired if you use them. XML is also lousy for transport of information. Network protocols should be efficient and XML is not. An XML parser is more complex and heavy than a XDR or ASN.1 parser, for sure. Also the amount of useless information in XML is very high. Huffman must be turning in it’s grave.

I don’t see XML as the reason for XMPP extensibility, I really don’t, but XML is a very high-level method of encoding information, and for now it helps to use it as the base of XMPP. Eventually, you could put a XML dictionary-based compression scheme between XMPP clients and servers, and still use the same protocol. Only compressed in transit. Gzip is also an option, and it’s even mentioned in XMPP RFC (this is from memory, I need to check the negotiation phase).

Before people start telling me something like “you stupid person, my p4 x ghz machine does not have performance problems with XML”, or “you moron, my 2mbit ADSL is mostly empty, so if I need 400 bytes to send a simple hello, that’s not a problem”, I have two things for you to think about: * always-on mobile networks will charge you for bytes transfered, at least in the mass-market plans; * it’s a waste of resources having 20000 clients connected to my server and having 20000 XML parsers: machines don’t need human- readable protocols.

Back to our list, the second point is TLS support. It’s mandatory in XMPP. It’s a standard, it works and it’s well understood.

The third point is bi-directional protocol. Having a bi-directional protocol allows you to use your notification system to query your systems. It allows your notifications to be short and to the point, giving you the possibility to ask for more information, so that you can correctly evaluate the problem.

The fourth point, a scalable network, is very important if you have more than 50 or so servers. You need aggregation points for notifications, and you need server-to-server communications. You also need reliability, you need the assurance that if an application sends a notification to the local notification center, the message wont be lost (insert regular acts of god disclaimer here). You need store-and-forward semantics, or end-to-end acknowledge of notification. Maybe a mix of both.

Finally, you probably work in a team, with a on-duty staff, and with escalation procedures for notifications. If a disk is 100% full, I don’t care if you’re offline, someone must be notified, right? Here we get into pubsub systems, probably the best way to deal with the problem of one to many communications right now. You can subscribe to applications, servers, clusters, any node or object in your infrastructure. It’s your decision, it’s under your control.

Pubsub is available in XMPP in two forms: the lazy one, and the standard one. The lazy one is multi-user chat rooms. You can use a multi-user chat room as a basic quick and dirty pubsub. Just create a chat room for each topic. Whoever wants to be notified, just joins the chat room. It’s a one-to-many system, and it works. Imagine this: all your mail servers connected to the same chat room, and having one of them say “Hey people, this dude at 127.0.0.1 is spamming me hard. block the sucker”, and having all the other machines in the cluster do it. You can even go into the chat room to monitor those events, or even to say “guys, unblock 127.0.0.1, please”. Yes, notifications can be sent between applications.

The standard for pubsub is JEP-0060, and you have at least two implementations today: ralph’s Idavoll and ejabberd (which also seems a very nice, mostly-XMPP compliant server. If only virtual hosts where supported…)

So with all of this, using an IM protocol for transport of notifications has a lot going for it. XMPP is by no means perfect. I’m still not sure if XMPP can really assure delivery of messages between servers. I don’t think you have the same store-and-forward with acknowledges you have in SMTP. And I really think that a low-bandwidth version of the Jabber network protocol is needed. But it’s a start.

So answering Rui’s question: why not make Growl a standard? Well, by all means, do it. But as a last mile solution for the notification problem, not for the network part of the problem. The network part is complex and we already have protocols that do it very well, we just need to glue them together.

How do we do that? Well, I have an idea, but I’ll need to talk about something else first, to clarify something about XMPP/Jabber that Rui also mentions (yes, the “jabber is dead part”…).

Saying that XMPP is an IM protocol, is like saying that SMTP is for sending text messages. Yes, you can do it, and it’s probably the most common use. But XMPP is so much more if you look into it. It has a powerful resource discovery protocol (See JEP-0030) and at least one decent client implementation, Psi, very decent publish and subscribe capabilities, and it also does IM :).

Regarding the lack of clients, my answer is “it depends”. You can have great clients today if you want the IM part only. Adium works very well, Fire also works OK. If you really need a XMPP client (and that’s an entirely different ball game), then no, there aren’t any good clients out there. Again, Psi is probably the best one.

The way I see it, XMPP is much more powerful than traditional IM systems, and most client implementations stop after having the IM part done. The rest of the XMPP doesn’t seem to have reached critical mass. In XMPP, you can use pubsub to publish the current music you are listening to, and I can subscribe to that topic to know that (and then probably use Growl to tell me whenever that changes). But there is a lot of framework missing that needs to be in place to make it work: how does my XMPP client talk to my music player? In a Apple environment this is a little bit easier, due to the iTunes domination, but these are the problems that face XMPP extensions adoption for now.

Now back to Rui’s answer: how do we do it? Well, you could build a XMPP client not for IM, but for notifications only. Your own personal notification avatar. Julian mentioned this recently. You can even built it into Growl itself.

This would allow you to use Growl to subscribe to topics. You still need to solve Growl shortcomings (at least the lack of URL support), but the rest is pretty much already in place.

My own jab at the problem, Ambrosio, does some of it, but I’m still finishing it’s infrastructure to be able to do what I’ve been talking about. We’ll see what happens in the next weeks.

IETF Publishes XMPP RFCs

melo@simplicidade.org (Pedro Melo) — Tue, 05 Oct 2004 11:16:29 +0000

IETF has published the XMPP RFCs. This is great news.

I don’t expect the world of IM to switch to XMPP, but if the large IM networks open up, my only hope is that they choose XMPP as the public protocol. I guess I’m a optimist :)

Ambrosio is useful now

melo@simplicidade.org (Pedro Melo) — Tue, 27 Jul 2004 16:05:38 +0000

The latest version of Ambrosio is now useful. You can now send notifications from scripts or applications you write.

I did this last sunday but I needed to write a small manual for notifications.

New version of Ambrosio

melo@simplicidade.org (Pedro Melo) — Fri, 23 Jul 2004 16:21:11 +0000

Ambrosio is almost ready for major deployment. A new version is available (0.3), and now you can subscribe the bots presence.

The roadmap is something like this:

Finish Notice plugin: you drop small files in a specific directory, the local bot will pick them up and forward them to the JID's specified in the file - this allows for other scripts or applications in each one of your servers to send notifications;
Better management of notifications and presence: don't send notifications to people that are away or disconnected.
Multi-User chat support: its going to be nice to enter a room filled with your webservers and tell them all, restart apache, or having bots talking to one another like people, bloody harvest at IP_ADDRESS and have all the others block that IP via iptables
Log watcher: probably just a gateway to a local swatch application?
Start to think about a meta-bot: a bot controlling the other bots - he can receive notifications for disconnected users, and decide what to do with them:
- forward part of the notification via SMS?
- send a URL pointing to the note?
- keep a log of unread notices?
Each plugin could have variables that he was willing to supply to some one: uptime can have the load, df can have free_kb_partition. These variables can be watched (you get some notification if they change, or if they trigger some threshold), or even logged (sql or rrdtool).

I have more ideas, some totally crazy (like having a pam_bot that asks the admin of the machine if the person trying to logging can do so before allowing it :) ), others more useful.

Remember that the core of Ambrosio is likely to change in the near future. The plugins will most likely be compatible. But the core will change a lot!.

Ambrosio

melo@simplicidade.org (Pedro Melo) — Wed, 21 Jul 2004 15:32:00 +0000

Ambrosio is a POE Jabber bot that you can run on each server you manage.

It gives you three commands: uptime, df and ps. It also responds to help.

It’s pluging based, you can extend it easily. In the few days, I should post plugins to control access to those bots, notification of events on other applications, and more commands.

It’s a proof of concept only. I’m doing it to gain some experience with POE::Component::Jabber::Client and other stuff. It will evolve into a small framework for making multi-network bots.

You can find it here.

Oh, BTW, it requires a modified POE::Component::Jabber::Client::Legacy module (included in version 0.2 and above). The CPAN version doesn’t seem to allow automatic registration, and I needed that. I have to cleanup my patch and send it upstream to Nick.

Yahoo changes IM protocol

melo@simplicidade.org (Pedro Melo) — Fri, 25 Jun 2004 12:41:25 +0000

Yahoo changed their IM protocol once again. The official reason is to prevent IM spam (or spim). I felt this in the flesh yesterday, when my client Proteus refused to connect to Yahoo network, but I didn’t have a clear opinion about this. Parts of Jeremy post helped me put it all in perspective.

First, I never got IM spam over Yahoo or any other network, so my perspective over this could be somewhat biased.

IM spam is nothing like mail spam. IM solutions have from the start the concept of establishing a trust relationship between two users. All the clients I know have a checkbox (the good ones make it the default) that only allows people in your buddy list to send you messages. So the spam issue, at least for me, is a non-issue.

The other issue people are talking about is that “It’s Yahoo network, it’s Yahoo protocol, and it’s Yahoo resources, so they can do with them whatever they want”. Well, yes it’s true. But thats a shallow analysis of the problem.

Think about why trillian and others have to, or want to reverse engineer the Yahoo protocol. I came up with two reasons:

there is a user demand of a multi-network application: my friends are in multiple networks, and I want to talk to them without having to run multiple clients;
Yahoo does not have a open-protocol gateway to the outside.

The first one is interesting to me: the current official clients for the major networks are not good enough, they have limitations, because they cannot connect to multiple networks. So the market has this need, and the major networks choose not to compete, but to stifle competition by starting a arms race that they have little chance of winning, while pissing of their own or potencial customers. Smart, eh?

The second is more subtle. Given that the spam issue in IM networks is moot, I don’t see a reason for Yahoo and the other networks not having a open transport gateway. Jabber or SIMPLE, for instance.

In my view, if they had one, they would be giving more power to their own users, and give them a reason to stay with Yahoo network, and use their own client. It would become the race for the best client, and frankly, I don’t see what Yahoo and the others fear in that race: they have the resources and the content integration to provide the best IM client out there, hands down.

Imagine this: Yahoo and the others open up a Jabber gateway, and launch a new client to match. “Talk to anybody in the world, and you can still get personalized news feeds, your calendar, your mail notifications, in a single app”.

I’m a believer in real-time always-on internet. I don’t need super-amounts of bandwidth, but I need it there, all the time. I would love to see a application that would be the center of my internet presence, gathering all my friends, all the events of my online life: mail notifications, IM messages, calendar notifications, new post in my favorite feeds. I see it as: a social network-based app (maybe Google will open Orkut via an API…), with touches of dashboard for cross-linking of information. Add mobile connectivity (GPRS or better), a PDA or smart-phone, and your done!

We can only hope…