Wearables · Node · WebSockets

Dossier

A private two-way feed to a pair of Meta Ray-Ban Display glasses. Someone at a keyboard writes; it appears on the lens. The wearer can answer back. Everything interesting about it is in the two problems that shape it: the eyewear must hold no secrets, and a socket will lie to you.

The bridge holds what the glasses can't

A wearable is the worst place to keep a credential.

The obvious way to build this is to hand the display app whatever it needs and let it talk directly to the services involved. That means the credentials ride along in the bootstrap — into a device you wear out of the house, hand to someone to try on, and cannot wipe remotely.

So a server-side bridge sits in the middle and holds all of it. The glasses receive a stream of already-normalised messages and never learn where any of it came from. Write access and read access are separate capabilities, so the composing side and the viewing side can be handed out independently — and revoked independently.

Composer

The writing side. Text and images go in, get normalised and resized server-side.

Bridge

Holds every secret, normalises everything into one stream, and owns delivery.

Viewer

Runs on the glasses. Receives messages. Knows nothing else.

A socket that accepts your data has not delivered it

The bug that rewrote the delivery layer.

A WebSocket send() that returns without error means the bytes went to the operating system. It does not mean they reached the other end. When a client half-opens — the sort of thing that happens constantly to a battery-powered device moving between networks — the server keeps writing into a connection it still believes is healthy, and the messages evaporate silently.

// what the server believed
ws.send(entry)            → no error → assumed delivered

// what actually establishes delivery
ws.send(entry)            → the transport accepted it, nothing more
client → ack(entry.id)    → the app confirms it rendered

So delivery is acknowledged at the application layer. The bridge holds a message as outstanding until the viewer says it arrived, and retries otherwise.

The subtle half of the fix: the server-side de-duplication had to re-broadcast on a duplicate rather than silently drop it. Dropping seems obviously correct — you already have this one — but if the first copy was the one that vanished into a half-open socket, the retry is discarded as a duplicate and the message can never arrive. The retry loop runs forever and converges on nothing. A dedupe that swallows retries is a delivery bug wearing a correctness costume.

Status

Deployed, working, and never worn in anger.

The feed is live and the two-way back-channel works. What it has never had is its actual occasion: it was built for a conference where display glasses turned out to be banned, so the wear test has no event to attach to. Everything below the lens is verified; the part that needs a crowded room and a real reason to glance down is still theoretical.