Messaging: What Will It Do?

[Part 2 of a short series on messaging systems. (Part 1)]

Having implemented messaging systems of various sizes and scopes in all sorts of environments, I’ve come up with a few guidelines for myself:

  1. If messaging is not the core service, make it an orthogonal network service.
  2. If possible make the messages ephemeral.
  3. If the messages must persist use the lightest storage solution possible and store as little as possible.
  4. Accept that huge message traffic will mean partitioning, partitions will be eventually consistent, and this is OK.
  5. You don’t need full text search.
  6. If you really do need full text search then use a DB that is built for this — its a major time-sink to hack it in later and get it right.
  7. If the messages are threaded annotations over other existing relational data, swallow your pride and consult your DBA.
  9. If anything about messages over existing data records feels hacky, awkward, or like it might put pressure on the existing DB, separate message storage and accept that some data integrity may be delayed or lost from time to time.
  10. Messaging is likely more important to your users than you (or they) think it is.
  11. The messages themselves are likely less important to your users than you (or they) think they are.
  12. If you can skip a feature, DO.
  13. YAGNI.
  14. You don’t need [AdvancedMessagingProtocol] (aka XMPP).
  15. If you *really* need XMPP it will be painfully obvious (and if you do chances are you certainly don’t need the extensions).
  16. [insert more things about avoiding feature creep]

Adding messaging to an existing system can get a little messy if you’re not really sure why you are doing it. If you know that your users really do have a need for messaging within your system, but you don’t know what features or type of messaging it should be, then think carefully about how you would want to use it as a user yourself.

Do users work together within your system to accomplish immediate goals? A concurrent multiuser system (multiplayer game, concurrent design tool, pair programming environment, etc.) benefits most from an ephemeral, instant chat system that centers around the immediate task. When the task is over the messages become meaningless and should be allowed to decay. It may be nice to give users an easy way to export or save significant messages, but that is really a client-side issue and is orthogonal to how the messaging system itself works.

Is the system used to coordinate real-world tasks or events? A real-world coordination system benefits most from a threaded comment/discussion system that centers around those tasks, and must only enhance but not replace the existing task-assignment and tracking features of the system. Threaded annotation is powerful here, but the threads need only persist as long as the task records do and messaging should never be mistaken for a task assignment tool (it can be leveraged as a part of task notification but never assignment or tracking). Remember ON DELETE CASCADE? This is where it is super helpful.

Do users self-organize into groups whose sole purpose is communication? Social group systems benefit most from mail systems implemented directly within the system they use to organize themselves. Such systems may also benefit from some form of ephemeral immediate chat, but it is critical that we keep in mind that that indicates a need for two different messaging systems, not One Message System To Rule Them All.

Many different flavors of message systems exist between the extremes of “persistent point-to-point mail” and “ephemeral, instant, channelized (group) chat”. Consider:

  • Persistent chat (Campfire, SocialObstructionist StackOverflow chat, etc.))
  • Message boards (“forums” — though this term is far broader in actual meaning…)
  • Usenet-style newsgroups
  • Mailing list systems
  • Email bridges
  • IRC + bridges + bots
  • Anything else you can imagine…

Some other things to think about are the nature of the users relationship to one another. That’s not just about communication channels and point-to-point delivery issues, it is also about what concept of identity exists within the system. Is the system one with strong authentication, total or partial anonymity, or a hybrid? This will dictate everything about your approach to permissions — from moderation, channel creation and administrative control to whether private messages are permissible and have a huge impact on what the implementation of a messaging system will require in terms of access to the original host system it is intended to support.

The issues of identity, authentication and public visibility are largely orthogonal to questions of persistence duration, storage and message-to-record relationship, but they can become intertwined issues without you realizing it whenever it comes time to design the storage schema, the serialization format(s), or the protocol(s). Of course these are three flavors of basically the same issue — though the modern trend is shy away from thinking about this either by hiding behind HTTP (like, uh, who even knows how to program sockets anymore? zomg!) and sticking your fingers in your ears when someone says that “schemaless JSON is the schema” or that XML can do the job of all three because it is the pinnacle of data representations. Consider whether this may change in the future. Keep YAGNI in mind, but when it comes to schemas, serialization and protocols it is always good to design something that can be extended without requiring core modification.

Messaging: Why Would You Do This?

[Part 1 of a short series on messaging systems. (Part 2)]

Messaging is a feature that seems to wind up on the ZOMG MUST HAVE!!1! feature list long after initial system deployment quite a bit these days. I’ve been getting asked about this a lot lately, so I’ve written down my generic advice here for reference. (If you want more specific advice feel free to contact me, though — its interesting and fun to hear about all the different things people are working on.)

I’ve been implementing and deploying messaging systems in one form or another since I first got involved with computers as a kid in the very late 80’s and early 90’s. Back then most multiplayer games were basically text message dispatch and routing systems with thematic computation surrounding those messages, so this was an area quite a few people my age dealt with — without realizing that it would one day be considered an “enterprise” feature. (And to think, we used to do this in Pascal, and assembler, and C, and hilariously inadequate variants of BASIC… as children! That nonsense was only reasonable to us because they were the only tools we had, those were labors of love, and we didn’t know any better.)

The most important thing to recognize about messaging systems is that the term “messaging” is hopelessly broad. It doesn’t really mean anything by itself. Every over-the-wire protocol is a message system definition, for example. Every drop-it-in-a-spool system is also a messaging system. Every combat notification system in a game is a messaging system. Every websocket thing you’ve ever done is a messaging system. This list could go on for quite a while, but I assume you get the idea.

Messaging systems take on different characteristics depending on their context of use. Some messaging systems are persistent, some are ephemeral, some have selective decay, some are instant, some are asynch, some are channeled, some are global, some are private, some are selective-access, some are moderated, some include extra semantic data that can be interpreted in the message body, some run everything through a central data service (“ooooh, ahhhh, ‘the cloud'”), some are peered, some are anonymous, some are verified, some broadcast, some are point to point, some are free, some are paid in per-message increments, some are paid by aggregate use, etc. The list keeps going as long as you can think of things that can be said about any system, actually.

It is important to keep in mind that most of the adjectives in the last paragraph are not mutually exclusive. Here is the fun part, though: if you need two that are, then you need two messaging systems. (That’s why they make chocolate and vanilla, after all.)

That’s a lot of different aspects to something as conceptually simple as “messaging”. The obvious problem there is that messaging is actually not simple at all in practice. When you decide that you need a “messaging solution” you really must carefully consider what that means for your users and your system. Your users’ state of mind, user experience, utility value of messaging and desire to use messaging in the context of their use of your system are all folded together.

Consider this: Email is a messaging system and we’ve all already got that, why is this not sufficient for your use? If you can’t answer that question quickly then sit back and let it stew for a bit — you will learn something about your users in the process of answering this question because it forces you to think for a moment as a user of your system instead of as a builder of it.

Let’s consider some reasons you might want to add a killer messaging feature to your existing product or system.

  • You can’t figure out the difference between “organic pageviews” and traffic resulting from the robot invasion.
  • You want more pageviews and you don’t care how you get them — messaging, you think, can be a source of bajillions of clicks!
  • Your users deal with data objects about which they constantly converse, but can’t do so within your system.
  • Your users have things to express that are best represented in a way that captures the history of their thoughts in sequence.
  • Your native applications do exactly what they should, but breaking out of it to send a message is distracting.
  • Your system already passes data among users, but requires human annotation to be fully meaningful.
  • Your system deals in machine-to-machine messages already, but users still have to call each other on the phone.
  • You are looking for a way to attach your brand to one more thing users see every day to reinforce the hypnotic effect you wish your brand had on them.
  • You require an anonymous(ish) way for users to communicate out-of-band relative to other online services.

A conditional flow would look something like this:

stupid_reasons = [pageviews,
                  BULLSHIT_WEB_IDEAS(SEO && ALL_FLAGS),
                  ADS([ad_search, ad_rank, ad_tech, ad_{*}, ...]),

if (member(your_reason, stupid_reasons)) {
    if (idea_of(You) || you_are(TheManagement)) {
        assert cancer_killing_internet = You;
    } else if (idea_of(TheManagement)) {
        abort(current_job, GRACEFULLY);
        // It won't last much longer anyway.
    contact(me, IRL);
    // I've got way better ideas.
    // You should work with me instead of sticking with losers.
} else if (knee_jerk(messaging_feature)) {
} else {

    shock(hopeless_thing, DEAD);
    anger(cant_coerce([model, users, investors, world]),
    bargain([me, you, imaginary_entities, investors, users, world, HAL],
            perceived_value(hopeless_thing, PERSPECTIVE(MYOPIC)));


Did you find yourself at congratulations(), or somewhere else? Stop and think for a while if your reason belongs in the stupid_reasons list or not. How much will it actually enhance your users’ experience with the product or interaction with each other or you? Are you going to use it yourself, or are you going to continue to use email, IRC, whatever corporate chat service is popular this week, Twitter, etc? (And if you say “Well, I/we don’t use my/our product, so I don’t know…” then you are already rather far beyond admitting defeat, you just don’t know it yet.)

Be painfully honest with yourself here because messaging is one of those things that you can’t add in and then just take away later without consequences. Even if very few people use it and it turns out to be a technical burden to you someone will wind up using it no matter how shitty it turns out to actually be, a few of these people will come to depend on it, and to these people you will be an asshole if you ever remove it. Don’t be an asshole to customers. That’s how you wind up with a “[your_product]” — and the kind of users who come to depend on weird internal messaging systems that suck are exactly the kind of people who will register a domain like that and talk shit about you. That crap will stay on the web forever and the stink may stay on your product forever, even if you change your product and they come back loving it.

So let’s assume that your system will exist in a context where it really does add value to the user’s life in some way. goto congratulations()! Messaging will be a big win if done properly and unobtrusively. As a reward for being diligent and thoughtful you now you get to wade through a swamp of design issues. But don’t worry, I’ll give you the fanboat tour and point the way through the muck.

Next we’ll look at some common features of messaging systems, what they mean for your implementation and most importantly what they mean for your users within the context of your system. [Continue to Part 2]


I just realized that it is futile to drop hints to my wife about, say, a snack before dinner. The master play is to talk about snacks with my kids before dinner, and they will always find a way to deliver the goods.


Evidence of real power: badass snacks.

Pure Declarations in Erlang

Over the last year or so I’ve gone back and forth in my mind and in discussions with other Erlangers about type systems in Erlang, or rather, I’ve been going back and forth about its lack of one and the way Dialyzer acts as our bandaid in this area. Types are useful enough that we need Dialyzer, but the pursuit of functional puritanism gets insane enough that its simply not worth it in a language intended for real-world production use, especially in the messy, massively concurrent, let-it-crash, side-effecty, message-centric world of Erlang.

But… types and pure functions are still really useful and setting a goal of making as much of a program as possible into provable, bounded, typed, pure functions tends to result in easy to understand, test and maintain code. So there is obviously some stress here.

What I would like to do is add a semantic that the compiler (or Dialyzer, but would prefer this be a compiler check, tbh) be aware of what functions are pure and which are not. The way I would do this is by using a different “arrow”, in particular the Prolog-style declaration indicator: :-

[Edit after further discussion…] What I would like to do is add a directive that Dialyzer can interpret according to a simply purity rule. Adding this to Dialyzer makes more sense than putting it in the compiler — Dialyzer is already concerned with checking; the compiler is already concerned with compiling.

The directive would be -pure(Name/Arity) (a compliment to -spec). The rule would be very simple: only guard-permissible BIFs and other pure functions are legal from within the body of a pure function. This is basically just an extension of the current guard rule (actually, I wonder why this version isn’t already the guard rule… other than the fact that unless something like this is implemented the compiler itself wouldn’t have any way of checking for purity, so currently it must blindly accept a handful of BIFs known to be pure and nothing else).

For example, here is a pure function in Erlang, but neither the compiler nor Dialyzer can currently know this:

-spec increment(integer()) -> integer().
increment(A) ->
    A + 1.

Here is the same function declared to be pure:

-spec increment(integer()) -> integer().
increment(A) ->
    A + 1.

Pretty simple change.

“ZOMG! The whold standard library!” And yes, this is true — the whole thing is out. Except that the most important bits of it (the data structures like lists, dict, maps, etc.) could be easily converted to pure functions with little more than changing -> to :- adding a single line to the definition.

Any pure function could be strongly typed and Dialyzer could adhere to strong types instead of looser “success types” in these cases. Some code that is currently written to take an input from a side-effecty function, pass it through a chain of non-returning and possible side-effecty functions as a way to process or act on the value, and ultimately then call some side-effecty final output function would instead change to a form where the side-effects are limited to a single function that does both the input and output, and all the processing in-between would be done in pure functions.

This makes code inherently more testable. In the first case any test of the code is essentially an integration test — as to really know how things will work requires knowing at least one step into side effects (and very often we litter our code with side-effects without a second thought, something prayer-style monadisms assist greatly with). In the second case, though, the majority of the program is pure and independently testable, with no passthrough chain of values that have to be checked. I would argue that in many cases such passthrough is either totally unnecessary, or when it really is beneficial passing through in functions is not as useful as passing through in processes — that is to say, that when transformational passthrough is desired it is easier to reason about an Erlang program as a series of signal transformations over a message stream than a chain of arbitrarily side-effecty function calls that collectively make a recursive tail-call (and that’s a whole different ball of wax, totally orthogonal to the issue of functional purity).

Consider what we can know about a basic receive loop:

loop(State) ->
    {process, Data} ->
        {ok, NewState} = do_process(Data, State),
    {send_state, From} ->
        From ! State,
    halt ->
    Message ->
        ok = log(unexpected, Unexpected),

-spec do_process(term(), #state{}) -> {ok, #state{}} | {error, term()}.
do_process(Data, State) :-
    % Do purely functional stuff

-spec log(category(), term()) -> ok.
log(Cat, Data) ->
    % Do side-effecty stuff

We can see exactly what cases result in another iteration and which don’t. Compare that with this:

loop(State) ->
    {process, Data}     -> do_process(Data, State);
    {send_state, Asker} -> tell(Asker, State);
    quit                -> exit(normal);
    Message             -> handle_unexpected(Message, State)

do_process(Data, State) ->
    % Do stuff.
    % Mutually recursive tail call; no return type.

tell(Asker, State) ->
    % Do stuff; another tail call...

handle_unexpected(Message, State) ->
    ok = log(unexpected, Message),
    % Do whatever else; end with tail call to loop/1...

I like the way the code lines up visually in the last version of loop/1, sure, but I can’t know nearly as much about it as a process. Both styles are common, but the former lends itself to readability and testing while the latter is a real mixed bag. Pure functions would keep us conscious of what we are doing and commit our minds in ways to the definite-return form of code where our pure functions and our side-effecty ones are clearly separated. Of course, anyone could also continue to write Erlang any old way they used to — this would just be one more tool to assist with breaking complexity down and adding some compile-time checking in large systems.

I would love to see this sort of thing happen within Erlang eventually, but I am pretty certain that its the sort of change that won’t happen if I don’t roll up my sleeves and do it myself. We’ve got bigger fish to fry, in my opinion, (and I’ve certainly got higher priorities personally right now!) but perhaps someday…

Rich Hickey: Simple Made Easy

This is an excellent presentation of the “soft tech talk” type given by Rich Hickey about the difference between a thing being “easy” in the sense that it is near to our experience and it actually being “simple” in the sense that understanding the idea does not force us to understand a lot of other ideas that are partially folded into it. His point is that we should be careful about the way we use the words “easy” and “simple” and be rather more specific than we tend to be, because this hides up a rather large and common class of complexity problems that we tend to gloss over within programmer society because we are merely familiar with a huge class of unnecessarily complicated constructs that have nothing to do with the business problems we are supposed to be solving.

Rich Hickey: Simple Made Easy

If only it were glaringly obvious to us when we were engaging in the glossing-over of non-essential complexity in architecture. I suppose one way of at least trying to become conscious of this is the frequency of use of a certain alarm-bell phrase: “just”. Ward Cunningham’s wiki actually has a whole page on it, along with another page that enumerates and discusses/argues a few other linguistic red flags of note.

Its a Small, Small World

A question on the Worldbuilding SE site about military contractors / mercenaries / “evil henchmen” / whatever caught my attention and I responded. A discussion started between myself and another guy who has contracted before in the same places, but on the tech side of the business instead of PSD. I’m preserving the conversation here because it illustrates the point I was trying to make in my answer, but doesn’t really fit within the answer and will certainly be deleted by the mods:

@zxq9 I’m impressed by your answer. I worked as a contractor as well, and ran a bar at night in one country (Middle East). Lots of the guys I worked with were former Ranger / SF. I did tech instead of PSD, but some jobs we were responsible for our own security, travel, etc. All the guys I saw ended up going back to the States (or the Philippines…) after contracts; nobody really hung out in theater after jobs. Are those little communities you’ve referred to really that common? Because I’ve yet to see people hang around after the fact.
hathead 15 mins ago

@hathead If you were ever in Baghdad you might remember that along the main E-W road between the traffic circle and Triple Canopy’s base Olympia was a mish-mashed neighborhood with a few shops and restaurants, and a couple of smaller contract company offices working out of houses. (Near the “Hot Tomato” restaurant that was always weird.) That neighborhood is exactly the sort of spot I’m talking about. Kabul has something similar. I think most of that may have been invisible to you if you didn’t work PSD or base def (and therefore have your own wheels) — but its there. Similar in Kampala.
zxq9 10 mins ago

@zxq9 – I remember the neighborhood but didn’t spend a lot of time out there. People bought alcohol there. I worked on Bes-maya, I guess you know where that is. My glory days were in Kabul, though. There we all lived on the economy and would pop into the embassy / base to do work, or speed out to Bagram. Kabul was always weird- you can get whatever you needed and half the guys at the bar were wanna-be journalists. Tourists even popped in sometimes. This neighborhood you’re talking about in Baghdad – it seemed like it was within the confines of base (checkpoint controlled). Was it not?
hathead 7 mins ago

@hathead I also forgot to mention… There are contracts in the southern Philippines, Indo, Malay, Cambodia and Thailand , too — and there are two SF association houses (the front half of which are really bars, like Garfield’s in AC and Tilac II in Pattaya). The neighborhoods near there are full of older SF guys who married locally and never left, and sometimes its easy to source logistics or meet the right folks to get a crew together locally. Pace of life is a bit slower there, but the shape of things is fairly similar — but not everyone wants to have anything to do with contracting.
zxq9 6 mins ago

@hathead The neighborhood wasn’t, but right next to it was the former finance minister’s house and apartments for his wives — which was turned into a business development center. The edge of it was right on the NW edge of the circle and had walls + a guard force from TC (which I was in charge of for 6 months once). That place gave the impression the neighborhood was controlled, but it was just that one facility. The volume of alcohol trade there always surprised me! A lot better than the “parts cleaner” thing the Poles had going on down in al Kut.
zxq9 3 mins ago   edit

@zxq9 – half the ex-Army guys I worked with had houses in the Philippines. You probably know some of the same guys. It’s not easy getting work as a tech with a PMC but I managed to find it with a big name (closed now, but you’d know them) and it was a lot of fun. Hanging out in Turkey now. It’s not hot enough yet that a worthwhile expat community has established. Yet.
hathead 2 mins ago

@zxq9 – The Europeans had fine alcohol, it was just a matter of finding it. They had a bar on Liberty that was wild. Panties stapled to the ceiling. I only saw it once; kept out of that sort of thing mostly. Did brew my own beer, though.
hathead 1 min ago

@hathead Likely do know some of the same folks. They’ll put this thread in chat or delete it pretty soon. My url is the same as my alias here: . Drop me a line. Turkey is an interesting place right now, too!
zxq9 46 secs ago

@zxq9 – I’ll drop you a line, and delete my previous chats if I’m still able.

The Yuan: Stealing from Piers to pay 保罗

So, indeed the Yuan was made into a reserve currency and the link-by-failure is already being established. It is interesting, though, that the bulk of the value transfer involved is coming from the Euro, not the Dollar or Yen. Linked by the IMF formally or not, though, if either the Euro or the Yuan fail over the mid-term the other will as well. The Chinese and Eurozone economies are intimately linked already, but were linked more by success than failure until now. That the failure of either is a very real possibility is too terrifying for the financial press to discuss, I think, and it is a political landmine public figures are trying very hard to avoid mentioning. It even seems that the made-up nature of Chinese government economic estimates isn’t even in the news much these days. You would think that little detail might enter into the discussion about adding a new currency to the IMF’s reserve currency group.

There is no longer a strong relationship among basic aspects of value assignment, legal ownership, practical control (that is, “real ownership”), vested business interest in terms of the performance value of concerns, and available goods and services in either the Eurozone or Chinese markets. While there are no recipes for economic success, there are several recipes for disaster (ask an economist about this — their responses tend to be as enlightening and humorous as they are depressing on reflection). A lack of correlation between various forms of utility values and assigned values is one of the disaster recipes. There is no easy way to fix this other than a kinetic re-establishment of property rights, and that means there is nothing left to do in the current situation than hope that when they do fail, they fail cleanly. But historically there is no such thing as a clean failure (in theory, of course, all sorts of lovely solutions exist).

Dropping an anvil on the overloaded camel’s back in the Eurozone or China would be rather easy at the moment, as both economies are in precarious situations. In fact, inducing a major market collapse would be so easy right now that failure is almost certain to come as the result of a deliberate action from an external player than by mere circumstance. The more players who realize this is true the more likely such an action becomes: why let a failure happen to you when you can be the one making it happen if the event is inevitable?

In describing the European and Chinese economic situations a financial analyst friend of mine used the phrase “poised to fail” (along with a lot of depressed-looking facepalming). When someone says that to a geopolitical analyst, though, ears perk up. There is always opportunity to be found in crisis, and sometimes when crisis is inevitable the best play is to be the cause of it yourself, because then you are the only one truly prepared. Consider the economic fallout of Russia’s invasion of Georgia in August 2008. A similar performance is absolutely not out of the question, nor is having some “terrorists” conveniently demonstrate the peaceful nature of some religion all over a ship in the Strait of Malacca at a perfectly horrible moment.

2007-2010 SPY chart

Rhetoric forces us to pretend that the August invasion of Georgia did not trigger a reassessment of risk in Eastern European carry trade loans, and instead believe that the already liquidated American subprime loans acted as a magical “contagion” that unfairly crushed the Eurozone. As if the European economies were not profoundly overleveraged and primed to implode.

There really isn’t anything to do about what is going on with the Yuan, really. This course was set about 20 years ago (yes, all the way back in 1995 — after the Cold War, after the first post-Tienanmen Square Five Year Plan was in action; as China started on its “Money is Good” -> “Expansion Above All” -> “Don’t Stop the Train” -> “WTO Rules? Screw the rules, I have money!” chain of policies). The general trend will continue, as none of the players seems to have any inkling of how to change the rules of the game — and the trend is of the end of a decades-long political and financial cycle. The way these stories end is never happy.

1984-2015 Money Base chart

Anyone who thinks that events since 2008 have been business as usual and that geopolitics plays no part in this because “its just a market hiccup” is deluded.


Every end is a new beginning, and that’s what is really worth focusing on. That may sound like small comfort (and it is), but if you already know things are going to get worse before they get better, then at least you won’t find yourself sleeping in a bed of broken dreams. It is too soon to tell which way this Jenga tower is going to topple, but we are nearing the end of this round of the game.

China: Yuan Will Be a Reserve Currency, Come What May

EDIT: Indeed, it has been made a reserve currency, or at least it looks like announcements have already been made to pave the way.

The IMF is considering adding the Yuan to the group of reserve currencies. That would put it alongside the U.S. Dollar, the Japanese Yen, the English Pound, and the Euro in terms of “officially perceived” stash-your-value-here viability. As far as actual criteria for inclusion go, the Canadian Dollar, Australian Dollar, and very likely the Russian Ruble are probably actually closer to being genuine reserve currency material than the Chinese Yuan.

But… politics.

China is much closer to a total financial collapse and internal civil disruption* than recovery and stability in its current form. Long-term, of course, China will still be right where it is and the people there will still be Chinese (but there will eventually be far fewer of them, at least for a few generations). A Chinese collapse right now would be a major disaster for everyone. The commodity markets are depressed more than they have been for several decades (in relative terms, actually, I’m not sure that we actually have a post-WWII precedent for what is happening), energy is cheap, credit is massively overleveraged, and yet people aren’t buying enough stuff to keep the wheels spinning.

What does that have to do with the Yuan becoming a reserve currency? It does three things:

  • Gives China access to an external aggregate value device to prop up the yuan if necessary (links their economy to everyone else’s by failure, similar to the way subsidies can do this within a national economy). This effect is actually more a hoped-for psychological effect on the market than a tangible superpower China is being granted by the rays of a yellow sun.
  • Makes the Yuan a necessary holding for anyone trying to carry a balanced basket of reserve currencies (temporarily spikes demand for the Yuan).
  • Promotes an impression of stability in the Yuan (well-founded or not).

Why would the West agree to this? (And I say “the West” because, let’s face it, Washington and London are pretty much the ones who will be deciding.) Because if China were to fail right now it would be a severe annoyance for the U.S. and a complete disaster for Europe and Russia. Nobody really knows what the fallout of that would be, but it wouldn’t be pretty.

The Yuan will be made a reserve currency, whether it makes sense or not, and whether it actually fits in the reserve currency club by the standards and rules the IMF itself has laid out. These are scary times and nobody has any good levers to pull to “fix the economy” so national governments and central banks are pulling at straws because there is simply nothing left to try. All the control rods have been yanked out and tossed already, or shoved in and locked tightly; all the red buttons have been mashed; all the hyperbolic rhetorical devices have been so over-used at this point that the only thing that might actually influence market participants is a frank exposition about the truth rather than more “we’ll do whatever it takes!” and other gung-ho, “it’ll work this time” and “this is the lastest of the last rounds of QE, and this time it will really be the most effectivest of effective measures… I promise!” blather.

[* China is due for two painful corrections which will likely occur together, as they are linked. The first is a political correction; China’s geography does not lend itself to a central command economy. The second is a property-claims correction; when basic goods cannot be had at any price it means the entire system is so out of whack due to government interventions that only a hard reset can fix things. This will likely take the form of a civil war, but who knows. It could be gradual decline toward state failure followed by a logical and non-violent nation-wide roundtable discussion, or even a bloodless revolution coupled with a voluntary capitulation of material holdings by the power elites. But seriously, this has never happened in history and there is no reason to expect China’s inevitable transitions to occur independently of one another, or for either to be non-violent.]