A CSRF token doesn't have to be stored in memory on the server like these fnids, you only need a way to verify it like a secret for decoding it. This is a solved problem for many other servers so they could just look at some other implementation of CSRF, or start by getting rid of the many uses of fnid which are not required anyway (they are also used on GET requests).
I don't think they should try to serialise fnids, but just get rid of them completely. What state is required for a posted reply other than the three things outlined above + CSRF protection?
I think the most common technique I've seen for generating CSRF token is to compute an HMAC of the immutable request parameters.
I'm guessing that's what HN already implements for voting, as the token is dependent on user id and the id of the thing being voted on, and kind of looks like an SHA-1 hash.
I don't think they should try to serialise fnids, but just get rid of them completely. What state is required for a posted reply other than the three things outlined above + CSRF protection?