Future of Internet and Software World after Google Wave

[groho]

After posting Google Wave and XMPP ~ Beginning of Web 3.0 I followed the blog and there are two successive posts about future of the internet and probable effect in software world.

ReTweet Future of Internet and Software World after Google Wave

[groho]

This post is sub-titled into the following parts--

The Conversation

XMPP

XMPP Addressing

A Post-Wave Internet

ReTweet Future of the Internet

[groho]

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 are 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.

Have not you ever thought of a new system you would 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 are 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.

[groho]

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. Enough 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. 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.

[groho]

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.

[groho]

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 website 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.

[groho]

One of the fun things about technology disruptions is trying to figure out what the landscape will look like after the main event. It's those changes that nimble businesses can take advantage of to pivot into the new spaces that were created. For example when the Web finally went mainstream it created an entirely new industry, but it then proceeded to change the way every other existing industry operated to some degree, and we're still working through that with things like hosted applications and the SaaS model.

Conversation-Centric Communications

I've been doing a lot of thinking about the impact of a conversation-oriented communications model on application architecture, and the concept of software applications in general. A week or so back I wrote that this was one of the most important bits of the Wave architecture: the way they modeled a conversation in which the idea of a participant is malleable.

It seems like a forgone conclusion that all applications which require use by more than one person will move to this model sooner or later. Just as SaaS apps are becoming mainstream, the game is changing, and the more nimble companies have an opportunity to pivot into a brand new space which is right now being created by this disruption.

While it's fun to talk about these things in the conceptual sense, I think it's more practical to get down to brass tacks and figure out the specifics as much as possible. Here are a few things that I've come up with so far, would be interested to see if anyone else can add to this list:-

Applications will be much less visible. By being participants in a conversation it's natural that applications would work within the existing conversation environment, extending it where necessary. The measure of an application's user-friendliness will now be how well it integrates into a conversation. The days of going to a distinct URL to use software are numbered.

Service applications will grow like wildfire. Some applications no longer need an interface at all, you will simply add them to the conversation and they will do things in the background. For example, adding a text analysis service to a conversation would only require adding it to the conversation, along with its output. Twitter has shown some of this potential, but only the amount that's allowed by its restrictive architecture, API, and medium--that is, not much. You can count on every Twitter application being rewritten to watch conversation hubs.

Applications will be seen more as components, or capabilities, than distinct and unique units of software. Because of the lack of a need for an extensive user interface, and the fact that deployment is as simple as adding an application to a conversation, the very idea of what software is morphs into a capability that you add to your communications rather than software that you purchase and download, or sign up for.

True object-oriented applications will become a reality. Call me archaic, but I hate the current MVC architecture that we're stuck with to get around the limitations of the disconnected Web. It sucks; sorry, face it. With all applications effectively on the same message bus now, and sockets in the browser with HTML5, and linked data on the back-end, true distributed object-oriented programming in the client is closer than you think. Praise God.

The conversation container will become the new AppStore. Adding capabilities to a conversation requires that you be able to find that software and import it into the conversation. The conversation container is king in this respect. There's a big potential here for conversation containers to displace the iTunes App Store as the hottest new software distribution channel. I would be shocked if Google isn't already looking at this--if they have the pre-eminent conversation container then they have an opportunity to displace Apple in the App Store business.

I'm still chewing on this list, but this is what I've come up with so far. There's definitely more, especially in the online identity area, but I'm still digesting that.

All in all I think this is certainly a larger number of disruptions than all but a few people out there are expecting. The first domino is falling, and now it's just a matter of looking at where it's going to fall.

ReTweet Probable effect in software world