Here's a weird markdown rendering bug for someone familiar with those bits... Note the formatting of the first word in each bullet point, each of which has identical style markup: ------ - **`uuid`**: the hash code of the blob's contents. - **`rid`**: a unique integer key for this record. This is how the blob table is mapped to other (transient) tables, but the RIDs are specific to one given copy of a repository and must not be used for cross-repository referencing. The RID is a private/internal value of no use to a user unless they're building SQL queries for use with the fossil db schema. - **`size`**: the size, in bytes, of the blob's contents, or -1 for "phantom" blobs (those which fossil knows should exist because it's seen them referenced somewhere, but for which it has not been given any content). - **`content`**: the blob's raw content bytes, with the caveat that fossil is free to store it in an "alternate representation." Specifically, the `content` field often holds a zlib-compressed delta from a previous version of the blob's content (a separate entry in the `blob` table), and an auxiliary table named `delta` maps such blobs to their previous versions, such that fossil can reconstruct the real content from them by applying the delta to its previous version (and such deltas may be chained). Thus extraction of the content from this field cannot be performed via vanilla SQL, and requires a fossil-specific function which knows how to convert any internal representations of the content to its original form. ------ Specifically: the 4th bullet point's **bold** markers are not consumed as markup, and are instead left in place. The trigger for this appears to be the subsequent backticked words in the 4th list point. If those backticks are removed, it renders as expected. Similarly, adding backticks to words in the other list entries causes them to mis-render in the same way.