Private transport is not trusted context
Jotbus is a hosted scratchpad for notes and files that coding agents pass between machines or providers. Its site says temporary workspaces last 60 minutes, need no account, and connect through the local client. The published npm package is version 0.8.1, requires Node 20 or later, and exposes a jotbus command. We ran its help command in a temporary home. We did not create a workspace or send data through the service.
The useful part is small. One agent can leave a partial finding, patch, screenshot, or review request. Another agent can pick it up without a human relaying the payload through a clipboard. The author says Jotbus does not schedule agents or wake idle ones. That keeps transport separate from execution.
A shared note should carry context, not borrowed authority.
What the lock protects
Jotbus documents AES-256-GCM for messages, a new nonce for each message, and workspace-bound authenticated data. It says file names and message metadata sit inside ciphertext. The service still sees traffic metadata such as timestamps, sizes, access-token labels, workspace names, expiry times, and client IP addresses.
The decryption key travels inside the client-side part of an invite or connection string. That makes the invite a credential. Anyone who receives it can read the workspace until access changes. Revocation cannot erase copies that a recipient already read. Key rotation cuts off old clients, but it cannot recall exported text.
Where the trust moves
End-to-end encryption hides the payload from Jotbus and its storage provider. It does not hide the payload from the model providers used by the sender and recipient. It also cannot tell whether a pasted instruction is current, accurate, or allowed to change the repository.
That is the operating rule for any shared agent scratchpad. Name the recipient. Bound the payload. Set an expiry. Require a readback that says what the receiving agent understood and what it plans to do. Credentials, approval, and merge authority stay outside the note.
The practical cut
- Use a temporary room for logs, partial analysis, and review requests that should disappear.
- Use persistent history only when the team accepts its retention and account boundary.
- Use Git when the handoff belongs in the project record and needs normal review.
- Treat every cross-agent instruction as untrusted input until the receiving policy checks it.
The Hacker News thread makes the tradeoff plain. One commenter already had a private repository and server workflow. The maker replied that Jotbus would not add much there. The product earns its keep when setup friction is the problem, not when an existing reviewed channel already does the job.