moot

More details here: http://blog.4chan.org/post/81896300203/webm-support-on-4chan

> I feel 4chan has become the 'porn' industry of the internet.

This is the most flattering thing I've ever read about 4chan.

Quality contribution(s) in an anonymous community? Who'd a thunk!

> There's a _huge_ discrepancy between people's interpretation of what 4chan is like, and what it really is.

> /b/ seems to be a "honey pot" for the more negative behaviors on 4chan.

Double bingo!

This is the best day of my life.

I did in fact only just sit down after leaving that comment ~12 hours ago. Hope to have something up by tomorrow or Wednesday.

Also wrong.

This is completely and utterly wrong, and only furthers my belief that nobody in Silicon Valley actually "gets" anonymity.

I'll try to write a real response tonight on my blog (http://chrishateswriting.com)

My excitement is that Mark, who has been extremely staunch in his belief in "Facebook identity" (First Name/Last Name/Profile Pic, Online == Offline), is starting to consider alternatives to that. It remains to be seen what that will ultimately amount to for Facebook's product/app offerings, but it's a huge shift in his personal beliefs.

I wrote up some thoughts on Snapchat's mainstreaming of anonymity/ephemerality a few months ago -- and believe there are huge opportunities out there for people who will go where Facebook/Google won't: http://chrishateswriting.com/post/67378144174/ephemerality-g...

Circles was neat, but it solved the wrong problem. I gave a talk about it a few years ago: http://youtu.be/e3Zs74IH0mc

As I said, we're considering our options going forward, but for all intents and purposes, the venture-backed startup that was Canvas Networks has failed.

Much, much less :)

This is right. It was clear we weren't going to be able to raise another round of financing, and even if we could, it was unclear how that would enable us to change the state of the things, namely that our business didn't represent a startup opportunity. Frankly if someone had offered me a term sheet, I wouldn't have accepted it.

We didn't really have many options. We tried to build a business and failed. We could have tried to raise a bridge financing -- but what are we bridging to in that case? A financing (no), an exit (also not an option, as we found)?

Ultimately spinning things down into a skeleton state and doing our best to operate the service for the coming months (heck, maybe years) was the only path forward.

Re: the OP, I think 400k MAUs is actually pretty decent for a mobile app, but maybe I'm mistaken.

This is mostly right. DrawQuest would make a fine lifestyle business for a few partners, but is unlikely to become a business that represents a venture-backed opportunity. However because we built it as a venture-backed business, that's the bar we're held to.

Per my post, I'm exploring options for keeping the service alive for the next few months (and hopefully longer), and am cautiously optimistic we'll be able to figure something out.

Another example from 4chan: http://chrishateswriting.com/post/68794699432/small-things-a...

This reminds me that the domain wildcarding we do for thumbnails probably isn't necessary anymore thanks both to SPDY but mainly how many parallel connections browsers open these days...

We only do this on the imageboards though -- not the front page.

Wasn't aware of this (but was hoping it was in the works) -- thanks a bunch!

We get surprisingly little mobile web traffic -- only 16% in November.

BRB, switching everything now!

Yes, but every time I've investigated it, the tl;dr was "not worth it" given our requirements/constraints.

Google Analytics has its shortcomings, but it's a great product and free.

I wouldn't agree. There are completely legitimate reasons to set cookies on *.domain.com -- it isn't "clueless/stupid" to do so, just less ideal.

Actually 78.75% of our users are on Chrome/Firefox!

SSL is forced on our domain you post to (sys.4chan.org) with redirects and HSTS, and we set cookies with proper Secure and HTTP-Only flags. Maybe some day we'll force SSL site-wide, but I don't think that's the right decision for now.

I definitely encourage people use the EFF's wonderful HTTPS Everywhere extension though: https://www.eff.org/https-everywhere

That's another thing YSlow and PageSpeed have complained about for ages, but hopefully the local resolver cache mitigates it somewhat.

Well it's a single kilobyte, but 100 KB in aggregate.

It's almost entirely Google Analytics, unfortunately. Our ads are served from a different domain (4chan-ads.org) for specifically this reason (user privacy and cookie bloat).

We've had a surprising amount of difficulty maintaining this over the years, since FreeBSD's NFSv4 implementation kind of sucked for a while, and it doesn't support mounting a memory partition (tmpfs). But you can trick it by mounting the memory partition using nullfs, and then nfsmount-ing that.

We used that memory-partition-over-network thing for a while, but actually switched to SSD-over-network because it was faster than the memory partition. I spoke with a FreeBSD maintainer about it and he said what we were doing was so unsupported/unoptimized that he wasn't surprised.

We run into weird FreeBSD edge cases pretty often where there are few people, if anyone, who can answer our questions. Sometimes I wish we'd gone with Linux, but after ten years the hassle of switching doesn't seem worth it. Thankfully 9.2-RELEASE has been pretty good to us.

Thanks for pointing that out. We minify production JS using Closure Compiler but sometimes that leaves room for improvement.

There's definitely a tradeoff between inlining JS and small images, but I think in our case it makes more sense to leave them external to leverage browser (and since we use a CDN for static content -- edge) caching.

I believe I tried to get ngx_pagespeed up and running when it was announced, but couldn't get it to compile from source. Sometimes (read: often) it sucks to be a FreeBSD user.

We actually do this with reply loading already, but not by default. We have a read-only JSON API and use that to append new replies when you're browsing in a thread (click [Update] or [x Auto] at the top/bottom of a thread). We also have a de-pagination feature that grabs all of the OPs from a board and let's you scroll through the indexes as one giant page.

I've been meaning to write a post about all of the weird stuff we do in the interest of maximizing our limited resources. We've always had to stretch things as far as possible given server, financial, and time constraints, which has led to some interesting/unorthodox "solutions."

Correct, but only if you don't set any *.domain.com cookies, which as it turns out most do.

We write pages to disk as compressed HTML, and make use of nginx's gzip_static and gunzip modules to serve them. So every time a person posts, we regenerate the applicable reply and index HTML. The high postrate boards are rebuilt with a daemon on a timer, since past a certain point (~1 post per second) it's wasteful to regenerate on demand given how long the script takes to run.

We essentially think of flat files on disk as a cache for the database, and don't employ a proxy cache or any other common HTTP proxies. It's a little unorthodox, but it works well for us.