“Commander, I need this snippet on the other machine.”
“Did you email it to yourself?”
“Yes.”
“Then congratulations. Our clipboard now has a marketing department.”
We can do better.
Drop Vault is MatrixSwarm’s encrypted, shared traveling clipboard. Paste text or drop a small file in Phoenix on one computer, then retrieve it from another Phoenix connected to the same live drop_vault agent. Give the item a title, add a note, pick it up at the other workstation, and delete it when you’re done.
A useful little agent with a useful little job. The clipboard has orders. It does not need a strategic offsite.
The deployment: one vault, one way in, one way back
Inside an existing MatrixSwarm deployment, Drop Vault only needs the normal command ingress and callback egress agents to communicate with Phoenix. A straightforward arrangement is:
Matrix core
├── matrix_https → command ingress from Phoenix
├── matrix_websocket → callback egress to Phoenix (hive.rpc)
└── drop_vault → encrypted shared clipboard
The Matrix core still handles the swarm’s normal routing. “Simple” here means adding a regular agent to that foundation, with an ingress/egress pair doing the transport work.
Already have that pair working? Reuse it. There is no prize for deploying a second front door because the first one looked lonely.
The ingress brings commands in. Drop Vault handles storage and retrieval. The egress relay carries replies back to the requesting Phoenix session. That last part matters: an accepted request with no working return path is the distributed-systems equivalent of shouting into a walkie-talkie with the battery removed.
There is one additional setup requirement: a dedicated Registry persistent_state record. That is the vault’s storage identity and key assignment, not another agent.
Create it as a simple workspace agent
Use a build that includes Drop Vault on both sides. Phoenix needs the palette entry and panel; MatrixOS needs the agent package, including both
drop_vault.pyandstore.py. Updating the desktop alone does not magically update the server. Telepathy remains outside the deployment budget.Open Swarm Workspace and drag
drop_vaultfrom the Agent Palette into your swarm. Keep its unique agent ID, or give it an appropriate unique ID. This is a normal workspace agent; the supplied implementation already does the clipboard work.Create a new, dedicated
persistent_staterecord in Registry and assign it to this agent’spersistent_stateconstraint. If you’ve configured Crypto Alert’s persistent state, the pattern will feel familiar. Create a separate record for Drop Vault. Reusing another agent’s storage identity is how a quick shortcut earns its own incident channel.Resolve the normal packet-signing constraint and keep the generated service configuration intact. Drop Vault advertises
hive.drop_vault.request@cmd_requestand useshive.rpcfor callbacks. In the arrangement above,matrix_websocketsupplieshive.rpc@cmd_rpc_route. Keep the ingress/egress connection and certificate assignments configured for your swarm.Deploy, connect Phoenix, select the agent, and open Drop Vault. The initial inbox listing loads automatically. Open the same agent from your second Phoenix instance, in the same universe, and you have your traveling clipboard.
Keep the same persistent-state record, state identity, key, and universe when redeploying. Back up the key securely with your recovery plan. The agent refuses to start without its required assignment and prevents two writers from opening the same store.
The vault is very literal about keys. “I’m pretty sure it was around here” is not a supported recovery mechanism.
Give it a harmless first mission
On computer A, open the Paste tab. Add an optional title and note, then type some text or use Paste from clipboard. Click Upload Text to send it.
Try this:
Drop Vault test only.
If this reached workstation B, the clipboard has successfully crossed the perimeter.
Please do not promote it to production manager.
On computer B, open the same vault and use Check now / Latest if needed. Select the entry, inspect the text, and click Copy text. The optional polling interval is 60 seconds, so an immediate manual check saves you staring at the screen like it owes you money.
For a file, set any title or notes first, then drop a small regular local file onto the file-drop area or use Choose files. On the other computer, select it and choose Save copy. The panel checks its SHA-256 checksum during retrieval.
Copy file asks where to save the file, then puts a reference to that local copy on your clipboard. Drag saved copy lets you drag an explicitly exported file into another application. These exports are real local copies, so choose their destination deliberately.
Finish the test with Delete from agent, then refresh the other Phoenix instance. For a persistence check, leave one harmless item stored, redeploy using the same state assignment, and verify it returns.
What the vault promises—and what the clipboard union declined
Content and catalogue metadata are encrypted at rest through MatrixSwarm’s existing persistent-state machinery, using authenticated AES-256-GCM encryption. SQLite runs in memory; the saved catalogue snapshot is encrypted, and stored objects have separate encrypted envelopes.
There is no plaintext upload spool or hidden plaintext download cache. Text is displayed as plain text, and stored files are never executed by Drop Vault.
The current limits keep the job deliberately small:
| Limit | Allowance |
|---|---|
| Each text entry or file | 1 MiB |
| Total stored content | 256 MiB |
| Inbox entries | 1,000 |
| Concurrent uploads | 4 |
| Transfer chunks | 8 KiB |
This is a handy home for snippets, notes, small configs, and compact files. A VM image arriving at the door will be politely informed that it has confused the clipboard with a freight terminal.
The inbox is shared. Every authorized operator connected to that swarm can list, retrieve, and delete committed entries. Use it with that audience in mind. Session-scoped replies keep responses routed to the right Phoenix session; they do not make stored items private to their uploader.
Encryption also does not recall exported files, clipboard history, screenshots, or backups. Deleting an entry removes it from the shared inbox; it cannot reach across the room and confiscate somebody’s saved copy.
If the inbox appears stuck
Check the command route, the live hive.rpc relay, callback signing, and the persistent-state assignment. A working entrance is only half the trip. With a lost upload acknowledgement, use Check now before retrying: silence does not prove the commit failed.
That is the whole operation: add the agent, assign its dedicated storage, give it ingress and egress, and move the small thing you actually needed on the other machine.
The clipboard has completed its mission. Somebody tell the email thread it can stand down.
🌐 Links & Resources:
Try MatrixSwarm: https://matrixswarm.com
Join the Community / Discord: https://discord.gg/2USbWVBVV
Download Server: https://github.com/matrixswarm/matrixswarm
Youtube: https://www.youtube.com/channel/UCMjiY4_-W2KP5fHXO0eC2ug
Top comments (2)
The lost-acknowledgement note leaves an interesting retry boundary: if the upload committed, the reply was lost, and another authorized operator deletes the entry before Check now, the refreshed inbox looks like it never committed.
Do uploads have a stable operation ID whose committed outcome survives deletion of the item? I'd test that exact sequence and retry the same ID after reconnecting: it should report the prior outcome rather than recreate a deleted entry. That is different from deduplicating by file checksum, since identical content can be two intentional uploads. I haven't run Drop Vault; this is a suggested lost-ack/delete race fixture based on the shared-inbox behavior here.
Thanks for spelling out that sequence. Each upload gets its own random ID, and SHA-256 checks content integrity. Repeat commits are recognized while the item exists, but we don’t currently retain a separate committed outcome after deletion. Upload ownership is also tied to the connection.
So you’re right: “Check now” can’t distinguish “never committed” from “committed, then deleted.”
Your reconnect/retry sequence is a useful regression case. A durable operation receipt, independent of the stored item, would let the same-ID retry report the prior outcome without recreating a deleted entry. Identical content uploaded intentionally twice would still have separate IDs.
Appreciate the concrete example—this is exactly the kind of feedback that helps.