Awazon Shapes

Family

Files and text

Awazon market links

Supplied by the site owner and printed unchanged, with nothing added and nothing ranked. This reference contacts none of them, so it reports no availability of any kind.

Seven shapes that are all descriptions of something else, and seven ways a description can be perfectly formed while the thing it describes is not what it says. Start with the thesis if you have not read it.

The other families on this site document strings that are the thing. An onion address is the address. A seed phrase is the wallet. Lose a character and you have lost the object itself.

This family is different. Nothing here is the thing. A hash is a short label computed from a file, printed beside the file, and carried around separately from it. A filename is a label written into a directory entry. A line in an archive listing is a rendering of a header field. A quoted block is text somebody typed to stand in for text somebody else typed. Each one is a description, and a description travels apart from the thing it describes.

That separation is what binds the seven cards together. It is also where the reasoning goes wrong most often, because a description that is correctly formed feels like it has been checked. It has not. It has only been written.

A description can be right and still be about something else

Take the plainest case. A file arrives with a hash printed beside it. The hash is sixty four hex characters, all lower case, no spaces. The shape is exactly right. What has that established? That somebody typed sixty four hex characters. The label and the file were carried to you by the same route, and if that route rewrote one of them it could rewrite both.

The same reasoning holds for every card in this family. A filename ending in a familiar extension is a name somebody chose, and choosing it cost nothing. An archive listing is generated from fields inside the archive, and those fields were set when it was built. A metadata line under an image is printed from headers in the image file. A quoted message block is entirely the work of the person quoting.

None of that means any particular description is false. It means the shape check answers a narrower question than it appears to answer. The question it answers is: could this string be the kind of thing it is presented as. The question it does not answer is: is it about the object in front of me.

There is a second reason these seven belong together. Each of them is a place where a display gets between you and the data. A listing hides suffixes it recognises. A viewer rounds a byte count and prints a unit. A message client rewraps quoted lines to a width it prefers. A form field joins lines because it can only hold one. In every case the rendering is lossy in a way that leaves no mark, and reading carefully means knowing which losses your own screen is capable of introducing before you attribute anything to the file.

The seven shapes

Two habits worth carrying between the cards

The first habit is to name the object before you check the shape. Hex strings in particular are ambiguous by construction: sixty four hex characters could be a digest, an identifier, a hex encoded blob, or a fragment of something longer. The shape rules for all of those are identical. Deciding what you are holding is a separate act from checking that it is well formed, and it comes first.

The second habit is to ask which side of the description you are on. A hash printed on the same page as its download link, an archive listing rendered by whoever supplied the archive, an image metadata line drawn from the image itself: in each case the description and the described came from one source. Agreement between them is agreement of a source with itself. That is worth exactly what it sounds like.

Both habits are cheap. Neither requires software, and neither produces a verdict. They narrow what a check can be claimed to have shown, which on this site is the only kind of progress on offer.

Every page on this reference