cohost dot org


the website you're on right now

brought to you by @vogon @jkap @aidan


@staff is on the clock from 9am EST to 5pm PST every weekday.

Be sure to check out the status of known bugs, feature requests, and other site improvements in the notion link above.

find our FAQ and support documents at

To contact us directly, email [email protected]

thank you for using cohost!

nobody contributing to our upstream dependency responded within two weeks, and in the sake of getting it off our plates as quickly as possible without having to reverse-engineer someone else's Markdown parser, we've decided to disable Github Flavored Markdown processing in profiles and posts containing more than 256 lines separated by only a single newline. if you post an extremely long single-spaced paragraph, the following Markdown features will stop working in your post:

  • automatically converting URLs and e-mail addresses to links;
  • footnotes;
  • struck-through text;
  • tables;
  • and task lists.

we'll let you know if and when this changes.


Q: why is this bug happening?
A: hell if we know. our underlying GFM table parser -- a piece of software with more than 600,000 weekly downloads on npm, so we shouldn't be the only ones hitting this issue -- seems to churn through a bunch of memory allocations if it sees a long sequence of lines which could possibly be a table.

Q: why 256?
A: it's a round number. also, the performance characteristics start getting bad around there, and are too bad for us to tolerate well before 512.

Q: "Github Flavored Markdown"?
A: yeah. Markdown was originally invented by Aaron Swartz (yes, that Aaron Swartz) and John Gruber (an influential Apple and user experience blogger) in the early 2000s as a markup language for rich text, and one of its greatest sins is that for almost a decade the best available specification was just a page on Gruber's blog. so, as it took off across the web, a bunch of different companies introduced incompatible dialects of it with different subsets of added functionality. Github's dialect was, inexplicably, one of the big ones that stuck, and provides some features that never officially got standardized.

Q: task lists?
A: yeah, we weren't sure if those worked on here either, but turns out they do.

in reply to @staff's post:

You should, genuinely, flag and escalate this as a security issue. A parser exploit that can cause superlinear memory allocations is a DOS risk of the sort that's constantly being flagged as security advisories (most of the stuff you'll see in npm's "your dependencies have X critical vulnerabilities" are this kind of thing), and that's much likely to get it fixed faster.

unfortunately there doesn't seem to be any formal escalation process on the upstream repo, and the entirety of their "security" section in the is

This package is safe.

which doesn't give us a lot to go on. the bug's title contains "severe performance issues" and contains an aggressively minimized repro case, so if any maintainer is paying any kind of attention to it they should've noticed it sometime in the last two weeks.

huh. I dunno if John Gruber really considers Aaron a co-creator of Markdown, though he definitely has mentioned that Aaron was the only beta tester and contributed "ideas, feedback, and testing" that improved it significantly. am I wandering ass-backwards into some weird internet dispute? Did Aaron consider himself a co-creator?

please everyone feel free not to respond, I'm not trying to attack, just curious, so if this bothers you, forget I said anything lol, I'm not going to go create drama I promise

yeah, idk the specifics, I'm just cribbing wikipedia -- this is the first I knew of aaron's involvement, though wikipedia does imply that the design of markdown was influenced by atx, a similar markup language he'd written a couple years earlier

Yeah, I just happened to be listening to Gruber’s Dithering podcast this last week, making my way through the backlog, and he talked about the origin of Markdown a bit on episode five, said he started off by trying to make a bunch of suggestions to the guy running Textile, which is mentioned on the Wikipedia article as well, but that guy was like “you’ve got some good ideas but they aren’t Textile, but seriously go do your own thing” so he did. And he kinda cut it off there, but he did imply that the original perl implementation was entirely written by him, and didn’t end up mentioning Aaron at all. He’s clearly grateful to Aaron for going above and beyond in providing feedback and ideas, but it seems, and he may have a point here, that he thinks the fact that he curated what actually went into the spec, keeping it tight and clean, made it uniquely his project.

Anyway, who cares, toss some extra credit to the dead guy, he won’t use it lol