Happy Valentine’s Day! If you’re looking for a last-minute card, check out Toni J’s Love Bug Valentines.

I post at least one blog per week at Apidae.com. Here are the latest:

Check back each Tuesday for new posts.

I’m going to start testing out live video streaming of open source projects. I’ve been a viewer on Twitch.tv for a while and have recently started checking out LiveCoding.tv.

To make it easy to find my stream, I figured I’d embed it directly on my WordPress blog.  While there are a few plugins that purport to do that through WordPress widgets or shortcodes, they each have a major limitation: they always showed up.  In my case, I only want the stream to show when I’m broadcasting, not waste time with a black box in the middle of the page.

I decided to dust off my PHP skills (which I haven’t touched in many years) and write my own plugin.  Thankfully, Twitch provides an intuitive, anonymous API and WordPress plugins are incredibly straightforward.

Figuring out when the broadcast is active

In order to figure out whether a Twitch channel is actively broadcasting, we can query the REST endpoint at https://api.twitch.tv/kraken/streams/{$channel} (in my case https://api.twitch.tv/kraken/streams/bertjohnsondotcom).

If “stream” is “null”, the channel is offline.  Otherwise, it has a JSON object describing the stream.

My plugin simply checks that value and if it’s online, shows the Twitch IFRAME.

Supporting HTTPS

The normal way to embed a stream is by creating an IFRAME with a source of http://www.twitch.tv/{$channel}/embed (http://www.twitch.tv/bertjohnsondotcom/embed in my case).  You’ll notice that’s over HTTP, but I use CloudFlare for SSL offloading to ensure all connections are performed over HTTPS.

By default, Twitch doesn’t support HTTPS streaming yet.  It’s been on the roadmap for a while, but any attempts to visit https://secure.twitch.tv are redirected back to the HTTP version.  When embedding the HTTP version of Twitch, you won’t see the content or even a warning on the HTTPS site in most browsers.  Instead, it will silently fail.

To work around that, I found an HTTPS Flash endpoint available on Justin.tv’s CDN (which was the precursor to Twitch.tv).  There’s a definite tradeoff, as requiring Flash means this won’t work on many browsers (including the vast majority of mobile platforms), but I consider that better than allowing non-encrypted traffic.

That Flash endpoint is available at https://www-cdn.jtvnw.net/swflibs/TwitchPlayer.rfc07d37fc4eed1d17243b452dd3441665496e1e0.swf?channel={$channel} (https://www-cdn.jtvnw.net/swflibs/TwitchPlayer.rfc07d37fc4eed1d17243b452dd3441665496e1e0.swf?channel=bertjohnsondotcom in my case).

Hopefully this is a temporary workaround and Twitch will support HTTPS everywhere soon.

Getting the plugin: WP Twitch

You can find source code for the WP Twitch plugin on GitHub at https://github.com/bertjohnson/WP-Twitch.  You can download the ZIP archive from https://github.com/bertjohnson/WP-Twitch/releases/download/1.0/wp-twitch.zip.

I’ve also submitted it to the WordPress plugin directory.  Since this is my first submission, it might take some time for review before it’s widely available.

It’s incredibly simplistic, but should meet most needs.  I’ve embedded it into my theme via shortcodes, but it works just as well as a widget.  Suggestions welcome.

The end result

Here’s a sample from my wife’s site, ToniJ.com:

WP-Twitch

When I first created OpaqueMail, I faced the difficult choice between S/MIME and PGP as the standard for encryption.

The advantages for S/MIME were:

  1. A lower barrier of entry due to supporting libraries pre-installed with Windows.
  2. Greater familiarity and ease of use for developers used to public key infrastructure.
  3. Lower complexity of managing, securing, and choosing keys.

S/MIME adoption has grown, partly thanks to the usability of OpaqueMail, but it remains prohibitively complex for many scenarios.

Email is being increasingly secured through PGP. I don’t have reliable data, but PGP seems to enjoy wider adoption and awareness from the general public. I’ve wanted to support both for a while now, but needed a good reason to embark on the PGP path.

A tipping point for me this month has been Facebook’s new support for publishing PGP keys.  Finally, there is a public, (largely) trusted database where users can share keys. Instead of the traditional “web of trust”, I expect key databases (like keybase.io) to foster increased adoption.

With that background, I’ve started adding PGP support to OpaqueMail, now available to test in the 2.2.0 release. For the first time, OpaqueMail now has a dependency on another open source library: BouncyCastle. PGP is far too complex to implement from scratch and thankfully BouncyCastle provides secure, high-performance, and complete libraries for cryptography. The Legion of the Bouncy Castle dates back to the 1990s and their code has been scrutinized by tens of thousands of developers.

OpaqueMail 2.2.0 features PGP decryption and signature verification only. Encryption and signature creation is planned for a future release.

Beyond that, I may start another project to streamline public key discovery from Facebook and other federated sources.

Now that your WordPress Multisite install is up and running in Azure using Project Nami, it’s time to set up daily backups.

WordPress Files

For your files (code, uploads, and other multimedia), it’s easy. Under your Web App settings, choose “Backup” and create a schedule. In my case, I went with daily backups (retained for 30 days), backed up in the same resource group in the same region. With about 1 GB of files, backups complete in under 10 minutes.

WordPress Database

Now what about the database? Normally, I’d just set up a linked resource so the database would get backed up along with the website. Unfortunately, that doesn’t seem to be working in my subscription (and there are more than a dozen threads complaining about the same issue on TechNet).  When I select a database to be backed up with my WordPress site, it fails instantly with a vague error in the operations log, leaving me with a 0 MB backup.

As a backup, I figured I’d just set up a scheduled database backup that would be saved on the filesystem, which would be part of the files backup. Well, it turns out that most of the mature WordPress backup plugins (e.g., WP-DB-Backup, BackWPup, BackUpWordPress) don’t support multi-sites and/or don’t support Project Nami. So that option’s out.

Fortunately, Azure databases on the basic, standard, or premium tiers are automatically backed up hourly and provide 7, 14, or 35 days of retention. Using an S1 instance, I’m more than comfortable with a 14 day database backup window.