Spoilers in the age of Social Media and Ubiquitous Time Shifting

You know what really grinds my gears? Folks who complain about TV spoilers in social media. Quite often I will tweet something about an episode of The Walking Dead or Game of Thrones several hours, or even days after the original air date of the episode, and there is always someone who gives me shit about it because they haven’t watched it yet. We live in an age where DVR’s are more or less ubiquitous and most people “tape” their favorite shows and watch them later. Granted, DVR is far inferior to actual tape (as in VCR tape) in when it comes to actual portability and usability of the time shifted material. Of course this is mostly a concern only in principle since bit torrent sites provide even better time and format shifting services to the masses for free. Needless to say, there are many ways to watch your favorite show on your own schedule whether you own a DVR or not.

The problem with this is that TV watching has always been a social experience. With the mainstreaming of social media, many viewers such as me want to engage with friends and community at large via those channels and discuss the on-screen events as they unfold. Many TV networks such as AMC have noticed this trend and actually encourage it by posting Twitter hash tag suggestions during commercial breaks. It is actually a lot of fun to live tweet your favorite show, and bounce around jokes and/or speculations with other fans. But there is always someone in your social circle who is not watching the show right now and wont be able to watch the show for days and thus becomes very upset at all the spoilers in their feed.

You would think that if you happen to be a fan of some show, and friends with many other fans via social media would know better than to wade into the update stream as a new episode is on the air and expect not to be spoiled. But lets say that live tweeting is just a tad bit inconsiderate. Perhaps we ought to leave a small courtesy window between the original air date, and actual posting of the plot revealing spoilers? What should that window be though? Is the morning after an acceptable compromise? Two days later? Next weekend? A month?

The truth is that spoiler-complainers don’t actually want a compromise. They want their social media to be pristine clean and devoid of spoilers forever. They want to watch their shows on their own schedule (as is their right) and want everyone to hold off any and all discussion of said shows until that an undetermined and arbitrary date when they choose to watch them (which I would say is inconsiderate on their part). In fact, if you happen to be followed by a lot of people, almost invariably you will piss off someone who doesn’t even get the show you are discussing in their region. Yes, I have actually been yelled at by someone who never seen Game of Thrones but was considering “maybe downloading it one day”.

So realistically, the only way to avoid the ire of the spoiler-complainers is to keep your mouth shut, and never mention any of the series you like in your social media feeds, ever.

I got fed up by this and decided to do something about it. The simplest and most direct solution to this problem would of course be to gather all these whining spoiler haters, put them in a rocket and launch it into the center of the sun. But since I don’t have a rocket, I decided to code up a solution instead. Something that would allow me to post spoilers in my tweets without pissing anyone off in the process.

The big thing about posting plot twists and revelations in Tweets is that there is really no way to hide or filter them. Forums and blogs have a long standing tradition of using vertical white space (often known as “spoiler space”) to set the spoilers apart from regular post, or change the font color to obscure the text. Twitter’s limited nature does not allow you to do any of that. There is really no way to hide part of your tweet in any meaningful way… Except of the Twitter Cards functionality.

When you tweet a link to a site which implements Twitter Cards, the users can click on it and it expands to reveal an excerpt and a picture from said link. I figured I could exploit this functionality as a crude way to hide spoilers. So the idea was to design a service that would allow one to create a spoiler text, bind it to a unique URL and then automatically tweet that URL along with a non-spoiler teaser message. Let me show you an example – I could tweet something like this:

Spoiler Tweet

The link in the post would then link to a web page like this:

Spoiler

Note that I’m not showing Game of Thrones spoiler as an example for reasons that should probably be obvious by now. The Twitter Cards integration doesn’t work as of yet, because apparently it takes months for that functionality to get approved. The service however does integrate with Twitter so you don’t actually need to sign up for an account to start posting spoilers. You simply sign in with Twitter and you are ready to go.

I’m actually pretty happy with the URL I was able to nab for this service: dontspoil.us. What I really wish I was able to get was spoil.er but unfortunately the .er TLD is not open to the public yet.

This is how it looks

As with most of my projects, this one is Open Source. You can peruse the code at your convenience over at GitHub.

The front end is my usual: clean HTML5 with a little bit of Twitter Boostrap which in this case I’m using primarily for the responsive grid and pretty buttons. I’m also using jQuery which drives some of the Bootstrap effects, and also lets me do very simple validation on user input.

The back end was written entirely in Ruby, using the excellently simple Sinatra as the web framework and Data Mapper as the ORM. I resisted the urge to host it on my old and busted Dreamhost account like I did with MarkdownJournal.com. As you probably seen that host has major stability problems, so I instead opted for something different: Heroku cloud hosting platform.

If you are not familiar with Heroku, it is basically Google App-Engine style service but with slightly different focus and a lot more flexibility. Whereas Google sort of binds you to its own proprietary API and it’s own proprietary NoSQL data storage, Heroku gives you a wide array of options. For example, in this project I’m using PostgreSQL database hosted and maintained entirely on the service, and running in fully distributed mode.

Heroku’s main strength as a hosting platform is the promise of almost infinite scalability, but that’s not really why I set my service up there. I don’t imagine it becoming popular enough to warrant more than a single Heroku dyno and a dev-mode database plan. I mostly made it to solve my own problem and picked the platform because I wanted to learn more about it. I created my Heroku account couple of years ago, when the service was still young but never really did anything with it until now.

I must say it is interesting environment. Working with it is a little weird at first because it doesn’t always behave as you would expect a regular platform to behave. Because if it’s decentralized nature and its limitations there are little quirks you need to keep in mind – like the differences between the way your app runs locally when you test it, and the way it works when deployed to the Heroku cloud.

I fully expected it to be the most annoying part of the project, but it wasn’t. That distinction goes to Twitter. When I was writing the application I kept running into Twitter API rate limits. I didn’t know this when I set out to create this service but each Twitter app is limited to 15 API requests per minute for each unique Twitter user. This of course includes authentication and any look-ups you may want to do.

For example, in the early version of the app I would authenticate the user using the Twitter OAUth, then look up some information about the account that just signed in such as Twitter username, display name and the profile picture URL. This actually counted as five requests, so I could only refresh the page 3 times per minute. If I accidentally made one request too many, I would get locked out for 15 minutes during which all my requests would be rejected. I quickly learned to cache everything and use as few requests as possible but it was extremely annoying at first.

Anyway, the service is now up and running. The Twitter Cards integration isn’t there yet so for now you have to click on the link to see the spoilers. Eventually I’m hoping you will just be able to expand them. This will have double benefit – it will make it easier for users to consume the spoilers, and it will lessen the traffic on my end allowing me to keep the service on a cheep (and preferably free) Heroku plan.

As usual, comments and suggestions are appreciated. If you manage to break the service, please submit a bug report and I’ll get right on fixing it. Or, if you can code in Ruby feel free to fix the bug yourself and just issue a pull request for faster turnaround time.