ChromVoid Blog
Pocket Host: A Private Cloud That Fits in Your Pocket
A phone can be more than a second screen. With a USB-first remote flow, it can become the source of truth for a desktop vault session.
Imagine sitting down at a desktop computer that you trust enough to use, but not enough to make it the permanent home for your private vault.
You want the bigger screen. You want the keyboard. You want the calm desktop workflow for passwords, notes, files, SSH keys, passkeys, and the other pieces of private infrastructure that usually become awkward on a phone.
But you do not want to copy the vault to that machine.
You do not want to publish a remote endpoint to the network.
You do not want the desktop to quietly become a second source of truth.
That is the idea behind Pocket Host.
Pocket Host is a ChromVoid design direction for turning a phone into a small private host over USB. The phone keeps the vault. The desktop becomes a temporary screen, keyboard, and remote dashboard. The cable is not magic security. It is a deliberate physical transport that the user chooses before anything opens.
The important part is not "cloud, but smaller."
The important part is this:
Your private data stays anchored to the device you carry, while another computer can borrow the interface only for the active session.
That is a different trust model from a cloud vault. It is also different from syncing the full vault to every desktop you use.
The Problem With Normal Remote Access
Most remote-access products eventually ask users to accept one of three tradeoffs.
The first tradeoff is cloud custody. Your data, metadata, sync state, or session broker lives somewhere outside your devices. That can be convenient, but the durable source of truth is no longer entirely local.
The second tradeoff is network exposure. Your private device has to become reachable through a local network, relay, tunnel, peer connection, or some other network path. That may be acceptable for many use cases, but it is not always what the user wants.
The third tradeoff is duplication. You install the app on another computer, restore or sync the vault there, and now that computer becomes another place that needs to be protected, backed up, locked, wiped, updated, and reasoned about.
ChromVoid already cares about local-first ownership. But local-first does not mean "only usable on one tiny screen." People still need desktop workflows.
Pocket Host asks a narrow product question:
Can a phone be the private host while a desktop acts only as a temporary client?
The answer should be yes, but only if the boundaries are explicit.
What Pocket Host Is
Pocket Host is not a new vault format.
It is not a NAS.
It is not a general file server.
It is not "sync everything over USB and hope the desktop behaves."
The product shape is simpler:
- The user opens ChromVoid on desktop.
- The desktop starts in a locked shell.
- The user chooses remote access.
- The user explicitly selects USB instead of network.
- The phone is connected by cable.
- The desktop and phone establish an authenticated secure channel.
- The vault is unlocked on the phone-side host.
- The desktop opens a remote dashboard for that active session.
- If the phone locks, the cable is detached, the session fails, or the user disconnects, the desktop dashboard closes.
The desktop does not become the authority. It does not get a silent long-term plaintext cache. It does not fall back to a network path just because USB failed.
The phone remains the host.
The desktop remains the client.
The session remains temporary.
Why USB Matters
USB is useful here because it is visible and intentional.
When a user plugs a phone into a desktop and chooses USB in the app, the transport decision is physical. That does not make USB inherently trusted. A cable can be bad. A host can be compromised. A local machine can still be dangerous.
But USB changes the product boundary.
There is no need to make the phone discoverable on Wi-Fi.
There is no need to rely on a relay just to open a dashboard next to the phone.
There is no need to pretend that "automatic transport selection" is always what privacy-sensitive users want.
For Pocket Host, USB should mean exactly USB. If the USB connection fails, the app should show a USB failure or return to transport selection. It should not silently try network remote access.
That detail matters because fallback behavior is part of the security model.
If a user picked a cable because they did not want a network path, switching to a network path without a new explicit decision breaks the promise.
The Cable Is Only a Pipe
It is tempting to say "USB is private because it is a cable."
That is the wrong model.
In Pocket Host, USB is only a byte stream. It is the pipe, not the security layer.
The private session still needs a secure channel above the transport. In ChromVoid's design, that means the desktop and phone authenticate each other and exchange encrypted messages before remote dashboard traffic is allowed through.
A good mental model is:
USB decides where bytes travel. The secure channel decides whether those bytes are trusted.
That separation keeps the architecture honest.
The desktop should not send plaintext vault RPC over USB.
The phone should not treat a USB device descriptor as identity.
The app should not trust serial numbers, manufacturer strings, model names, or bridge events as proof that the same trusted host is present.
Those details can help the user interface, but identity needs to be cryptographic. A paired host should be recognized by the key it proves it controls, not by a label that a device or bridge can report.
The Unlock Boundary
There is one more boundary that matters as much as pairing:
A connected transport is not an unlocked vault.
The desktop may discover the phone. It may pair with it. It may reconnect to a previously paired host. It may establish an encrypted session.
That still should not open the remote dashboard automatically.
The phone-side vault must be unlocked or explicitly approved by the host before the desktop sees the remote dashboard. That approval should travel inside the authenticated secure channel. A local desktop event like "USB connected" is not enough.
This creates a clear state:
The transport is ready, but the host is still locked.
That state is useful. It lets the desktop tell the user what is happening without pretending the vault is open. It also prevents a cable attach from becoming an access grant.
The user action that unlocks the vault remains attached to the host boundary.
Why This Is Not Just Sync
Sync is useful, but it changes ownership.
If every desktop has a full vault copy, every desktop becomes part of the durable security story. That may be the right choice for a primary workstation. It is not always the right choice for a temporary machine, a shared environment, a travel laptop, or a locked-down corporate network.
Pocket Host is designed around a different relationship.
The phone owns the catalog, the writer state, and the vault boundary. The desktop asks the active host to perform operations through the remote dashboard contract.
That difference matters for conflicts too.
If another client already owns the writer lock, a USB session should not get a special bypass because it is physically connected. It can stay live. It can show a read-only or locked-write state. But transport should not override sync rules.
The point is not to make USB privileged.
The point is to make USB explicit.
Where This Helps
Pocket Host is useful when the user wants a desktop-class interface without turning the desktop into the home of the vault.
That includes ordinary cases:
You keep your main vault on your phone, but once a week you want a full keyboard to clean up entries, move files, edit notes, or review credentials.
You use multiple machines and do not want to restore the vault on every one of them.
You are on a network where peer discovery, relays, WebRTC, VPNs, or firewall rules are unpredictable.
You are traveling and want a local cable path between phone and laptop without depending on internet availability.
You want a privacy posture that is easy to explain:
The phone has the vault. The desktop has the session. Pull the cable or lock the phone, and the desktop view closes.
That is not the right model for everyone. Some users want always-on sync across all devices. Some users want cloud recovery. Some users want a hardware security key for the strictest possible credential boundary.
Pocket Host is for the user who wants local-first portability with a larger working surface.
The Android-First Reality
The first practical target for this idea is Android.
Android has an established USB accessory model where an attached accessory can act as the USB host while the Android-powered device communicates with it through the accessory protocol. That gives ChromVoid a realistic path for an Android phone acting as the mobile vault host for a desktop-side bridge.
The real work is still in the details: permissions, cable quality, operating-system behavior, device quirks, background execution, reconnect behavior, and clear user prompts.
This is why an MVP should stay narrow.
The first version should prove one journey:
Connect Android phone by USB, choose USB on desktop, unlock on the phone, use the remote dashboard, detach or lock to close the session.
iOS is a different story. A generic "plug any iPhone into any desktop and run the same flow" promise would be misleading. iOS cable integrations have their own platform constraints and accessory-program realities. That path should be treated separately rather than hidden behind the same label.
Honest platform boundaries are better than universal-looking buttons that fail in confusing ways.
What Should Never Happen
A product like Pocket Host is defined as much by what it refuses to do as by what it enables.
It should not open a network session because USB failed.
It should not open the dashboard just because a cable was attached.
It should not trust USB metadata as host identity.
It should not write decrypted vault content into persistent desktop storage.
It should not let browser extensions, mounted vaults, SSH agents, or other OS-bound integrations inherit access just because the phone is connected.
It should not run a second local dashboard next to the remote dashboard and blur which Core is authoritative.
It should not treat stale pairing as a reason to silently downgrade into a fresh pairing flow. If pairing state is broken, the user should remove it and pair again deliberately.
These are not edge cases. They are the difference between a clear private-host model and a convenient but muddy remote-access feature.
The Honest Limitation
Pocket Host does not make a compromised desktop safe.
If a desktop is recording the screen, logging keystrokes, injecting UI, or controlling the operating system around the app, a cable cannot fix that. A remote dashboard still runs on a machine with its own security properties.
Pocket Host also does not replace backup. If the phone is the host and the vault is not backed up, losing the phone is still a serious event.
It does not make USB universally reliable. Cables, hubs, device firmware, OS updates, and power behavior all matter.
And it does not turn ChromVoid into a general private Dropbox. The MVP should stay focused on the remote dashboard, not broad file-server scope.
The promise is narrower:
Keep the vault source of truth on the mobile host, and let the desktop borrow access through an explicit, authenticated, fail-closed USB session.
That is a useful promise because it is specific enough to test.
Why This Fits ChromVoid
ChromVoid is built around an uncomfortable but practical idea:
Secrets need a visible boundary.
That boundary might be the local vault. It might be a mobile host. It might be a remote session. It might be a future module that uses the vault without exposing raw secrets to the interface around it.
The user should be able to tell where authority lives.
Pocket Host makes that visible.
The phone is the private host.
The desktop is the temporary client.
USB is the chosen transport.
The secure channel protects the session.
The host unlock gates the dashboard.
Detach and lock close the view.
That is the whole shape.
It is not as frictionless as "everything syncs everywhere." It is not trying to be. The friction is the point where it represents a real boundary and a real user decision.
The Takeaway
The personal cloud does not have to start with someone else's server.
For a certain kind of user, the most understandable private cloud is the device already in their pocket: encrypted, carried, locked, backed up by their own model, and connected only when they choose.
Pocket Host is ChromVoid's design direction for that user.
Use the phone as the host.
Use the desktop as the dashboard.
Use USB as an explicit transport.
Use a secure channel for every remote message.
Fail closed when the host locks, the cable detaches, or the session stops being trustworthy.
That is not a giant cloud platform.
It is a small, physical, understandable boundary.
And for private data, understandable boundaries are often the product.