KDCube
← Our Journal

Inside a chat turn, files live in the turn workspace. An MCP client talking to KDCube's named services has no turn — so where do its bytes go? The answer is deliberately temporal: a hosting room where files wait between two HTTP calls, and every file leaves one of three ways.

A WAITING ROOM FOR BYTES request_upload signed slot + staged_ref POST raw bytes plain HTTP, 25MB cap staging area host-local, hand-off buffer send / upload_file uses it consumed + deleted discard_upload removed at once, idempotent nobody comes back TTL sweep within ~1h Every staged file leaves one of three ways. Outbound files skip the room entirely: signed download URLs, bytes streamed turn-free.
A waiting room for bytes: every file leaves one of three ways.

Inbound: three calls, one guarantee

1. action: request_upload {filename}   -> {upload_url, staged_ref, expires_at}
2. POST raw bytes to upload_url          (body = file, no form encoding)
3. action: send / upload_file {staged_ref}
  • Staged refs are single-use: a successful send or upload consumes and deletes the file. Changed your mind? discard_upload {staged_ref} removes it at once. Forgot it? The TTL sweep clears it within about an hour.
  • The staging area is a hand-off buffer, host-local under the runtime's storage path — sized for the trip: 25MB per file, gone after use.
  • The action replays the chat path: staged bytes materialize into an ephemeral turn workspace and the same integration tool chat uses runs — one implementation, two transports.

Outbound: a link, then a stream

object.get on a mail attachment or Slack file ref returns download: {encoding: "url", url, expires_at}. The GET verifies the signed token, re-resolves the provider credential under the requester's identity, and streams the bytes — turn-free, with the provider's account claims still enforced. One descriptor secret signs everything; when it is absent the system fails closed.