Tag Archives: XMPP

The end of Google Wave

On May 28th, 2009 Google announced Wave to much fanfare. Wave was going to change the world by merging blogs, wikis and IM and finally replacing email as the digital world’s main collaborative tool.

On August 4th, 2010, 14 months later, Google announced they have stopped working on Wave due to a lack of users.

Despite my interest in the underlying technology, I never used Wave for anything productive. The main reason for this is that I didn’t know anyone else using it regularly. Of course this is the catch-22 faced by every new communications technology and it is at the heart of Wave’s failure. The underlying problem is that Wave didn’t add enough value for users working on a document alone. Wave’s revolutionary power would have eventually come from its collaborative features but the problem with focusing on these aspects early is that they do not add any value until there are users to collaborate with. In episode #68 of This Week in Startups, Marco Zappacosta defines the amount of value a service brings to users without network effects as network independent value (NIV). Wave had next to zero NIV.

It didn’t have to be this way. There are several aspects of Wave that could have been focused on to create a superior or at least unique single user experience. The most obvious would be to have made basic document editing and management a better experience. Or they could have focused on use cases not supported by other document systems. The Wave API allows for third party applications (bots) to contribute to documents at the same time as users. This could have been used to build bots which automate tasks that are time consuming or annoying in Word or Google Docs. On the collaborative side, Google could have concentrated on a specific, practical use case such as a shared white board (there are several bots which do white-boarding) or built interesting applications such as Gravity by SAP.

Wave’s failure saddens me because Google was really doing this right. They were publishing the protocol specifications and most of the source code. Even more importantly they architected Wave based on a distributed/federated model which allowed for Wave servers to exist within every organization just like email servers do. This is a much harder problem than a centralized, all Google architecture but it is critical that single organizations do not control (what could have become) a core Internet protocol.

One also has to wonder where the revolutionary innovation that is required to replace email will come from if even Google gives up after only 14 months. Wave represents a large change that requires time to diffuse and for infrastructure to be built up around it. It is completely unreasonable to expect that Wave would have had large success in just 14 months. One has to feel for the Wave team whom it seems were given the impossible mission of changing the world in 14 months.

I believe that years from now we’ll look back on Google Wave and realize that it was closer to the solution than we thought. One of the key features that makes me believe this is the bot API. The idea of allowing third party applications equal access to a live document is very powerful and could spawn huge amount of innovation. For example, there is no competition to Microsoft’s grammar checker in Word or Google’s spell checker in Google docs. There cannot be as these are functions which are part of the application. Now imagine a world where a document system like Wave is the norm. Any user could select which spell checker to use just by adding a different bot to the Wave. I believe this flexibility would spawn competition that would drive a great deal of innovation. This speaks to the power of decentralized systems such as Wave.

There may also be an opportunity for a startup or open source project to take the Wave ecosystem and run with it. A lot of the hard work has already been done.

ejabberd default permissions

I upgraded my ejabberd to 2.1.0-rc1 today and while doing so decided to start with a fresh ejabberd.cfg. This reminded me of something I noticed when I first switched to ejabberd but forgot to blog about. The default permissions in ejabberd are a bit surprising.

Before I go into details, I’m not arguing any of these problems are the end of the world but I think it would make lot of sense for ejabberd to ship with a safer configuration and allow administrators to open things up if desired.

MUC permissions

The default MUC (XEP-0045) access list is:

{access, muc, [{allow, all}]}.

This access list allows all JIDs, even those on remote servers. The default MUC configuration uses this access list for all operations.

{mod_muc [
    %%{host, "conference.@HOST@"},
    {access, muc},
    {access_create, muc},
    {access_persistent, muc},
    {access_admin, muc_admin}
]},

As a result, the default configuration allows users on other XMPP servers to create rooms on the local MUC server. Probably not that big of a deal but I don’t see a good reason why my server should be hosting channels for external users. Worse, would I be responsible if the channel was used for some nefarious purpose?

I created a new access list which only allows local JIDs and used this access list for access_create and access_persistent.

{access, muc_create, [{allow, local}]}.
{mod_muc [
    %%{host, "conference.@HOST@"},
    {access, muc},
    {access_create, muc_create},
    {access_persistent, muc_create},
    {access_admin, muc_admin}
]},

Pubsub permissions

The default Pubsub (XEP-0060) permissions are:

{access, pubsub_createnode, [{allow, all}]}.

Again, this allows all JIDs, even remote ones to create nodes on the Pubsub server. I changed this to the following.

{access, pubsub_createnode, [{allow, local}]}.

In-band registration

This really amazes me. In-band registrations (XEP-0077) allows users to connect to an XMPP server and create new accounts. This is enabled in the default configuration that ships with ejabberd.

{access, register, [{allow, all}]}.

I wonder how many ejabberd servers there are with unexpected users?

The solution is documented immediately above the register access list definition.

{access, register, [{deny, all}]}.