# Refused is a different word from failed

> A terminal error reads ERR 0x1F4, HANDSHAKE REFUSED, then a blinking cursor on an empty line. The cursor is the part actually communicating anything.

August 19, 2026 · https://justog.club/stories/handshake-failure-code

A terminal error, filling the print top to bottom in one amber ink. `ERR 0x1F4`, larger than
anything else on the shirt.

`HANDSHAKE REFUSED` sits beneath it, same fixed-width face, smaller.

Below that: an empty line, and a single cursor block, caught mid-blink.

Refused is a different word from failed. Failed is nobody's decision. Refused means something on
the other end looked at the request and said no.

## What is a handshake failure code?

The moment two systems try to open a connection and one of them declines, printed exactly the way
it would appear on the screen it happened on.

A handshake is the exchange that has to succeed before any actual data moves — a system saying who
it is, and the other system deciding whether to let it in. `REFUSED` is the specific outcome where
that decision was made and it was no. Nothing crashed. Nothing timed out waiting for an answer.
An answer arrived, and the answer was a closed door.

## Why does REFUSED mean something different from a timeout or a crash?

Because a timeout is silence and a crash is an accident, while a refusal is the one outcome that
proves somebody was listening.

A connection that times out could mean the other system never received the request at all — wrong
address, dead line, nobody home. A crash means something broke before it could answer either way.
`REFUSED` requires the opposite: the request arrived intact, was read, was evaluated against
whatever the receiving system checks for, and was turned down on purpose. It's the same difference
between silence and a written rejection — [a firmware label that fails a device on sight rather
than letting it run degraded](/stories/firmware-warning-label) is doing the same thing,
refusing loudly instead of quietly not working.

## What makes the blinking cursor the actual subject of the design, not the error?

Because the error code and its label are the system reciting a rule. The cursor on the empty line
after it is the system still running, still listening, having said no and not gone anywhere.

An error alone reads as a dead end — case closed, nothing left to say. A cursor blinking on the
line beneath it reads as a system that's still there, still capable of a different answer given a
different request, and that's the detail that turns a static rejection into something closer to a
conversation that stopped rather than one that never started. It's the one part of the print doing
anything other than reporting a fact.

## Is an error code like 0x1F4 anyone's property?

No. A hexadecimal error number and a short all-caps label are exactly the kind of generic technical
convention nobody owns — the format itself, not any specific numbering scheme borrowed from a real
protocol or a real product's actual error table.

Reproducing an identifiable real system's exact error code and message, especially one associated
with a specific named product, would be a different matter, closer to quoting proprietary
documentation than to using a shared convention. Inventing the code avoids that question entirely
and loses nothing — a fictional `0x1F4` reads exactly as convincing as a real one, because the
format is what's doing the work, not the specific digits.

## Does the same print work for a rejection that isn't technical?

Any refusal delivered in the system's own fixed voice, rather than translated into something
friendlier, keeps the same weight.

A licence agreement that says no to a use case in the same flat clause structure as everything
else it permits works the same way [an agreement written for a body part rather than a piece of
software does](/stories/end-user-agreement-shirt) — the refusal lands harder precisely
because nothing in the document's tone changes to acknowledge it's a refusal. A terminal doesn't
soften `REFUSED` into something gentler. That flatness is the entire effect, and it survives moving
to a different kind of rejection as long as the voice stays just as flat.

## Isn't an error message a strange thing to want on a shirt?

Less strange than it sounds, once the message is read as the only thing this kind of system says
in its own words.

Most of what a machine communicates gets translated for a human before anyone sees it — a
[transcript of a conversation carried through an earpiece](/stories/translation-earpiece-transcript)
is somebody else's words rendered readable. An error code is the rare case where the raw text
never gets softened for an audience, because the audience was assumed to be another system, not a
person. Printing it unedited is printing the one honest sentence a piece of infrastructure ever
produces.

## Does it print well?

Yes, and it wants almost nothing beyond the type itself.

One amber ink on near-black is the entire palette a CRT-glow error needs — anything closer to a
true white loses the phosphor read that makes it look like a screen rather than a page. Fixed-width
type is not optional here; a proportional face breaks the illusion that this was captured off a
real terminal rather than designed to look like one. Keep the cursor block solid, not outlined —
outlined reads as a rectangle, solid reads as light.

## How do I get one made?

Describe the error at [JustOG](/) — the code, the refusal, how much empty line you want beneath
it. Pick a direction, drag the crop frame, see it composited on the real garment, and it's made to
order and shipped.

Designs other people have published are in the [shop](/shop).

One line refusing the connection, and a cursor underneath it that never stopped waiting.