First, there were STILL some questions about why exactly Wave and XMPP are so cool.  Well, the short answer to that is that the guys working on Wave did a number of things right.

The Conversation

The first thing they got right is the concept of a “conversation".  This is not some marketing-speak, they actually went and modeled a conversation in a protocol.  That's huge.

Why is this important?  Because as applications are becoming capable of doing more and more on their own, they’re turning into participants in a conversation, not a destination in and of themselves.  The fundamental way you interact with your applications is changing--you’re working WITH them, not IN them.  You are collaborating with your applications, perhaps even multiple applications, in a conversation.

Haven’t you ever thought of a new system you'd like to build and thought that there has to be a better way to interact with the users themselves, at a fundamental level?  Creating a new account in a system and then logging into that system as one of 500 different URL’s that you’re required to remember is just stupid.  It flat doesn’t work.  Turning the application into a participant in the conversation changes that dynamic.  The federation aspect of Google’s extension to the XMPP protocol handles this magnificently, 

XMPP

The second thing Google did right is build on top of the XMPP protocol.  (The protocol is an XMPP extension, look it up.  It runs on an XMPP server, look it up. 'Nuff said.)  This is important because in order to participate in a conversation with someone or something you need to be able to talk to it.  Right now, we are in a world of walled gardens:

• Facebook  
• Myspace 
• LinkedIn 
• Enterprise applications 
• Home applications 

These are very proprietary systems and you certainly cannot talk between them without something translating in the middle.  If you wanted to write an application that worked across Facebook and Linkedin, for example, you'd have to write it twice, and translate in the middle.  And then there is still no standardized way to talk with OTHER applications.

But once you can talk directly with someone or something, bypassing the proprietary gatekeepers, the value of the entire network grows exponentially with each new connection.  Go look at Metcalfe's Law.  I would argue that not only does the value of the network grow exponentially with the number of connected users, but also with the capabilities that those users have when interacting with each other.

The point of the whole thing is that endpoints on the network—whether it’s your phone, a Web site, a client in the browser, can talk directly with each other.  Now, I am quite obviously abstracting away some details here, thanks to everyone who pointed that out :P  Your phone and my phone obviously do not have a direct IP connection to each other.  But think about this:  If a message is *routed* directly to the other device, doesn’t that have the same effect?  That’s what XMPP enables.

XMPP Addressing

Now, HOW does XMPP do this?  It addresses people in the form you@yourdomain.com.  Email format.  This is a feature of XMPP, and the wave protocol does not change this.  Instead of a username on Twitter that only the Twitter API knows how to talk to, or an email address that is a proxy for a username on Facebook or Linkedin, which also requires an API to get to the actual user, you can talk directly to the user.  The domain identifies the server, the username identifies the user on the server.  It's simple, and works well.  XMPP also provides for ways to talk directly to different devices that a user might be on.

This necessitates a server that speaks XMPP on both ends.  That server listens to messages to and from the users on that domain—including applications.  It also speaks with the other XMPP/wave servers across the Internet to syndicate and synchronize data as necessary.  Do you see how this creates an application message bus that works across every network in the world that runs the protocol?

In the same way that companies run their own email servers, they will run their own wave servers.  But not only will the replacement for email be stored on that server, but the interaction with applications as well.  The data generated by an application participating in these conversations lives on the wave server (provider), so you can easily have partners working on your system, in your system, with your system, and in the same conversation, but storing your own data on your own servers.  Now that's what I call collaboration.

Also, there's nothing stopping you from running your own wave server, just the same as lots of people run their own Web and email servers.  It'll be the same thing as email all over again, your ISP might be your wave provider for a while, or your company, or Google, or Hotmail, or whatever.  It's all open-sourced from that perspective.

Remember what I was saying about the existing social networks becoming dumb pipes?  If they don't support wave they bleed users.  But in order to let their users participate in a wave they’ll have to open up the XMPP floodgates.  They will no longer control the conversation between their users end-to-end, in fact users from multiple *social* networks are free to communicate freely amongst themselves.  This relegates the *social* network to a “dumb pipe”, and I’m sure they will fight this tooth and nail.  For everyone else it’s a flat-out win, because they can do more, everywhere.

A Post-Wave Internet

So, stop thinking about where the Google client ends and start thinking about what comes after that, because you can talk to anything now. It is a platform to build on, it comes free with the success of this new communication technology.  

Assume for a minute that Google successfully launches wave and it becomes the next "email".  Think of the possibilities...

• You want to update somebody when their vacation or benefits change is approved?  Have the HR system send a message via XMPP, and listen for it on the other end.  The other end could be a Web app like Google's, a fat client, or your phone. 
• You want to update your team when a critical metric crosses a threshold?  Have your application watch it and then create a new conversation alerting your team.  You could also include a workflow system in the conversation.
• You want your cash register to send your customer’s phone a request for payment authorization?  By all means, send them the request and then listen for the response.  My entire shopping history with you is a conversation, but I’ll keep my thumbprint to myself on my phone, thanks
• You want big flashing lights and a heavenly chorus to play when you walk in the door of your house?  Let your house listen to location updates from your phone, sent by the client and subscribed to by a client on the computer in your house.
• I'd like to keep a running conversation with Amazon about my purchases and recommendations.  I want to include LibraryThing and Mint as well to track other aspects of my reading and financial histories.
• When a customer buys a product, you are engaging them in a conversation.  Especially if it's complex--they ask questions, you answer, they ask for help, you help, you give them tips and tricks, and so on.  Your support systems should be involved in this conversation. 
• When I want to sell some old furniture, I'm starting a conversation with potential buyers.  If I add an auction system to the conversation it should connect me with interested buyers and join them to the conversation. 
• If I answer a customer question, I should be able to pick an interesting bit out of a conversation with a customer and add that to a different conversation that is shared with a wider audience.  Again, people should be able to see this update on whichever kind of device they're using at the time. 
• Meetings spontaneously generate conversations, actions are taken in the midst of this (see the bug assignment demo in the Google keynote), and workflows and external systems are automatically triggered. 
• Reports and information are continuously published to ongoing conversations, updating participants in realtime, regardless of where they are at the time. 
• Sharing is comprised of conversations now, and you host your stuff wherever you want to.  Go check out the photo sharing demos from Google.  File sharing via special services (including social networks) is a thing of the past.  As I said in my last post, storage is a utility now.
• Blog posts like my last one turn into a giant conversation, with all of the various social aggregators like Digg and Reddit turning into participants as well, branching off their own private sub-conversations (wavelets) that only include their own user community.  Or include everyone, whatever.  Subsequent posts, like this one, are part of the same conversation.
• Sites like TechMeme and other "curators" come almost for free.  They're just outlines of conversations, displaying the most active branches. 

I could keep going.  But I won't, because that's your job :)

I hope I’ve done justice to this thought in my head.  I hope that you realize that I'm extrapolating the possibilities IF wave actually gets traction, and this stuff isn't going to come for free with the Google version of a wave client either.  I'm talking about what the ripples will look like across the technology spectrum.

P.S.  A point of clarification:  A Web site like the Google wave client should absolutely be considered an XMPP client.  It doesn’t matter what protocols the Javascript and GWT code uses, that’s irrelevant.  The point is that it’s an XMPP endpoint that a user uses directly.  Do you think users care about whether the browser is talking to the Web server XMPP?  No, of course not.  They get the benefit of the XMPP interaction in front of them and they couldn’t care less if it the browser communication is happening in semaphore.  I am talking about the network itself, you are talking about the form the client takes.

P.P.S.  I am aware of the scalability issues with XMPP.  After reading the Wave protocol specs, I believe that Google has solved this problem with their federation model.  A wave provider serves all of its local users, so the wave only has to be sent to each domain ONCE.  That is key.  Google’s federation model makes perfect sense to me and I see no reason why it can’t scale VERY well.