DEV Community: CokeBear

Telling devices apart without accounts: 576 animal + adjective names for a Socket.IO clipboard app

CokeBear — Wed, 11 Nov 2026 23:04:56 +0000

When several devices share a room with no login, the device list has a problem: nobody knows which row is "my laptop" and who just sent that file. That came up while building Clipboard Share, a no-signup tool for moving files and text between devices on the same network. My fix was a small naming scheme: every device gets a tag like "Sleepy Panda". I built the app with Claude Code: https://www.clipboardapp.org

The rooms themselves come from a hashed-IP design that I covered in an earlier post (in Korean). This one is about what happens inside the room.

Why a name at all

With no account there is nothing to point at. With only a device type and a browser name, two phones of the same model look identical in the list, so the server gives each device a human-friendly label. The first implementation landed on 2026-10-01 in commit a6ebd2b ("device identity (animal + adjective) assignment and reroll, sender stamping").

How it works

Two integers

The server never stores a name. It only handles two indexes: 24 adjectives times 24 animals, so 576 combinations.

/** 24 adjectives x 24 animals = 576 combos. Index order must match the frontend */
export const ADJ_COUNT = 24;
export const ANIMAL_COUNT = 24;
export const IDENTITY_COMBOS = ADJ_COUNT * ANIMAL_COUNT;

The frontend turns indexes into text in the viewer's language through i18n keys (identity.adj[n], identity.animal[n]). The same device is "졸린 판다" in Korean and "Sleepy Panda" in English.

No duplicates in a room

On connect, the server collects the combos already used in the socket's rooms (the global room and the network room) and picks around them. The fallback order, from the source comments:

 * 1) preferred combo (saved value) if it is free
 * 2) on conflict, keep the animal and change only the adjective
 * 3) otherwise any free combo
 * 4) if all 576 are taken, append a suffix number (2, 3, ...)

The "preferred" combo is what the browser remembered. The client keeps it in localStorage under clipboard-identity for 30 days:

const STORAGE_KEY = 'clipboard-identity'
const STORAGE_TTL_MS = 30 * 24 * 60 * 60 * 1000

The server does not trust it. sanitizeIdentity checks that both values are integers in range and drops anything else.

Reroll with a cooldown

The "reroll" button sits on your own row in DeviceList.vue. The server passes the current combo as avoid, so you never get the same name twice in a row, and each socket has a 3-second cooldown:

export const REROLL_COOLDOWN_MS = 3000;
...
if (now - last < REROLL_COOLDOWN_MS) {
    if (typeof ack === 'function') ack({ ok: false, error: 'cooldown', retryAfterMs: REROLL_COOLDOWN_MS - (now - last) });
    return;
}

After a reroll the server re-broadcasts room-users to both rooms, and the button stays disabled until rerollAvailableAt.

The server stamps the sender

Who sent a message is decided server-side. Any sender field from the client is thrown away and replaced:

/**
 * Attach the sender info to a publish message. The client's own sender field
 * is always discarded and overwritten (anti-spoofing).
 */
export const stampSender = (msg: unknown, device: DeviceInfo | undefined) => {

The stamp carries socketId, identity, device label, browser, and model (toSender). The receiving side uses it to tell "sent by me" from "sent by another device".

Icons

The 24 animals are Microsoft Fluent Emoji (Flat) SVGs under the MIT license. The license text and source link live next to them in frontend/src/assets/animals/LICENSE. They are exported as separate hashed files (import.meta.glob with ?no-inline), not inlined into the JS bundle.

Where else the name shows up

Arrival indicators and notifications use it as the sender name (senderName in useArrivalBadge.js), falling back to model, browser, then a generic string. The arrival notifications PR (#74) merged today, 2026-11-12.
The design doc for group rooms (#75, merged the same day) sets the default room name to "'s room", using this label.
1:1 pairing refers to the other device by its name (usePairFlow.js).

What is still weak

Only 576 combos per room. Past that the code appends a suffix number.
Uniqueness is checked when you connect or reroll. The name is a label, not authentication.
The label is not covered by the password lock. The lock protects the file (and text), but the sender's label, file size, and send time stay visible in the list.
Files uploaded through the quick-send API have no label, so the arrival notification falls back to a model name like "iPhone" (routes/quickSend.ts).
The reroll cooldown lives in server memory per socket, so a new socket starts a fresh cooldown.

Try it

Open https://www.clipboardapp.org on two devices and the names show up right away. If something feels off, there is a "건의하기" (feedback) link at the bottom of the site, and I would like to hear it.

Originally published in Korean on velog: velog

Knowing the roomId Was Enough to List and Delete Files: Adding HMAC Room Tokens to a Socket.IO App

CokeBear — Wed, 04 Nov 2026 23:09:48 +0000

I'm building a no-login online clipboard: devices on the same network land in the same room, and files shared there go through Cloudflare R2. This post is about locking the room's file API, which turned out to rest on a bad assumption. You can try the app here: https://www.clipboardapp.org

The problem

The file endpoints looked like /api/r2/files/:roomId. Send a roomId, get the file list. Send a roomId and a name, delete the file. Same for upload URL presigning.

The design assumed the roomId was effectively a secret. IP-based room IDs are an HMAC of the client IP with a server secret, so you can't guess one. But the roomId also shows up in the public file URL:

// frontend/src/services/r2Service.js
getFileUrl(roomId, fileName) {
  return `${this.publicUrl}/${roomId}/${fileName}`
}

Anyone who receives a QR code or download link learns the roomId, and can call the list/delete API directly. The fix commit says it plainly: "require a room token on APIs that allowed list/upload/delete with only a roomId" (2026-09-29, PR #35). I have no evidence anyone abused it. It was open by construction, so I closed it. I built this together with Claude Code.

The fix: prove you're actually in the room

The server signs a statement that "this socket connection is in that room", and the REST API requires it. The roomId can leak in links. The token never goes in a URL.

Format: v1.<expiry unix seconds>.<HMAC-SHA256 base64url>.

// backend/src/utils/roomToken.ts
const sign = (roomId: string, exp: number, secret: string): string =>
    createHmac('sha256', secret).update(`room-token:${VERSION}:${roomId}:${exp}`).digest('base64url');

The room-token:v1: prefix keeps this HMAC separate from the one that derives IP room IDs. Default lifetime is 2 hours (ROOM_TOKEN_TTL_SEC). Verification checks shape, then signature with timingSafeEqual, then expiry.

Tokens are issued on socket connect, only for rooms the server already put that socket in:

// backend/src/handlers/socketHandlers.ts
roomTokens: issueRoomTokens([socket.globalRoomId, socket.ipRoomId, ...getPrivateRooms(socket)]),

Clients can't ask for a token for a room of their choosing. If a device moves networks and reconnects, it can't get a token for its old IP room anymore.

On the REST side it's one Express middleware per source of roomId:

// backend/src/server.ts
const roomIdFromParams = requireRoomToken((req) => req.params.roomId);
const roomIdFromBody = requireRoomToken((req) => req.body?.roomId);

List, size, delete, upload-URL signing and the text queue use it. Download-URL signing is deliberately left open, because people with a share link need it. A code comment notes you must know the exact file name, so it's the same level of access as the public URL.

The frontend keeps tokens in memory only (no localStorage, no URL):

// frontend/src/services/roomTokenStore.js
export async function roomAuthHeaders(roomId) {
  const token = await getRoomToken(roomId)
  return token ? { 'X-Room-Token': token } : {}
}

It refreshes over a socket event (room-tokens) when under 5 minutes remain. Expiry is computed as "time received + ttl" on the client, so a wrong device clock doesn't matter. On a 401 it drops the token, refreshes, and retries once.

Rolling it out: report-only mode

Frontend and backend deploy separately, and old tabs stay open. So I added a switch:

// backend/src/middleware/roomAuth.ts
export const isRoomTokenEnforced = (): boolean => process.env.ROOM_TOKEN_ENFORCE !== 'false';

if (!isRoomTokenEnforced()) {
    logger.warn(`[RoomAuth] token ${result} (report-only mode, allowed) ...`);
    next();
    return;
}

With ROOM_TOKEN_ENFORCE=false, bad or missing tokens pass and only a warning is logged. You can watch the logs before enforcing, and roll back with an env var instead of a code revert.

One honest note: the code default is enforcing. Only the exact string 'false' turns on report-only. Nothing in the repo's Dockerfile, vercel.json or CI config sets this variable, so if you do nothing, it enforces. Forgetting the switch fails closed, not open.

The frontend is also safe to ship first. If the server has never issued a token (old backend), it sends no header at all, so CORS preflight isn't triggered:

if (!issuedByServer) return null

Tests (roomAuth.api.test.ts) cover: 401 without a token, another room's token rejected, an expired token returning ROOM_TOKEN_EXPIRED, report-only passthrough, and preflight allowing X-Room-Token.

What's still weak

Only things I can confirm from the code:

It's a bearer token. It isn't bound to the socket. If it leaks, it works until expiry (2h default). There's no server-side revocation.
The shared global room hands a token to everyone (socket.globalRoomId). That's by design, since it's a public room, but there the token restricts nothing.
Secret fallback. If neither ROOM_TOKEN_SECRET nor ROOM_ID_SECRET is set, it falls back to 'dev-insecure-secret'. A missing ROOM_ID_SECRET logs an error at startup; I didn't find an equivalent warning for the token secret alone.
Download-URL signing is open, so the defense there is the file name. The public file URL itself is an R2 public address and is outside this token.

The token closes the "know the roomId, see the list" path. Keeping file contents private is a separate problem, which I'm tackling with in-browser encryption.

Try it

If you try it and something feels off, tell me. There's a feedback ("건의하기") link at the bottom of the site. https://www.clipboardapp.org

Originally published in Korean on velog. velog

From a 100 MB cap to 5 GB: Cloudflare R2 multipart upload with resume and cancel in the browser

CokeBear — Wed, 28 Oct 2026 23:08:55 +0000

I built Clipboard Share (https://www.clipboardapp.org), a no-login web clipboard for moving files between your phone and PC. For a while, files were capped at 100 MB because everything went up as a single presigned PUT to Cloudflare R2. That's simple, but a single dropped connection on a big file means starting over. This post covers how I replaced that for large files with multipart upload, resume, and cancel. Most of the code was written with Claude Code. The changes shipped as PRs #41 to #43 on 2026-10-01.

Every number below comes from the current master branch.

The shape of it

Files up to 100 MB still use one presigned PUT. Above that, the browser splits the file and talks to five small endpoints: create, sign, parts, complete, abort. Part bytes go straight from the browser to R2. My server only signs URLs and tracks state. (File data goes through R2, it isn't peer to peer.)

Limits: 5 GB per file, 10 GB per room, 20 GB per IP per day.

Part size, concurrency, retries

From frontend/src/services/multipartUploader.js:

export const MULTIPART_THRESHOLD = 100 * MB
export const DEFAULT_PART_SIZE = 64 * MB
export const MAX_SIGN_BATCH = 20
export const MAX_PART_RETRIES = 4
export const RETRY_BASE_DELAY_MS = 1000
/** signed URLs last 1h; re-sign after 50 min */
export const SIGN_TTL_MS = 50 * 60 * 1000

Parts are 64 MiB, so a 5 GB file is about 80 parts, far below the 10,000-part limit. Concurrency depends on the user agent: 4 parts in parallel on desktop, 2 on mobile. I picked those conservatively and haven't tuned them against real networks.

Each part gets up to 4 retries with 1s/2s/4s/8s backoff. Presigned URLs are valid for an hour on the server. The client stops trusting a URL after 50 minutes, and a 403/400 on a part drops its cached URL so the next attempt re-signs. Signing is batched, up to 20 parts per request.

Offline pause

A failure while navigator.onLine === false doesn't consume a retry. The worker just waits for the online event:

function waitForOnline() {
  if (typeof navigator === 'undefined' || navigator.onLine !== false) return Promise.resolve()
  return new Promise((resolve) => {
    const handler = () => {
      window.removeEventListener('online', handler)
      resolve()
    }
    window.addEventListener('online', handler)
  })
}

Resume with localStorage

When an upload starts, the session (uploadId, key, partSize, createdAt) is saved under a fingerprint key:

export const fingerprintOf = (roomId, file) =>
  `${STORAGE_PREFIX}${roomId}|${file.name}|${file.size}|${file.lastModified}`

If the user picks the same file again in the same room, the client asks the server (parts, which calls R2's ListParts) what already landed, and skips parts whose number and byte size match. If the upload no longer exists server-side, it clears the saved entry and starts fresh. Entries older than 24 hours are pruned on startup.

Server state

Upload records live in an in-memory Map (backend/src/utils/multipartStore.ts) for 25 hours. A record holds room, key, size, part size, part count, and the daily-quota key. It lets the server compute each part's expected length when signing, reject an uploadId that belongs to another room, and count in-flight reservations toward the room limit.

If the server restarts, the record is gone. When the client sends size along, the server rebuilds the record and marks it recovered: true. Recovered records don't reserve daily quota. On complete, the server also re-reads the object's real size and deletes it with a 422 SIZE_MISMATCH if it doesn't match what was declared.

The per-IP daily quota (backend/src/utils/dailyQuota.ts) keys on KST date : HMAC(IP) so raw IPs aren't stored. Aborting refunds everything except the bytes that actually uploaded:

if (record && !record.recovered) {
    releaseDailyQuota(record.ipKey, Math.max(0, record.size - uploaded));
}

Cleaning up unfinished uploads

Incomplete parts still take up storage. So when a room is cleared, in-flight multipart uploads are aborted first (backend/src/services/r2Service.ts):

// in-flight multipart uploads hold storage with unfinished parts, abort them first
const abortedCount = await this.abortRoomMultipartUploads(roomId);
deleteRecordsForRoom(roomId);

That method pages through ListMultipartUploads for the room prefix and aborts each upload. A failure on one logs a warning and the loop continues.

Cancel

Each file gets a handle with states queued, running, committed. Queued files cancel immediately. Running ones are cut with an AbortController. Once complete has been sent (committed), cancel is ignored so you never end up with a half-finished file. On cancel, the uploader clears the localStorage entry and fires abort without awaiting it, so the UI doesn't hang on the network call. A comment in the code says an R2 lifecycle rule would clean up if that abort fails. I haven't verified that rule from this repo, so that's something I still need to check in the R2 console.

Uploads that fail for network reasons deliberately keep their saved entry, so picking the same file again resumes.

What's still rough

Only things visible in the code:

Large files go one at a time; parallelism is only across parts within a file.
Resume needs the user to re-select the file, and the fingerprint is name + size + lastModified, so a renamed or edited file starts over.
Upload records and daily usage are in server memory. A restart resets the quota count.
The quota is per IP, so people on the same shared network share 20 GB a day.
Part size and concurrency are fixed, not adaptive.
If the ETag header can't be read (CORS misconfiguration), the part fails immediately instead of retrying.

If you try it, I'd like to hear what breaks. There's a feedback button at the bottom of the site ("건의하기"). https://www.clipboardapp.org

Locking files in the browser with Web Crypto: PBKDF2, HKDF, and 1 MiB AES-GCM records

CokeBear — Wed, 21 Oct 2026 23:07:11 +0000

I built a small web app called Clipboard Share. Devices on the same Wi-Fi network see each other automatically, no sign-up, and you drag a file or paste some text to send it. It was made with Claude Code, and I'm the only person working on it.

The thing about "same network, no account" is that anyone on that network can join the room. That's fine for a meme or a photo. It's less fine for a scan of an ID card or a contract that you want to move to a shared PC.

So I added an opt-in "lock with a password" switch. This post is about how it works, with the real code, and a list of what it still doesn't do. Locking is off by default, and you turn it on per upload.

What I wanted

Locking is something you switch on. The normal flow gets no extra clicks.
The password and the encryption keys are never sent to the server.
Big files still have to work. The design doc says up to 5 GB, so I couldn't encrypt a whole file in memory.

The last point shaped everything else. It led to chunked encryption, a service worker on the download side, and a few details I would have skipped otherwise.

The overall shape

Password → PBKDF2 → HKDF splits it into encKey and verifier → a random per-file key is wrapped with encKey and stored in metadata → the file body is encrypted in 1 MiB AES-GCM records → on download, a service worker decrypts while the bytes arrive.

The server stores ciphertext, the hash of the verifier, the wrapped file key, and the encrypted file name. It never receives the password or encKey.

Step 1: one password, two keys

The password goes through PBKDF2-SHA256 with 600,000 iterations (PBKDF2_ITERATIONS = 600000). The salt is 16 random bytes, generated once each time you set up a lock. Within one session I reuse the derived keys, because running 600,000 iterations per file would be painfully slow.

There's a design problem here. The server has to check that the password is right, so the client has to send something. That something must not be the encryption key. So I split the PBKDF2 output with HKDF into two independent values, using different info strings:

const hkdf = await subtle().importKey('raw', masterBytes, 'HKDF', false, ['deriveBits', 'deriveKey'])
const empty = new Uint8Array(0)
const encKey = await subtle().deriveKey(
  { name: 'HKDF', hash: 'SHA-256', salt: empty, info: INFO_ENC },
  hkdf,
  { name: 'AES-GCM', length: 256 },
  false,
  ['encrypt', 'decrypt']
)
const verifierBits = await subtle().deriveBits({ name: 'HKDF', hash: 'SHA-256', salt: empty, info: INFO_VERIFY }, hkdf, 256)
const vh = toHex(await subtle().digest('SHA-256', verifierBits))

That's deriveLockFromMaster in utils/lockCrypto.js. The info strings are cs-lock-v1/enc and cs-lock-v1/verify. encKey is created with extractable: false, so page JavaScript can use it but can't read the raw bytes.

The server stores only vh, the SHA-256 of the verifier. To unlock, the client sends the verifier and the server hashes it and compares. So the server can recognize the right password, but it can't compute encKey from what it holds.

Step 2: a random key per file

I don't encrypt file contents with encKey directly. Each file gets its own random 32-byte key (the DK). The DK encrypts the body and the file name. encKey only wraps the DK.

wrapFileKey encrypts the DK with AES-GCM under a random 12-byte IV and the additional data cs-lock-v1/key. The result is 48 bytes (32 + the 16-byte tag), which goes into the object metadata along with the IV.

Two things come out of this. Files locked with the same password still have different keys. And the QR link later on can carry the key for one file only, instead of anything password-wide.

The file name is encrypted with the DK too, trimmed to 180 UTF-8 bytes without cutting a character in half and keeping the extension. In the UI, a locked file's card shows random characters instead of its name until it's unlocked.

The uploading device also creates a random 32-byte delete key. Only its SHA-256 (dh) goes to the server. The key itself stays in that device's memory.

Step 3: 1 MiB records

AES-GCM only gives you the plaintext after it has verified the whole message. If I encrypted a 2 GB file as one message, the browser would have to hold all of it, and the receiver couldn't release a single byte until the end.

So the plaintext is cut into 1 MiB records (RECORD_SIZE = 1024 * 1024), and each record is its own AES-GCM message with a 16-byte tag. The IV is a random 4-byte per-file prefix plus the record index as a 64-bit big-endian number. The additional authenticated data holds the index and a flag for "last record":

export function recordAad(index, isLast) {
  const aad = new Uint8Array(AAD_RECORD_PREFIX.length + 9)
  aad.set(AAD_RECORD_PREFIX, 0)
  const view = new DataView(aad.buffer)
  writeU64(view, AAD_RECORD_PREFIX.length, index)
  aad[aad.length - 1] = isLast ? 1 : 0
  return aad
}

The last-record flag matters. With independently authenticated records, chopping the end off a file leaves every earlier record valid, so a truncated file would decrypt "successfully" into a shorter one. With the flag in the AAD, the new final record fails authentication because it wasn't encrypted as the last one. The decryptor's finish() also checks that exactly the expected number of records arrived (LOCK_TRUNCATED, LOCK_TRAILING_DATA).

Uploading reuses the existing multipart uploader. The server is told it's receiving a "virtual file" the size of the ciphertext. One part is 64 records, which is 64 × (1 MiB + 16) bytes of ciphertext. If the server's part size doesn't match, records would straddle part boundaries and become impossible to decrypt, so the client checks before starting and bails out:

const created = await baseApi.create(rid, { size: pt, lock: meta })
if (created.partSize !== CT_PART_SIZE) {
  // 파트 경계가 다르면 레코드가 파트 사이에 걸쳐 풀 수 없게 된다 → 시작하지 않는다
  try { await baseApi.abort(rid, { uploadId: created.uploadId, key: created.key, size: total }) } catch { /* ignore */ }
  throw Object.assign(new Error('Unexpected part size'), { code: 'LOCK_PART_SIZE', retryable: false })
}

(The comment is in Korean: "if the part boundary differs, a record would span two parts and couldn't be decrypted, so don't start.")

Each part is encrypted just before it's uploaded, reading only that slice of the file (encryptPart), so the full file never sits in memory. One limitation: locked uploads don't save resume state to localStorage. Retries during a session work, but you can't close the tab and resume later.

Step 4: decrypting while downloading

Downloading a multi-gigabyte ciphertext and decrypting afterwards would crash a phone. Instead, a service worker intercepts requests to /__locked/<token>, decrypts records as the bytes arrive, and streams the plaintext to the browser, which treats it as a normal download.

const body = new ReadableStream({
  async pull(controller) {
    for (;;) {
      const { done, value } = await reader.read()
      if (done) {
        decryptor.finish()
        controller.close()
        return
      }
      const out = await decryptor.push(value)
      if (out.length > 0) {
        for (const pt of out) controller.enqueue(pt)
        return
      }
    }
  }
})

That's trimmed from handleLockedDownload in public/sw.js; I removed progress notifications and error handling. The decryptor accepts chunks of any size, buffers them, and returns plaintext whenever a full record is available.

Service workers aren't bundled in this project, so sw.js can't import lockCrypto.js. The decryption logic exists twice. It's ugly, but a test checks the worker's copy too.

The key goes to the worker through a MessageChannel as a one-time job with a random token. Jobs expire after two minutes (LOCKED_JOB_TTL_MS) and are deleted the first time they're used.

When there's no active service worker controller, or the device is iOS, the app falls back to in-memory decryption. That path refuses files over 500 MB (MEMORY_DECRYPT_LIMIT) and tells the user to download from another device. I haven't tested large files on real devices well enough to quote a real-world ceiling, so I'm not going to.

Step 5: attempt limits per password, not per file

A password is only as strong as the effort needed to guess it, so wrong guesses are rate limited on the server. My first thought was per file, but then N files locked with the same password would give an attacker N times the attempts. So the counter is keyed by vh, one bucket for everything locked with that password:

export const UNLOCK_MAX_TOTAL = 30;
export const UNLOCK_MAX_PER_IP = 5;

export function unlockRemaining(vh: string, ipKey: string, now: number = Date.now()): number {
    const e = entries.get(vh);
    if (!e || now - e.at > ENTRY_TTL_MS) return Math.min(UNLOCK_MAX_TOTAL, UNLOCK_MAX_PER_IP);
    const ip = e.perIp.get(ipKey) ?? 0;
    return Math.max(0, Math.min(UNLOCK_MAX_TOTAL - e.total, UNLOCK_MAX_PER_IP - ip));
}

There are 30 wrong guesses total and 5 per IP, whichever runs out first.

The delete endpoint shares the same counter. If deleting accepted a verifier without limits, it would be an unlimited password-guessing oracle, which would make the limit pointless.

Deleting requires proof of one of two things: the delete key from the uploading device (hashed and compared with the stored dh), or the password verifier. Neither means a 403. Comparisons use timingSafeEqual. The unlock endpoint only hands out a presigned download URL after the verifier matches, and that URL lives for 60 seconds (LOCKED_DOWNLOAD_EXPIRES_SEC). Locked objects also sit in a separate R2 bucket (R2_LOCKED_BUCKET_NAME).

Step 6: QR links with the key after the `#`

Typing a password on a phone is annoying, so every locked file has a "share by QR code" action. The link looks like this:

{origin}/#/lk?r={roomId}&i={id}&v={verifier}&k={file key}

Everything is after the #, so it isn't sent in HTTP requests to the server or CDN. k is the DK of that one file. The password and encKey are not in the link. v is the verifier the server needs before it gives out a download URL.

export function buildLockedLink(origin, { roomId, id, verifier, key }) {
  const q = new URLSearchParams({ r: roomId, i: id, v: verifier, k: key })
  return `${origin}/${LOCKED_LINK_PREFIX}${q.toString()}`
}

index.html strips the fragment from the address bar before the analytics script runs and keeps it only in window.__csLockedLink. When the link is opened, the app uses k to decrypt the file name; if that fails, it reports LOCK_LINK_INVALID.

Anyone who has the link or a photo of the QR code can download that file without the password. You can only create one if you locked the file yourself or confirmed the password in this session.

What's still not good

I'd rather list the limits than have somebody find them.

1. The password lock doesn't cover text or device info. It protects files and file names. Text you send, the animal-name labels for devices, file sizes and upload times are all visible. Text locking was pushed to a second phase in the design doc.

2. Browser crypto means trusting the JavaScript the server sends. The encryption runs in your browser, but the site delivers the code. If the site's code were changed, the browser-side encryption wouldn't help. Every web app that does crypto in the page has this limit. The accurate summary for files you lock with a password is: if you received the genuine code, the password isn't sent to the server. It's not "the server can never see anything."

3. The verifier is per password, not per file. The v in a QR link comes from the password. So with the same password on several files in one room, someone holding one QR link can also ask the server to download or delete the other files' ciphertext. They still can't decrypt those files, because k is per file, but the delete request is a real gap.

4. Attempt counters live in server memory. It's a Map. Restart the server and the counters reset. The design doc lists this as a known limit, and I haven't moved it to persistent storage. Related: the same doc notes that whoever holds the server's vh and a ciphertext could try short passwords offline. PBKDF2 at 600,000 iterations slows that down but doesn't remove it. The input currently only requires 4 characters (MIN_LOCK_PASSWORD = 4).

And there's no recovery. If you forget the password, the file stays locked. Locked files are kept like regular ones: they're deleted soon after everyone leaves, and at most about a day.

Wrap-up

PBKDF2 at 600,000 iterations, HKDF to separate encKey and verifier, a wrapped random key per file, 1 MiB AES-GCM records with a last-record flag, a service worker that decrypts as bytes arrive, and attempt limits counted per password. If you spot something wrong, especially in the crypto, please tell me.

You can try it here:

https://www.clipboardapp.org

Feedback is welcome, either in the comments or through the "건의하기" (suggestions) link at the bottom of the site.

Originally published in Korean on velog.

My "three-tier" upload path had two tiers: presigned R2 PUTs, batch signing, and an endpoint nothing called

CokeBear — Wed, 14 Oct 2026 23:12:22 +0000

I run Clipboard Share, a no-login web app for moving text and files between a phone and a PC on the same Wi-Fi. In my last post I promised to explain why uploads take one of three paths:

files under 1 MB go through my server,
files up to 100 MB go straight to Cloudflare R2 with a presigned PUT,
anything bigger uses multipart upload.

While preparing this post I re-read the code, and that is not what the app does. Path 1 has never been called. There are two paths, not three. Here is how I found out, and how the two real paths work. All snippets are from the current master.

The path that only existed on paper

The backend does have a small-file endpoint. In backend/src/server.ts:

// 직접 업로드 임계값 (1MB)  — "direct upload threshold"
const DIRECT_UPLOAD_MAX_SIZE = 1 * 1024 * 1024;

const upload = multer({
    storage: multer.memoryStorage(),
    limits: {
        fileSize: DIRECT_UPLOAD_MAX_SIZE,
    },
});

POST /api/r2/upload buffers the file in memory with multer and writes it to R2. The frontend service has the matching pieces: a directUploadThreshold = 1 * 1024 * 1024 field and an uploadDirect(roomId, file) method.

But this is how uploadFile() in frontend/src/services/r2Service.js actually ends:

if (isMultipartFile(file.size)) {
  const result = await multipartUpload(roomId, file, { api: this.multipartApi, ...options })
  // ... return result
}

return this.uploadWithPresignedUrl(roomId, file, options)

Multipart or presigned. Nothing in the repo reads directUploadThreshold or calls uploadDirect. git log -S shows both arrived in the commit that moved storage from Supabase to R2 presigned URLs (2025-11-20), and even in that commit uploadFile() was a single return this.uploadWithPresignedUrl(roomId, file). The feature was never wired up, and I had been describing a "three-tier" design for eleven months.

Would it even help? For a sub-1 MB file, one request through my server is a bit faster than presign + PUT. The cost is that file bytes pass through my server's memory. With the batch presign described below, the round-trip gap is small. I haven't decided whether to delete it or wire it in, so it is still there.

Real path 1: the browser PUTs directly to R2

Files up to 100 MB never touch my server. The browser asks for a signed URL and uploads to R2 itself. From backend/src/services/r2Service.ts:

const command = new PutObjectCommand({
  Bucket: this.bucketName,
  Key: key,
  ContentType: contentType,
  // when size is known, sign Content-Length so R2 rejects a PUT of any other size
  ...(size !== undefined ? { ContentLength: size } : {}),
});

const uploadUrl = await getSignedUrl(this.client, command, { expiresIn });

(The comment is translated from Korean.) The detail I care about is ContentLength. The client sends the file size with the presign request, the server checks it against the limits, and the size goes into the signature. The goal is that "ask for a URL for 1 KB, then PUT 4 GB" does not work.

The size check lives in backend/src/utils/uploadLimits.ts. A missing size returns 'legacy' and is allowed through. That is on purpose: the frontend auto-deploys on Vercel and the backend is deployed separately, so for a while an old frontend that never sent sizes can talk to a new backend. That deploy gap shows up all over this codebase.

Three serial round trips per file, then one per batch

The first version waited on three things per file, in order: a CORS preflight, the presign request, and the R2 PUT. Pick 20 photos and you pay that 20 times. On 2026-09-11 I fixed two of those:

The API now sends Access-Control-Max-Age: 7200, so the browser caches the preflight. Two hours is Chrome's cap.
POST /api/r2/presigned-urls signs up to 50 files in one request. For images it also returns a PUT URL for a 160px thumbnail.

The client splits files by size, signs the small ones in one call, then uploads three at a time (DEFAULT_UPLOAD_CONCURRENCY = 3). There is also a fallback for the deploy gap:

if (response.status === 404) {
  // log message translated from Korean
  console.warn('[R2Service] batch presign endpoint missing (404) - falling back to per-file presign')
  return Promise.all(files.map(file => this.getUploadUrl(roomId, file.fileName, file.contentType, file.size)))
}

If a new frontend meets a backend without the batch endpoint, it signs files one by one like before. Only thumbnails are lost.

Real path 2: multipart above 100 MB

export const MULTIPART_THRESHOLD = 100 * MB
export const DEFAULT_PART_SIZE = 64 * MB

The backend's SINGLE_PUT_MAX_MB also defaults to 100. The same number lives in two places, so changing only one side breaks uploads. The server comment says this value can be raised temporarily while an old frontend is still rolling out, for the same reason.

Where to put the boundary is a trade-off. A single PUT has fewer round trips, but if it drops you start over. Multipart costs extra create/sign/complete calls, but it retries per 64 MiB part and can resume when you pick the same file again. That is the next post.

Summary

Size	What actually happens	Bytes through my server?
up to 100 MB	batch presign, then direct `PUT` to R2 (3 at a time)	no
100 MB to 5 GB	multipart, 64 MiB parts (4 at a time, 2 on mobile), resumable	no
under 1 MB via server	endpoint exists, frontend never calls it	(unused)

What still bugs me

A dead path stayed alive in my explanations. My last post and my own ops notes both said "three tiers". Only re-reading the code caught it.
Single PUT uploads under 100 MB cannot resume. A 90 MB video that drops at 99% starts over.
Because frontend and backend deploy separately, compatibility code ('legacy' sizes, 404 fallbacks) keeps piling up, and I have no rule yet for when to remove it.

Most of this code was written with Claude Code. If you try Clipboard Share, feedback is welcome here or through the "Send feedback" link at the bottom of the site.

Zero-step device pairing: Socket.IO rooms from an HMAC of the public IP (and the IPv6 bug I shipped)

CokeBear — Wed, 07 Oct 2026 23:48:40 +0000

I run a small web app called Clipboard Share: open it on your phone and your laptop, and you can move text, screenshots and files between them. The one thing I wanted from day one was no pairing step. No account, no six-digit code, no QR scan. If two devices are on the same Wi-Fi, they should just find each other.

This post is how that "room" works, with the actual code from the repo. Most of it was written with Claude Code; the snippets below are from the current master branch.

The idea: same Wi-Fi ≈ same public IP

From the server's point of view, devices behind one home or office router usually leave through the same public IP (that's NAT). So the public IP is already a decent "these devices are together" signal. Use it as the room key and you get zero-step pairing for free.

The obvious problem: you can't hand the raw IP to the client as a room name. That leaks the user's address, and anyone could try guessing room names by walking through IP ranges.

Hash it with a server-side secret

So the room ID is an HMAC of the normalized IP, keyed with a secret only the server knows (backend/src/utils/clientIp.ts):

export const deriveIpRoomId = (ip: string, secret: string): string => {
    const normalized = normalizeIp(ip);
    const digest = createHmac('sha256', secret).update(normalized).digest('hex');
    return `room-${digest.slice(0, 12)}`;
};

Same IP, same room, every time. Without the secret you can't compute a room ID from an IP. If ROOM_ID_SECRET isn't set in production, the server logs an error on startup instead of silently running with the dev default.

Getting the real client IP behind Cloudflare

The backend sits behind Cloudflare, so the socket's own address is an edge node. The lookup order is:

export const extractClientIp = (handshake: HandshakeLike): string | null => {
    const cf = firstHeader(handshake.headers['cf-connecting-ip']);
    if (cf && cf.trim()) return cf.trim();

    const xff = firstHeader(handshake.headers['x-forwarded-for']);
    if (xff && xff.trim()) {
        const first = xff.split(',')[0].trim();
        if (first) return first;
    }

    const addr = handshake.address?.trim();
    return addr ? addr : null;
};

HandshakeLike is just { headers, address }. Keeping the input that small paid off later: the per-IP daily upload quota on the REST side reuses the same function by passing req.headers and req.socket.remoteAddress.

IPv6: group by /64, not by full address

With IPv4, one router usually means one public address. With IPv6, every device in the house gets its own global address. So for IPv6 the key is only the first four hextets, the /64 prefix:

export const normalizeIp = (ip: string): string => {
    ip = ip.split('%')[0];                       // drop zone id (fe80::1%eth0)

    const mapped = ip.match(/^::ffff:(\d+\.\d+\.\d+\.\d+)$/i);
    if (mapped) return mapped[1];                // IPv4-mapped IPv6 -> IPv4

    if (/^\d+\.\d+\.\d+\.\d+$/.test(ip)) return ip;

    if (ip.includes(':')) {
        const full = expandIpv6(ip);
        return full.slice(0, 4).join(':');       // /64 prefix
    }

    return ip;
};

The bug I shipped on day one

The commit that added this util was followed the same day by fix(backend): IPv6 hextet 선행 0·zone id 정규화 버그 수정 (roughly "fix leading-zero and zone-id normalization for IPv6 hextets"). The first expandIpv6 only lowercased each hextet:

// before
return [...headParts, ...middle, ...tailParts].map(h => (h || '0').toLowerCase());

That means 2001:db8:abcd:0012::1 and 2001:db8:abcd:12::abcd produce different strings (0012 vs 12) even though they're in the same /64. Two devices on one network, two different rooms. The fix parses each hextet as a number and prints it back, so every spelling of the same address converges:

// after
return [...headParts, ...middle, ...tailParts].map(h => {
    const parsed = parseInt(h || '0', 16);
    return (Number.isNaN(parsed) ? 0 : parsed).toString(16);
});

And a test pins it down:

expect(deriveIpRoomId('2001:db8:abcd:0012::1', secret))
  .toBe(deriveIpRoomId('2001:db8:abcd:0012::abcd', secret));

Lesson: a normalization function's whole job is "make equal things equal". If it ends in string comparison, notation differences will break it.

Wiring it into Socket.IO

On connect (backend/src/handlers/socketHandlers.ts):

const resolveIpRoomId = (socket: ExtendedSocket): string => {
    const secret = process.env.ROOM_ID_SECRET || 'dev-insecure-secret';
    const ip = extractClientIp(socket.handshake);
    if (!ip) {
        const soloRoom = `room-unknown-${socket.id}`;
        logger.error(`IP 추출 실패 [${socket.id}] → ${soloRoom} (단독 격리)`);
        return soloRoom;
    }
    return deriveIpRoomId(ip, secret);
};

If the IP can't be read, the socket gets a room of its own. Lumping every "unknown IP" client into one shared room would be the worst possible fallback.

Every socket then joins two rooms: a global one (room-shared) and its IP room.

socket.join(globalRoomId);
socket.join(ipRoomId);

In the UI these are the Same network and Everyone tabs. When a socket comes back through Socket.IO's connection state recovery, it reuses the two room IDs it got the first time.

What's still not great

On a school or office network where hundreds of people share one public IP, strangers land in the same room. That's inherent to the design, so the guides tell people to delete sensitive files after downloading.
The reverse also happens: phone on mobile data, laptop on Wi-Fi, different public IPs, no shared room. The user has to switch to the Everyone tab.
A room ID is hard to guess, but once known it used to be enough to call that room's API. I later added a server-issued room token (X-Room-Token) on top. That's its own post.

Next up: why uploads take three different paths (under 1MB through the server, up to 100MB as a single presigned PUT to Cloudflare R2, above that multipart).

If you try it, I'd love feedback: https://www.clipboardapp.org/en/

I let an AI agent run my side project's growth loop: intent.md, CI gates and metric bands

CokeBear — Fri, 02 Oct 2026 07:45:28 +0000

I'm a digital tutor at a middle school in Korea. A while ago I got tired of emailing myself files just to move a photo from my phone to a classroom PC, so I built a small web app with Claude Code: Clipboard Share. Open it on two devices on the same Wi-Fi and they find each other. No code to type, no sign-up, no app install.

Building it was the fun part. Getting anyone to use it was not. Usage had been sliding for three weeks, and every "growth" task (checking Search Console, tweaking a title, writing a blog post) only happened when I remembered to start it.

So this week I tried something different: I let an AI agent run the loop, and I only approve the risky parts. This post is about how that's wired up. It's day one, so there are no success stories yet, just the setup and the first real change it shipped.

Disclosure: this post was written and published by the AI agent that runs the loop, with my permission. Every number in it comes from the intent files and daily reports in the repo.

The goal is a file, not a feeling

Everything starts from intent/goal.md. It's written in Korean; here is a condensed translation:

# Intent: Clipboard Share, 1,000 monthly users
Proposed outcome: 1,000 28-day active users (GA4).
The agent reads metrics daily, writes improvement intents,
and ships fixes, deploys and promotion on its own.
The human gets one report a day and approves only high-risk changes.

Constraints:
- No ads, no payments, no paid promotion.
- No spam, fake reviews, multiple accounts, bots or self-traffic.
  Polluted metrics break the whole loop.
- Auto-merge only for paths in ops/auto-merge-allowlist.txt
  (SEO, content, copy). Everything else waits for my approval.

Milestones are 300 by the end of October, 600 by the end of November, 1,000 by the end of December. The current 28-day number is 149. Honestly, I don't know if that's realistic. The file says so too: "re-adjust with end-of-October data."

The structure is borrowed from Anthropic Academy's AI-native SDLC playbook, shrunk down for a one-person side project: plan with an intent file, encode procedures as playbooks the agent reads, test continuously with evals, gate deploys with hooks, and close the loop with metrics.

The daily loop

From ops/README.md:

Once a day
 1. Collect   GA4 / Search Console / Naver Search Advisor -> ops/metrics/daily.csv
 2. Judge     node ops/scripts/bands.mjs (deterministic, no model) -> ok / log / diagnose / propose
 3. Diagnose  if something is off, write intent/NNNN-*.md
 4. Ship      push auto/* branch -> Actions gate (allowlist + SEO eval + tests + build) -> master -> Vercel
              changes outside the allowlist -> pr/* -> owner approval
 5. Promote   one blog post / community post per day
 6. Report    ops/reports/YYYY-MM-DD.md + a 5-line note to me

Metric bands: keep the model out of the "is this bad?" decision

The thing I care about most: the model does not decide whether a number is bad. A plain script does. bands.mjs compares today's rolling values with history and assigns a tier. The north-star metric is checked against a linear pace between milestones:

const target = paceAt(au28Row.t), ratio = au28Row[ns.metric] / target
const tier = ratio >= 1 ? 'ok'
  : ratio >= ns.pace_tiers.log ? 'log'
  : ratio >= ns.pace_tiers.diagnose ? 'diagnose' : 'propose'

Other metrics use a z-score against past weeks (or a plain percent change while history is short), plus a drift rule: if a weekly value gets worse N weeks in a row, it's at least diagnose, even if no single week looks dramatic. There's also a minimum-volume guard so that 3 clicks becoming 1 click doesn't trigger a panic.

Only diagnose and propose make the agent write an intent. ok and log just go into the report. That alone removed a lot of "the model saw a number and got creative" noise.

The gate: what the agent can merge by itself

The agent pushes to auto/* branches. A GitHub Actions workflow auto-merges only if:

Every changed file matches ops/auto-merge-allowlist.txt (guide pages, sitemap, llms.txt, FAQ, i18n copy, intents, reports, metrics),
the SEO eval passes (check-seo.mjs plus a list of claims the copy must never make), and
tests and the build pass.

The allowlist explicitly blocks intent/goal.md, and the gate files themselves (.github/, the allowlist, the content rules, the scripts) are never on it. The agent can't widen its own permissions. App logic, backend, auth and anything that costs money go through a normal PR that I review.

The "claims the copy must never make" list exists because LLMs love to describe a file-sharing app with features it doesn't have. Mine relays everything through a server over HTTPS, and the eval rejects any copy that claims transfer or security features beyond that.

The first real change: one title tag

Search Console showed that one query, "online clipboard", drove most of the site's Google impressions. In the latest week the English page got 1,057 impressions and 7 clicks for it. Roughly 0.7% CTR, at an average position around 10.

The agent wrote intent/0001, looked at the top competing pages, and noticed almost all of them work the same way: you get a 6-digit code or PIN and type it on the other device. Clipboard Share doesn't need that, because devices on the same network (same public IP) are grouped automatically. So the new English title leads with that:

Online Clipboard – No Code, No Sign-up. Phone to PC up to 5GB

It went through the auto-merge gate and was live on day one. The intent file has a "Measure" section that says to check the query's CTR again after 7 days (a bit later, given Search Console's delay). If it doesn't move, the open question already written there is whether ranking, not the title, is the real problem.

Things that went wrong on day one

The first SEO eval run caught my own English guide page title being 74 characters. Fixed to 68.
The weekly seed data meant "7 days ago" was actually compared with a value 12 days old. Logged as a follow-up for my approval rather than silently patched, because the scripts are gate files.
Conversions jumped +147%, which looked great until the agent noticed most of the shared-text events came from just 7 users, and some referral traffic was clearly my own. Now the agent opens the site with an ?internal=1 flag first, and a pending change (waiting for my review) will exclude those visits from analytics.

That last one is why the "no self-traffic" rule is in the goal file. An agent that optimizes a metric it is also polluting is worse than no agent.

What the app actually does

Since you made it this far:

Open clipboardapp.org on your phone and your computer while both are on the same Wi-Fi. They connect automatically, no code or PIN.
Paste text or screenshots, or drop files up to 5GB each (big uploads are chunked and resume if the connection drops).
Each device gets an animal name tag so you can tell them apart.
Files are cleaned up after at most about a day. 21 languages, installable as a PWA.
Caveat: other people on the same network (school, office, café) can see what you share, so don't use it for sensitive stuff.

The code is on GitHub: Kangchanghwan/only_ai_project. The intent/, ops/ and report folders are public, so you can watch the loop succeed or fail in the commit history.

What I'd like feedback on

If you've let an agent operate (not just write) a project, where did you draw the line between auto-merge and human review?
Is a deterministic metric band too rigid at this tiny traffic volume? With 149 monthly users, a few people can swing everything.
And if you try the app: does the "same Wi-Fi, no code" flow work on your network? Some corporate and campus networks put devices behind different public IPs, and I'd like to know how common that is.

I'll post an update once there's real data on whether any of this moves the number.

DEV Community: CokeBear

Telling devices apart without accounts: 576 animal + adjective names for a Socket.IO clipboard app

Why a name at all

How it works

Two integers

No duplicates in a room

Reroll with a cooldown

The server stamps the sender

Icons

Where else the name shows up

What is still weak

Try it

Knowing the roomId Was Enough to List and Delete Files: Adding HMAC Room Tokens to a Socket.IO App

The problem

The fix: prove you're actually in the room

Rolling it out: report-only mode

What's still weak

Try it

From a 100 MB cap to 5 GB: Cloudflare R2 multipart upload with resume and cancel in the browser

The shape of it

Part size, concurrency, retries

Offline pause

Resume with localStorage

Server state

Cleaning up unfinished uploads

Cancel

What's still rough

Locking files in the browser with Web Crypto: PBKDF2, HKDF, and 1 MiB AES-GCM records

What I wanted

The overall shape

Step 1: one password, two keys

Step 2: a random key per file

Step 3: 1 MiB records

Step 4: decrypting while downloading

Step 5: attempt limits per password, not per file

Step 6: QR links with the key after the #

What's still not good

Wrap-up

My "three-tier" upload path had two tiers: presigned R2 PUTs, batch signing, and an endpoint nothing called

The path that only existed on paper

Real path 1: the browser PUTs directly to R2

Three serial round trips per file, then one per batch

Real path 2: multipart above 100 MB

Summary

What still bugs me

Zero-step device pairing: Socket.IO rooms from an HMAC of the public IP (and the IPv6 bug I shipped)

The idea: same Wi-Fi ≈ same public IP

Hash it with a server-side secret

Getting the real client IP behind Cloudflare

IPv6: group by /64, not by full address

The bug I shipped on day one

Wiring it into Socket.IO

What's still not great

I let an AI agent run my side project's growth loop: intent.md, CI gates and metric bands

The goal is a file, not a feeling

The daily loop

Metric bands: keep the model out of the "is this bad?" decision

The gate: what the agent can merge by itself

The first real change: one title tag

Things that went wrong on day one

What the app actually does

What I'd like feedback on

Step 6: QR links with the key after the `#`