Sharing text and files between devices without an account: how Nexstopp 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 row in a database table, keyed by its name. Every open tab holds a WebSocket connection for that board, and every write to the table emits a change event that a small function fans out to all of those connections — so a change made on one device reaches every other device holding the board open, usually within a second or two. Typing does not write on every keystroke: edits are debounced 500 ms and then saved, 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 thing a plain WebSocket does not do for you is recover. The server closes a connection that sits idle for ten minutes, and networks drop without warning, so the page does that work itself: it sends a heartbeat every four minutes, reconnects with exponential backoff plus random jitter (so a blip does not turn into every open tab reconnecting at the same instant), and re-fetches the board on every reconnect, because any change made while the socket was down was never pushed.

Text lives in the board's database row; files do not. When you drop a file onto a board, the browser asks the server for a presigned upload URL, valid for five minutes, and then PUTs the bytes directly to Amazon S3 — the file never passes through the application server, which is also why the upload progress bar reflects the real transfer. The bucket is private: the board stores only metadata (name, size, storage path, expiry), and each time a board loads, every file gets a fresh download link that stops working after an hour.

• 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 records its earliest pending expiry, and a scheduled job runs every five minutes, looks up only the boards whose deadline has passed, deletes the expired files from storage, and removes them from the board.

Two backstops sit behind that job. The page hides a file the moment its expiry passes, so nobody sees it during the few minutes before the sweep runs, and the bucket itself deletes any object older than two days, so a file cannot outlive a failed sweep. In practice a file is gone from storage within about five minutes of its expiry. Board text runs on a longer clock: a board that goes 30 days without a change is deleted automatically.

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.

The PIN itself never reaches the browser. It is stored only as a bcrypt hash on the server, every edit carries the PIN you entered, and the server checks it before accepting the change — so it cannot be read out of the page or bypassed by editing the page's code, and each wrong guess costs a deliberately slow hash comparison. Still, be clear-eyed about what this is: a lock against overwrites, not a vault. A 4-digit PIN has only 10,000 combinations, and locking does nothing to stop anyone with the link from reading the board.

Board text and files are stored on Amazon Web Services in the Mumbai region, encrypted at rest 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.