So if I'm reading this right, the update would be written without media embeds to C* then the media processing would happen then it would write again.  This would all be in the `POST_update` request the reporter makes.

There're a few issues here:
* Scraping for embeds, especially multiple of them, takes a while.  Frequently on the order of seconds.  It's almost always a bad idea to block request processing on something external like that.
* If you load the page while the media embeds are scraping, you'll get the update without its media embeds. Refreshing after the media embeds scraped would give you a different view.

Scraping is done by the main site on an asynchronous queue: `scraper_q`.  Here's how I'd sorta envisioned this process working, though I'm not at all happy with the reporter UX:

1. reporter posts an update
2. if update contains scrapable links, put it on a background queue. otherwise update stream and broadcast immediately from request like current system does.
3. background queue scrapes the embeds for the update and when it's done it inserts the update into the event stream and broadcasts on socket.

The post-an-update request would return the ID of the update-to-be so that the reporter UI can disable the form and put some sort of "processing" indicator up until the message is received on the socket.

How does that sound?