Sharing text and files between devices without an account: how ClipVault boards work

Board names are 3 to 6 characters: lowercase letters, digits, and single hyphens. Anything you type is normalized first — Unicode NFKC, lowercased, runs of other characters collapsed to a hyphen — so /b/My-Board and /b/myboard resolve to the same board rather than silently splitting into two. The same validation code runs on both the create side and the read side, so the rules cannot drift.

If you use the generator instead of picking a name, it draws 6 characters from a 32-character alphabet that deliberately excludes I, O, 0, and 1 — the characters people misread when saying a code out loud. That gives 32^6 = 1,073,741,824 possible codes. That is enough that nobody stumbles into your random board by accident, but it is not a cryptographic secret: short memorable names like /b/test are trivially guessable, and that is by design — a board named 'test' is meant to be easy to type on the second device. Treat the name accordingly.

Each board is one Firestore document. Every open tab subscribes to it with a real-time listener, so a change written by one device is pushed to every other device holding the board open — typically within a second. Typing does not write on every keystroke: edits are debounced 500 ms and then written with a merge, and the page tracks the last value it pushed so its own echo coming back from the server does not clobber what you are currently typing.

The sync model is last-write-wins on the whole text field. There is no operational transform or CRDT underneath — this is a shared clipboard, not a collaborative editor. If two people type into the same board simultaneously, the later write wins and the earlier one is lost. For the intended use (one person, two devices, or one person handing data to another) this never matters; for real-time co-writing it would, and Google Docs remains the right tool for that. Text is capped at 65,000 characters, with a live counter in the footer.

One battle scar worth sharing: corporate networks. Some VPN and web-filtering proxies let Firestore's streaming connection open — so the client reports 'connected' — and then silently degrade it, so writes stop landing with no error. Two defenses came out of debugging that: the client forces plain long-polling instead of the streaming transport (slightly more overhead, far more proxy-compatible), and every write races a 10-second timeout so the sync indicator can honestly report failure instead of showing a stale 'synced' state forever.

Text lives in the Firestore document; files do not. When you drop a file onto a board, the browser asks the server for a presigned upload URL and then PUTs the bytes directly to Cloudflare R2 object storage — the file never passes through the application server, which is also why the upload progress bar reflects the real transfer. The board document stores only metadata: name, size, download URL, and expiry time.

• Up to 3 files per board, any type, 25 MB each. If your file is over the limit, compress it first — the image compressor and PDF merge tools run in-browser.
• Every file gets an expiry you choose at upload time: 1 hour or 24 hours. There is no 'keep forever' option for files, on purpose.
• Expired files are actually deleted from storage, not just hidden. Each board stores a nextCleanupAt timestamp; a lightweight cleanup pass runs on page load, queries for boards whose deadline has passed (capped at 5 boards per run to keep read costs sane), deletes the expired objects from R2, and rewrites the metadata.

The honest caveat in that design: cleanup is triggered by visits. A board nobody ever opens again waits for some other visitor's page load to sweep it. Expiry is therefore reliable in practice on a site with steady traffic, but it is eventual, not instantaneous — an expired file may survive in storage for a while after its timestamp passes, even though every board view filters it out immediately.

Any board can be locked with a 4-to-8-digit PIN. Locking changes one thing: editing. Anyone with the link can still read the text and download the files; only someone who enters the PIN can modify or clear them. The unlock is remembered per browser tab session, so you are not retyping it constantly on your own device.

Be clear-eyed about what this is: a courtesy lock against casual overwrites, not a security boundary. The PIN is stored alongside the board data and checked in the browser, there is no rate limiting on guesses, and a 4-digit PIN has 10,000 combinations. It solves the real problem it was built for — 'I shared this link with a group and don't want someone accidentally wiping it' — and nothing stronger than that.

Board text sits in Firestore and files sit in R2 in plaintext (encrypted at rest by Google and Cloudflare's infrastructure, like essentially all cloud storage, but readable by the backend). There is no end-to-end encryption: the service could technically read what you paste, and anyone who knows or guesses a board name can open it. That is the price of the feature — E2E encryption would require a key that lives outside the URL, which means an account or a secret to transport, which is exactly the friction boards exist to remove.

So the rule is simple: boards are for things you would be comfortable writing on a whiteboard in a shared office. Links, snippets, a config file, a PDF someone needs in the next hour. Not passwords, not API keys, not personal documents. If you must move a secret, encrypt it first — the AES tool runs entirely client-side, so you can encrypt with a passphrase, paste the ciphertext to a board, and share the passphrase over a different channel.

None of these is wrong — a USB drive beats everything for a 40 GB folder, and a chat app you already have open is hard to argue with. Boards win the specific case of 'two arbitrary devices, right now, no shared account, small payload,' which turns out to be most days. A quick trick for the phone-to-laptop hop: generate a QR code of the board URL and scan it instead of typing.