BlinkLink Post-Mortem

Last week, I released this thing called BlinkLink. It's mostly a social experiment to see how (well, if) people would use disappearing content on the web. The obvious inspiration is Snapchat, with a twist: you can choose to make your content "un-disappear" if someone tweets it.

A dorky selfie made it to Hacker News. I set what I thought was an incredibly high maximum view count of 10,000, but it only took about 30 minutes to disappear (the first time).

I'm pretty sure it struck a chord, and I thought it'd be neat to share a little more data about what happened.

Stats

On the first day, BlinkLink managed to get about 50k pageviews against 17k visitors. It peaked around #3 on Hacker News, and stayed in the top 10 for most of the day (Saturday). Traffic has halved pretty much every day since, which isn't unexpected:

Maybe more interesting, there have been 725 blinks created this week. I'd rather not poke around and see what kind of content was created, but in Google Analytics I can see there are non-negligible amounts of pageviews for many. So people have been creating blinks, and are sharing them.

Technical Problems

View Counting

Almost immediately, one intrepid HN member decided to slam my blink with requests. I started with a very naive method of counting views, and that comment (plus monitoring similar request patterns) made me clean it up after the first hour.

There are two popular throttling libraries for Rack-based apps: Rack::Attack and Rack::Throttle. I tried Rack::Throttle at first, since it had a nice one-liner to get everything working and I had to act fast. I eventually switched to Rack::Attack because it has a much cleaner API for creating granular throttle behaviors. It's probably a no-brainer to include one of these any Rack or Rails apps, since the setup is so painless.

Twitter

To avoid spoofing, verifying that a user tweeted a blink requires you to query the timeline of that user. You could either get the user to OAuth their account or, as BlinkLink does, simply ask for their public Twitter handle. It would be good to A/B test the two options, but my gut told me to go with the least intrusive.

For some reason, connections to the Twitter API would timeout or drop at random. Increasing the Twitter library's maximum timeout seemed to help, but it was one of those things I could never reproduce locally or on the server console.

There were also some savvy users who tried to automate the Twitter verification steps. I stopped these at first with IP banning, and switched to Rack::Attack for throttling per-Twitter-ID. I wonder if Twitter began to throttle my connections because these malicious verification requests also came at a high rate.

Observations

The barrier for a user tweeting something appears to be very high: I had to gradually increase the tweet "bonus" for my HN blink to +1000 views before any tweets appeared. I think there's a very interesting risk/reward dynamic going on, which could be explored more.

People are curious about disappearing content: dozens (including Mitch Kapor!) shared a totally innocuous photo of me making a O_< face, just to show off BlinkLink.

There might be a market. I've gotten inbounds from folks wanting to use BlinkLink as a sort of "share wall", where a deal disappears after a certain number of views... unless it's shared again. Maybe that's up Snapchat's alley, too.

Future

People are still sharing blinks on Twitter, and it's cheap to run, so I don't see a reason to shut it down. It's definitely not my priority, but it's a fun experiment and I'm curious to see where it'll go.