_____                   _                  _____            _____       _ 
  |     |___ _____ ___ _ _| |_ ___ ___ ___   |  _  |___ ___   | __  |___ _| |
  |   --| . |     | . | | |  _| -_|  _|_ -|  |     |  _| -_|  | __ -| .'| . |
  |_____|___|_|_|_|  _|___|_| |___|_| |___|  |__|__|_| |___|  |_____|__,|___|
  a newsletter by |_| j. b. crawford               home archive subscribe rss

>>> 2020-09-02 not so instant messaging (PDF)

There are various phenomena that make instant messaging a strange beast today, one that has surprisingly little resemblance to its former self. Broadly speaking, the main motivators of change seem to be that conventional instant messaging platforms (e.g. AIM) proved difficult to monetize, and the post-2000s radical success of social media (as a monetizable platform) essentially requires that any successful communication product have a significant social media aspect.

Let's take a look at a few specific examples of the instant messaging landscape today.

Google is, as usual, one of the easiest to poke fun at. Google Talk was an XMPP-based instant messenger that popped up in the sidebar of GMail in 2006. As a fairly standards-compliant XMPP implementation, Google Talk could be used with any of a number of third-party clients, but Google also released a desktop client of their own. Google Talk behaved basically how you would expect, very much like precursor products like AIM. Further evidence of the coming mass adoption of XMPP emerged when Facebook announced their own integrated sidebar instant messaging which was, once again, XMPP based, permitting the use of third party clients in addition to their own.

Just a few years later both vendors had abandoned their desktop clients and were backing off on XMPP support, with both relegating XMPP to "legacy" status and then completely dropping XMPP support.

What can we learn from this tale of woe? Perhaps nothing, but I think that it relates closely to two fundamental challenges that all federated/distributes systems face:

1) Federated systems are generally more difficult to monetize. The lack of central control makes advertising display less practical, and commercial services (that is, subscription based ones) generally have little motivation to implement federation and some motivation not to, as the federation interface provides an opportunity for a free implementation to wipe out the market.

2) Federated systems are more difficult to develop, maintain, and especially enhance. The protocols underlying federated systems generally ossify more or less instantly. Without very careful design, it's easy to get into a situation where a feature cannot be changed or implemented without breaking federation, and it's impractical to update the entire network at the same time. Even with careful design permitting back-compatibility, any added features are de-facto federation breaking because of the poor user experience created when some clients do not support those features.

As I discuss at more length in the essay "Obituary, for Ray Tomlinson and Email,"[1] these factors (and some other more minor ones) tend to inherently limit the success of any federated system. Both of them were presumably major players in the decisions of Google and Facebook to drop XMPP, as both have since implemented features and monetization strategies which are impractical with an open protocol and the resulting lack of close control over client implementations.

Also, time has shown that Google is fundamentally incapable of operating a working messaging system, but that's an entirely different topic.

A further challenge faced by these and most "legacy" instant messaging services (with the exception, oddly, of IRC), is lack of sufficient support for groups. Groups turned out to be a major application of instant messaging, particularly in certain niches such as business and gaming, but also as an adjunct to the mid-2000s forum scene. While AIM, XMPP, and other legacy IM solutions did offer support for groups, it was relatively limited. A major pain point was often a lack of access control, moderation, and organization tools, which made it difficult to manage any group that exceeded a certain (fairly small) size.

Users also increasingly desired "rich" content, which could initially be as simple as inline image display but later came to incorporate link previews as a major (now essentially required) feature of IM.

Perhaps nothing has changed the IM landscape more, though, than the idea of instant messaging as platform. WhatsApp is the main example of this, although I'm not sure whether or not it's the first. Facebook Messenger was also an early example of the phenomena, by rolling out features like money transfer before it was clear that that was a reasonable thing for an IM product to do. The basic idea of IM as platform is the same idea as everything being a social media product: IM products have people, and you can make money by delivering advertising and paid services to people. So, as the operator of an IM product, you want to shoehorn as much functionality into your IM product as possible in order gain more opportunities for monetization.

I describe this in purely capitalistic terms, but consumers seem to like it as well. Consider "ChatOps," a concept which was greatly bandied about but I have never actually seen successfully employed (but of course I have not worked for GitHub where the concept originates). ChatOps is essentially the dweebiest possible version of IM as platform. Picture Jenkins shoved into your IM solution. Apparently this is the future. While you and I might think that the compulsion to operate one's DevOps toolchain from Slack indicates a severe defect in the UI and interaction design of that DevOps toolchain, the IM industry happily supported it because they were in a position to make money off of it.

These observations lead more or less directly to the messaging landscape of today, in which IM products generally fall into one of four types:

1) Legacy - IM products that are "simple IM" because they've been that way since 2005, or because technical limitations make it difficult to exceed the core IM features. Think Google Hangouts and Signal, respectively.

2) Integrated - IM products that are a secondary feature to a different social networking product. Facebook has two of these for example, Facebook Messenger and the Instagram IM feature. These almost always have ambitions to enter the third category.

3) Platform - IM products that have been expanded into a platform for apps and third-party interactions. WhatsApp is perhaps the crowning example of the genre, but Messenger is trying to get there.

4) Community-based - IM products which are group-oriented and based around a metaphor of individual communities. Think Discord and Slack (Discord for Business TM).

Of these, platform and community-based solutions are generally viewed as the cutting edge. Platform products are extremely popular among the general world of internet users, while community-based solutions are extremely popular in certain specific industries, such as gaming for Discord and workplace communications for Slack.

I view community-based IM solutions as being fundamentally user-hostile, but this is largely a matter of opinion. I just think it's ridiculous that I have nine Slack accounts in my password manager and the level of friction involved in joining (or even logging into) a new workspace is not really reduced at all. Plus the mobile app makes it a real headache to be logged into more than one workplace at a time. But that's complaining about a specific product, and I try to keep my complaining more general, believe it or not.

What is the problem, in my eyes, with this IM landscape? Well, the first and second types are hardly worth discussing, as every example of the first type is on its way out (ironically, Hangouts, the one that is officially on the way out, also seems to be the one that's immortal), and the second type are rarely worth using in their own right. The third and fourth, the instant messengers of our generation, tend to suffer from one or more of the following problems:

1) Excessively heavy - Facebook Messenger, which is relatively feature-limited on the surface, is such a mess that Facebook maintains a "lite" version of the Android app for people with older phones and/or a desire for their battery to last more than two hours.

2) Self-limiting usage scope - applications like Slack which are basically limited to certain applications by their UI design (because of a high degree of friction in switching communities). Discord tends to avoid this problem but also has a downright baffling user culture related to Discord "servers," so I'm not sure that that's more than a fluke.

3) Limited client options - available only using an official app on specific platforms, no desktop client, desktop client is barely functional compared to mobile app, etc.

So where do we go from here?

Well, one problem that we might hope to address is the fact that I have, at this moment, 11 independent messaging apps on my phone. I'm not confident that there is any solution to this under capitalism though, as addressing it would basically require developing an open standard which could be used for communication across products, and just about everyone has an explicit motive not to allow this. Another problem is the high degree of complexity in most IM products. Once again, there is a fairly direct profit motive in increasing the complexity of an IM product, so there may not be any way to solve this one.

It seems a little ridiculous to just say "there is no ethical messaging under capitalism" and leave it at that, but that's pretty much the situation we find ourselves in right now. The solution to a lot of these problems seems to be a well-designed, well-implemented federated protocol, and there are products to build that right now (e.g. Matrix), but they seem to fall to all of the basic problems that federated protocols have, such as fragmentation, design issues, feature stagnancy, etc.

I'm a little tired of just complaining about instant messaging but there is an interesting direction to go here. In a future post, I will talk a bit more about federated systems, expanding on specifically the privacy and security challenges posed by federated systems. This is a much more interesting topic as it is actively moving right now, relates to some academically difficult topics in security and privacy, and leads directly to a huge quantity of internet drama.

[1] https://jbcrawford.us/writing/obituary