A print job is not a document archive — defining the print-relay model.
Most software that moves files is built to keep them.
Drive keeps them. Photos keeps them. Messaging apps keep them so conversations still make sense next week. That retention model is correct for collaboration and chat. It is the wrong default for a five-minute photocopy.
Yet in much of India, the path from phone to printer still runs through a personal chat. The paper leaves. The file often does not.
That mismatch is not a UI problem. It is a category problem: we are using an archive tool to perform a relay job.
Three Jobs People Confuse
| Job | What success looks like | Typical tools |
|---|---|---|
| Archive | Find the file months or years later | Google Drive, Apple Photos, Email |
| Conversation | History survives; context stays intact | Messaging apps, Slack, SMS |
| Print Relay | Paper out; digital residue permanently minimized | (under-built & neglected) |
A neighbourhood Xerox counter is almost always doing the third job. The customer wants ink on paper now. Neither party needs a long-lived shared folder. The shop does not need a searchable customer library. The customer does not need the counter’s phone to become an unmanaged backup of their bank statement.
When we route that job through a chat app, we import the second model into a third-model problem.
What a Print Relay Actually Is
A print relay is infrastructure with a narrow, strict contract:
- Accept a file for a specific shop session.
- Hold it in memory only long enough to render and print.
- Decrypt or display only for an authorized print action.
- Delete the platform’s copy immediately when the job ends.
It is a pipe with a timer — not a library with a search bar.
Useful architectural properties follow from that contract:
- Ephemeral by design — Expiry and cryptographic shredding are core features, not optional cleanup chores.
- Shop-scoped — The destination is a single counter queue, not a permanent chat thread.
- Session-bounded — One visit, a small number of files, then terminated.
The Physical Counter Reality
To put ink on paper, someone at the counter must render the document.
A platform that claims "nobody ever decrypts anything, ever" is describing a system that cannot physically print.
At Docshy, we do not claim blind magic. We claim zero retention on our side:
- In-browser AES-256-GCM encryption before upload.
- Short-lived ciphertext storage in memory during transmission.
- Decryption strictly for an authorized, logged-in shop print action.
- Immediate cryptographic shredding once printing completes.
The paper leaves with the customer. The digital file does not stay behind.
Closing
Say the true thing. Build for the counter you actually have. Delete what you no longer need.
That is the engineering standard we are holding Docshy to.
Originally published on blog.perceptova.com.
Abhinay Gokul Pulla
Founder & Director — Perceptova Intelligence Private Limited
Learn more at perceptova.com and docshy.com.
Top comments (0)