DEV Community: Gathmo

Checksums in Browser Uploads: What They Prove and What They Do Not

Gathmo — Fri, 17 Jul 2026 18:47:55 +0000

Checksums are often added to upload protocols with an imprecise promise of “security.” A digest can detect accidental corruption and identify whether two byte sequences match. It does not prove who created a file, whether consent exists, or whether the media is safe to display.

Choose the integrity boundary

Decide which bytes are hashed. The original file selected in the browser, each uploaded part, the assembled object, and a transcoded derivative are different byte sequences. Record separate digests when the system needs to verify each boundary.

For an original-preserving service, the most useful comparison is browser source digest versus assembled storage-object digest. Large files should be streamed rather than copied into one enormous ArrayBuffer.

Understand browser limits

The standard Web Crypto digest API expects the full input buffer, which can cause memory pressure for videos. Incremental hashing requires a carefully reviewed library or a worker implementation. Do not freeze the main thread while presenting a “preparing” spinner.

For small photographs:

const bytes = await file.arrayBuffer();
const digest = await crypto.subtle.digest('SHA-256', bytes);

For large media, hash parts during transfer and compute or verify the final object digest on the server.

Part hashes are not automatically a file hash

Concatenating hexadecimal part hashes does not produce the SHA-256 of the complete file. A multipart storage ETag may also use a provider-specific algorithm. Document exactly what each field represents.

If the protocol verifies every numbered part and the server assembles them in a trusted order, part digests provide transfer integrity. A separate final digest can protect export and handover workflows.

Bind metadata to the digest

A digest by itself has no event, media ID, or algorithm context. Store it with the upload intent and immutable byte length. Include an algorithm version so future migrations do not reinterpret old values.

Do not use a raw digest as a public object key for private media. Someone who already has a common file can test for its presence. Keep identifiers random and authorization separate.

Handle mismatch safely

A mismatch should prevent acceptance and trigger a bounded retry or restart. Preserve a safe reason code and enough part-level evidence to diagnose network or implementation problems. Do not log file contents or signed URLs.

Repeated mismatches from one client version may indicate a hashing bug rather than hostile traffic. Compare across coarse browser and application versions.

Use digests for deduplication carefully

Server-side deduplication can save storage, but cross-event equality leaks information and complicates deletion. Prefer deduplication within one event or one owner boundary. Keep reference counts correct and ensure deleting one media record does not remove bytes still required elsewhere.

Perceptual hashes answer a different question and create additional privacy risks. They should not be introduced as a casual extension of byte-integrity checks.

Verify exports too

The digest recorded at acceptance can appear in an export manifest. The archive builder should hash the exact exported bytes and note when a derivative differs from the original. Recipients can then confirm download integrity.

I help build Gathmo and have a commercial interest in trustworthy media handling. The Gathmo company overview gives product context; these checksum boundaries apply to many upload and archive systems.

A checksum is valuable when its byte boundary, algorithm, storage, and failure behavior are explicit. It is evidence of equality—not a substitute for authorization, moderation, provenance, or consent.

Fairness and Backpressure in Real-Time Moderation Queues

Gathmo — Fri, 17 Jul 2026 18:47:39 +0000

A live event moderation queue can receive hundreds of uploads in a few minutes. Processing strictly in arrival order sounds fair, but a single guest sending large videos can delay photographs from everyone else. Unlimited parallelism creates the opposite problem: storage, scanning, and preview workers collapse together.

Separate pipeline stages

Use distinct queues for validation, malware scanning, metadata extraction, preview generation, and human review. Each stage has different resource costs and failure policies.

accepted -> validate -> scan -> derive -> reviewable -> approved

A file should carry a stable media ID and stage version so retries do not produce duplicate derivatives or repeated review entries.

Apply admission control

The control plane should limit active work per event and per contributor session. Admission control does not need to reject every excess upload; it can place the item in a durable waiting state and tell the browser that acceptance succeeded.

Distinguish “accepted but queued” from “processing.” This prevents the UI from showing a stalled progress bar while the system intentionally waits.

Schedule by cost class

Classify photographs, short audio, and video into coarse cost bands. Use weighted scheduling so small items continue to flow while expensive video jobs receive guaranteed capacity.

A simple pattern is separate queues with worker weights, for example six image slots, two audio slots, and two video slots. Revisit weights using observed processing time, not file count alone.

Prevent one contributor from dominating

Round-robin across contributor sessions or use a per-session concurrency cap. The organizer may also assign priority to official staff uploads, but that policy should be explicit and visible in audit records.

Do not use hidden device fingerprints to create fairness identities. An event-local random session is enough for rate and concurrency controls.

Propagate backpressure

When downstream scanning is saturated, upstream derivative workers should slow rather than writing millions of pending messages. Expose queue depth and oldest-item age. Scale on both values: depth alone can look healthy while one poisoned job waits for hours.

Set maximum retry counts and move deterministic failures to a dead-letter path with the media ID, stage, safe error code, and attempt history. Never include signed URLs or private captions in queue logs.

Design the moderator view

The human queue should not reorder itself under the moderator's cursor. Give each item a stable position or a clear “new items” boundary. Show media type, event-local context, processing state, and reason for any automated flag.

Actions must be idempotent. Two moderators approving the same item should converge on one state and produce an audit record, not two notifications.

Recover from worker loss

Use visibility timeouts or leases, renew them during long video work, and make each stage safe to retry. A worker crash after writing a preview but before acknowledging the job should detect and reuse the existing derivative.

Test burst behavior

Replay event-shaped traffic: many photos after a speech, a few large videos, and simultaneous moderator activity. Measure time to first reviewable item, p95 queue age by media type, duplicate work, and fairness across sessions.

I help build Gathmo and have a commercial interest in moderated event media. The Gathmo corporate workflow is one use case; these queue patterns apply to any bursty user-generated-content pipeline.

Backpressure is not a failure. It is the mechanism that preserves predictable service and fair progress when demand exceeds one stage's capacity.

Offline Recovery for Browser Uploads Without False Promises

Gathmo — Fri, 17 Jul 2026 18:47:24 +0000

“Works offline” is an attractive promise for an event upload page. In practice, a browser cannot send media without a network, may not retain a selected File after restart, and cannot rely on background execution across mobile platforms. A useful offline design is honest about those constraints.

Define what offline means

There are several different capabilities:

the page shell can open from cache;
selected-file metadata survives a temporary disconnect;
an in-progress chunk can retry when connectivity returns;
the full original file survives a page reload;
upload continues after the browser closes.

Do not group them under one badge. Test and document each supported behavior.

Cache only the application shell

A service worker can cache HTML, CSS, JavaScript, and static instructions. Avoid caching private album responses or signed upload URLs. Version the shell and provide a safe fallback when an old client talks to a new API.

self.addEventListener('fetch', event => {
  if (isStaticAsset(event.request)) {
    event.respondWith(cacheFirst(event.request));
  }
});

Event state should come from the network when available and fail closed when authorization cannot be checked.

Persist resumable metadata

IndexedDB can store upload IDs, committed parts, file size, type, and expiry. It usually cannot guarantee access to the original File after a restart. The interface should say “Reconnect to continue” for a live page and “Select the same file to resume” after a full restart.

Verify reselected files with name, size, modification time, and an optional partial fingerprint. Do not upload a different file into the old session merely because the filename matches.

Treat connectivity events as hints

online and offline events do not prove that the upload host is reachable. Captive portals, DNS problems, and blocked storage domains are common. Pause after repeated network failures and probe the control API with a bounded timeout.

When connectivity returns, fetch committed parts before resending. A response may have been lost while the server stored the bytes.

Be cautious with Background Sync

One-off Background Sync is not uniformly supported and may not run promptly. Passing large File objects from a closed page to a worker is especially unreliable. Use it as an optimization for small control messages, not as the only path for important media.

Keep the page awake only when the user has chosen to continue, and avoid hidden battery-draining loops.

Design the recovery UI

Show each file separately with states such as waiting for connection, ready to resume, needs re-selection, expired, or accepted. Preserve the guest's progress and explain the next action. A global red banner is less useful than per-file recovery.

If the event closes while offline, do not discard the local record immediately. Tell the guest to keep the original and offer the organizer's support route if appropriate.

Test real interruptions

Use airplane mode, a captive portal, screen lock, tab eviction, browser restart, and Wi-Fi-to-cellular transitions. Test on actual iOS and Android devices. Development tools that toggle “offline” do not reproduce mobile lifecycle behavior.

I help build Gathmo and have a commercial interest in resilient event uploads. The Gathmo no-app browser flow provides product context; the recovery principles here apply to other PWAs and upload tools.

A trustworthy offline experience never implies that bytes have left the phone when they have not. It preserves safe state, detects reconnection, reconciles with the server, and tells the user exactly what remains to do.

Polling, SSE, or WebSockets for Mobile Upload Status?

Gathmo — Fri, 17 Jul 2026 18:47:05 +0000

After the browser transfers a file, the server may still scan, transcode, extract metadata, or generate previews. The interface needs status updates, but the most fashionable real-time transport is not automatically the most reliable choice for an event guest on a mobile browser.

Start with the update contract

Define states and transitions before choosing transport:

accepted -> queued -> processing -> ready
accepted -> rejected
processing -> processing_error

Every status response should include a monotonically increasing version or timestamp. The client can ignore events older than the state it already knows.

Polling is a strong baseline

HTTP polling works through proxies, resumes naturally after a page wake, and is easy to cache and rate-limit. Use adaptive intervals: one second just after acceptance, then back off to several seconds when processing takes longer.

const delay = Math.min(8000, 1000 * 2 ** slowChecks);

Add jitter when many guests finish at the same time. Stop when the state is terminal, the page is gone, or a server-provided retry time says to wait longer.

SSE fits one-way progress

Server-Sent Events are attractive when the server only pushes status. The browser reconnects with a last-event ID, and the wire format is simple. But mobile networks and some intermediaries silently kill idle connections.

Send occasional heartbeats and treat reconnection as normal. The reconnect handler must fetch current state because events may have been missed beyond the server replay window.

Do not keep one SSE stream per file. Subscribe by guest session or album and filter authorized upload IDs on the server.

WebSockets add more responsibility

WebSockets make sense when the client also sends frequent commands over the same channel or when a host moderation console needs many rapid updates. For a guest waiting on two files, they add connection authentication, heartbeat, reconnect, replay, and load-balancer complexity without much user benefit.

Never rely on the socket as the only source of truth. A reconnect must reconcile through an HTTP status endpoint.

Design transport fallback

The client can prefer SSE and fall back to polling after repeated disconnects. Keep state semantics identical across transports. A UI component should consume normalized status events, not know whether they came from HTTP or a stream.

statusStore.apply({uploadId, version, state, progress});

This also makes automated tests easier.

Respect background behavior

Browsers throttle timers and may suspend connections when the screen locks. Pause aggressive polling when hidden, but perform an immediate status fetch on visibility change. Do not display a failure merely because no event arrived while suspended.

Protect authorization

A status channel can leak filenames, processing details, or other guests' uploads. Authenticate every subscription, scope it to allowed IDs, and avoid putting access tokens in URLs that appear in logs. Recheck authorization during long-lived connections.

Measure the right outcome

Compare time from server state change to visible UI update, reconnect frequency, requests per completed upload, and battery/network cost. A persistent connection with constant failures is not more “real time” than two-second polling.

I help build Gathmo and have a commercial interest in upload UX. The Gathmo browser workflow is one example where processing status matters; the transport tradeoffs are platform-neutral.

For most guest upload pages, reliable polling is the reference implementation. Add SSE when it measurably improves latency or load, and choose WebSockets only when bidirectional behavior justifies the operational surface.

Designing Upload Expiration as a Recoverable State

Gathmo — Fri, 17 Jul 2026 18:46:49 +0000

Signed upload sessions expire. Event contribution windows close. Storage reservations are reclaimed. These are normal lifecycle events, but many interfaces reduce all of them to “Upload failed.” A better protocol makes expiration explicit and recoverable where policy allows it.

Distinguish three clocks

An upload workflow usually has at least three deadlines:

the event contribution window;
the server-side upload intent expiry;
the short-lived storage credential expiry.

They should not share one timestamp. The event may accept contributions until midnight while a credential lasts five minutes and an intent can be renewed for an hour.

Return the clocks in the session response with server time:

{"serverNow":"2026-07-17T18:00:00Z","eventClosesAt":"2026-07-18T00:00:00Z","intentExpiresAt":"2026-07-17T19:00:00Z","credentialExpiresAt":"2026-07-17T18:05:00Z"}

The client can display useful warnings without trusting its own clock for authorization.

Model expiration by state

A credential expiring during transfer is different from an intent expiring before completion. Use stable reasons:

credential_expired -> request renewal
intent_expired -> reconcile committed parts, then renew or restart
event_closed -> stop new work, preserve local recovery guidance

Do not automatically restart from byte zero. First ask the control plane which parts were committed and whether the original object key remains valid.

Renew narrowly

A renewal endpoint should accept the upload ID and prove continuity with the guest session. It rechecks event state, file policy, rate limits, and committed size. The response returns a new credential for the same object.

Do not let the browser extend an intent indefinitely. Define a maximum session age and a bounded number of renewals. Long uploads may receive a larger initial policy based on file size and observed throughput.

Handle the closing boundary fairly

Decide what happens to an upload already transferring when the event window closes. Reasonable policies include a grace period for active sessions or a strict cutoff for sensitive events. Document the choice and apply it on the server.

The UI should say “The upload window closed while this file was transferring” rather than suggesting a network error. If local retry later is impossible, tell the guest to keep the original and contact the host.

Avoid timer-driven corruption

Client timers are advisory. Background tabs throttle JavaScript, devices sleep, and clocks change. Never delete server state merely because a browser timer fired. Each request is authorized against server time.

When the page returns from the background, refresh status before continuing. The last part may have completed even though its response never reached the page.

Preserve user intent

Keep safe local metadata about files that need attention: upload ID, event ID, filename, size, and last known committed parts. Do not persist storage credentials. If the File object cannot survive a restart, ask the user to reselect the same file and verify basic attributes before resuming.

Test every boundary

Use fake clocks to test expiry immediately before a part begins, during a response timeout, after all parts but before completion, and while the page is hidden. Verify the displayed message and final server state.

I help build Gathmo and have a commercial interest in reliable event uploads. The Gathmo help centre provides product-specific recovery guidance; the expiration model here can be used in any resumable upload system.

Expiration is not an exceptional crash. It is a state transition with policy, evidence, and a recovery path.

Integrity Manifests for Event Album Exports

Gathmo — Fri, 17 Jul 2026 18:42:46 +0000

An event album export is usually treated as a zip file and a success toast. That is not enough for a handover containing hundreds of photographs, videos, and voice messages. The recipient needs evidence that the package is complete, readable, and tied to a specific export request.

Define the export boundary

Capture the event identifier, export request ID, creation time, selection rule, media states included, and requester role. An export of “approved media only” is different from an administrative archive containing removed or pending items.

Freeze the selection at a consistent point. If uploads continue while the archive is built, either use a database snapshot or state clearly which cutoff timestamp applies.

Create a machine-readable manifest

Include one entry per file:

{"path":"photos/IMG_1042.jpg","mediaId":"m_8f2","bytes":4821931,"sha256":"...","uploadedAt":"2026-07-17T12:10:00Z","state":"approved"}

Use stable internal media IDs, not contributor contact details. Add the original filename only if the product promises to preserve it and the recipient needs it.

Hash the bytes you deliver

Compute the checksum from the exact exported object, after any transformation. If the archive contains an original and a display derivative, list both separately. A hash stored only in an internal database does not prove the downloaded bytes match.

For very large exports, stream each object through the hash function while writing the archive. Avoid loading files into application memory.

Make partial failure visible

Do not quietly skip an unavailable object. Mark the export failed or include an explicit error section that prevents the UI from claiming completeness. Retry transient storage reads with bounded backoff, then preserve the failure reason for the operator.

The archive builder should be idempotent. Repeating the same request may create a new package, but its selection and manifest should remain comparable.

Sign or anchor the manifest

A server-side signature over the canonical manifest can show that it was produced by the service and not modified during handover. Key rotation requires a key identifier and a public verification procedure. For lower-risk use, storing the manifest hash in the audit log may be sufficient.

Do not oversell a checksum. It proves byte integrity, not consent, authorship, or legal ownership.

Verify before announcing success

After upload to the delivery location, read the archive footer, parse the manifest, and open a sample from every media type. Compare file count and total bytes with the frozen selection. Only then mark the export ready.

Use a short-lived download link scoped to one package. Export authority should not grant album administration or access to future packages.

Help the recipient verify

Include a small README with the event label, cutoff, file count, total size, manifest format, and checksum command. Nontechnical recipients still benefit from a clear statement of what is present and what was excluded.

I help build Gathmo and have a commercial interest in reliable media handovers. The Gathmo help centre provides product-specific guidance; the manifest approach works for any service that exports user media.

A trustworthy export is not merely downloadable. It is defined, reproducible, checked, and accompanied by evidence that the bytes handed over are the bytes the system selected.

Threat Modeling Share Links for Private Event Albums

Gathmo — Fri, 17 Jul 2026 18:42:28 +0000

A private event album often uses a share link because guests will not create accounts. That improves participation and moves the security boundary into the URL. The design must assume links are copied into group chats, photographed from signs, saved by browser history, and opened on shared devices.

Identify the assets and actors

Assets include original media, captions, contributor names, voice messages, moderation state, and export archives. Actors include invited guests, the host, suppliers, accidental recipients, automated scanners, and a person who receives an old device.

“Anyone with the link” is not an actor definition. It is an authorization rule with predictable leakage paths.

Separate upload and viewing authority

A QR code displayed in a venue may need to permit contribution without granting access to every existing file. Use distinct capabilities for upload, gallery viewing, moderation, and export. If one link does everything, a photograph of the sign becomes an administrator credential.

Capability tokens should be random, long enough to resist guessing, and stored hashed where practical. Avoid meaningful event names or sequential IDs as the secret part of the URL.

Plan for referrer leakage

If an album page loads third-party images, analytics, or outbound links, the full URL can appear in a Referer header unless policy prevents it. Set a restrictive referrer policy and keep capability tokens out of query strings used by third-party scripts.

Do not place secrets in page titles, Open Graph metadata, or client-side error reports. Messaging previews may fetch and cache those fields automatically.

Treat scanners as normal traffic

Email security products and chat applications may open links before a person does. A GET request must not consume a one-time capability, approve an action, or close an event. State changes require an explicit, protected request.

Rate limiting should tolerate harmless preview fetches while still detecting enumeration and high-volume scraping.

Add host-controlled rotation

The host needs to rotate a leaked share link without deleting the album. New tokens should become active immediately, and old ones should expire after a deliberate overlap or at once for an incident.

Record which printed materials and scheduled messages contain the old code. Rotation without an inventory can lock out legitimate guests or leave the compromised route in circulation.

Reduce exposure on shared devices

Avoid long-lived authentication in local storage for public guest links. Offer a clear sign-out or “forget this album” action when viewing authority is stronger than upload authority. Sensitive albums may require an additional event code that is not printed next to the QR symbol.

Browser history is difficult to control. Keep route names neutral and avoid rendering sensitive thumbnails before access is established.

Model closure and deletion

An event end date should change authorization behavior. Upload authority can close while view access remains for review. Export links should be short-lived and independently revocable. Deleted media should disappear from derivatives and caches, not only the database row.

Test the uncomfortable paths

Copy the link into a different browser profile, open it through a messaging preview, inspect network referrers, attempt old tokens after rotation, and load cached image URLs after removal. A threat model becomes useful when it produces tests.

I help build Gathmo and have a commercial interest in this area. The Gathmo product principles provide context for our approach, but the share-link threats described here are common to many private collaboration tools.

A share link is a credential. Design its scope, lifetime, leakage controls, rotation, and evidence with the same care as any other authorization mechanism.

Privacy-Preserving Telemetry for Guest Upload Pipelines

Gathmo — Fri, 17 Jul 2026 18:42:02 +0000

An upload system needs observability. Operators must know whether failures happen during selection, transfer, acceptance, or processing. The easy implementation sends every filename, event identifier, IP address, browser fingerprint, and retry to an analytics vendor. That produces a detailed dashboard and an unnecessary privacy liability.

Begin with operational questions

Write the questions before choosing events:

What percentage of upload intents become accepted files?
Where does time accumulate?
Which coarse browser families fail more often?
How many bytes are retransmitted?
Are processing failures isolated to one media type?

None of these requires a persistent identity that follows a guest across events.

Use an event-local session

Generate a random telemetry session for the current event and browser visit. Rotate it when the upload page is reopened after a reasonable interval. Do not join it to marketing cookies or another event.

An upload ID may appear in both control-plane logs and client events, but it should be random and scoped. Store the mapping to the actual object only where operations require it, with stricter access and retention.

Define a small event vocabulary

Avoid arbitrary log messages. Use structured stages:

{"stage":"part_transfer","result":"timeout","attempt":2,"sizeBucket":"5-10MB","network":"cellular"}

Bucket sizes, durations, and network types. Exact values can make rare combinations identifying and rarely improve a reliability decision.

Keep content out of telemetry

Do not send filenames, captions, album names, raw error bodies, signed URLs, or media metadata by default. Error objects often contain request URLs with credentials. Build an allowlist serializer instead of spreading the browser error into an analytics payload.

Server logs should redact authorization headers and query signatures before storage. Confirm redaction with automated tests, not only configuration promises.

Separate product analytics and incident evidence

Aggregate funnel metrics can use short retention and coarse dimensions. Security or abuse investigations may justify more detailed evidence for a limited case. Keep those systems separate, require an incident reason, and log access.

A single enormous analytics table tends to retain the most sensitive field for the longest policy.

Design deletion and expiry

Set retention per data class. Raw client events may need days, aggregated reliability metrics months, and security evidence a case-specific schedule. Expiry should be enforced by storage lifecycle rules and tested with sample records.

If an event owner requests deletion, know which operational records can be removed and which minimal security records must remain. Document this distinction in plain language.

Detect failure without fingerprinting

Browser family, major version, coarse device class, and feature support are usually enough. Prefer capability flags such as supportsCreateImageBitmap or supportsReadableStreamUpload over a high-entropy fingerprint.

Sample successful flows and retain all rare failure categories only after removing sensitive fields. This reduces cost and limits unnecessary collection.

Make dashboards honest

An accepted upload is not a ready asset. Show separate rates for server acceptance and successful processing. Distinguish user cancellation from technical failure. Record when the page disappears without inferring that the guest intentionally abandoned the contribution.

I help build Gathmo and have a commercial interest in privacy-aware event systems. The Gathmo company overview provides product context, while this telemetry model can be applied to other upload services.

Observability is strongest when every field answers a real operational question. If a value is merely interesting, remove it. Smaller telemetry is easier to secure, easier to explain, and often easier to use.

Memory-Safe Media Preflight in Mobile Browsers

Gathmo — Fri, 17 Jul 2026 18:41:30 +0000

Client-side media preflight can improve an upload experience, but it can also crash the page before the network request begins. A twelve-megapixel JPEG may be only four megabytes on disk and tens of megabytes after decoding. Creating several full-size canvases at once is enough to exhaust memory on older phones.

Preflight is policy, not editing

Decide what the browser must prove before transfer. Useful checks include file count, compressed byte size, declared type, readable dimensions, and a conservative duration limit for video. Avoid mandatory re-encoding unless the product truly needs it. Every transformation adds CPU time, memory pressure, battery use, and another failure mode.

Process one file at a time

A file picker may return twenty items. Do not decode all of them to build previews. Maintain a queue with one active decode on constrained devices and at most two on stronger ones.

for (const file of files) {
  const result = await inspect(file);
  renderResult(result);
  await yieldToMainThread();
}

The UI can list filenames immediately while dimensions and thumbnails arrive progressively.

Prefer metadata over full pixels

Use createImageBitmap with resize hints when supported. It can decode away from the main rendering path and avoid a full-resolution canvas for a small preview.

const bitmap = await createImageBitmap(file, {
  resizeWidth: 640,
  resizeQuality: 'medium'
});

Always close bitmaps after drawing. Revoke object URLs when the component unmounts. Small leaks become large when guests select and remove files repeatedly.

Handle orientation and color carefully

Modern browsers generally honor EXIF orientation when decoding, but behavior differs across APIs and older engines. Test portrait photographs from real iOS and Android devices. Do not strip metadata silently if the original is supposed to remain untouched; upload the source file and treat the preview as disposable UI.

Color differences between the preview and exported original are usually less harmful than a destructive client-side conversion. Be explicit about whether the product preserves originals.

Video needs different limits

Reading a complete video into an ArrayBuffer simply to inspect duration defeats streaming. Create a temporary media element from an object URL, wait for metadata, then release it. Add a timeout because damaged files may never emit the expected event.

Do not generate multiple video thumbnails concurrently on mobile. Seek operations can trigger additional decoding and large temporary buffers.

Survive cancellation

Every preflight task needs an abort path when the user removes a file, picks a replacement, navigates away, or the event closes. Use an AbortController for your own async boundaries and check the signal between decode stages.

Report errors per file. One unreadable image should not discard nineteen valid contributions. Use specific messages: unsupported type, file too large, video too long, or preview unavailable but upload permitted.

Measure without collecting filenames

Track coarse outcomes such as decoded, rejected by size, preview timeout, and out-of-memory page recovery. Filenames and media contents are unnecessary for operational metrics.

I help build Gathmo and therefore have a commercial interest in reliable browser media handling. The Gathmo help centre describes product-specific behavior; the memory rules here apply to any mobile upload interface.

A good preflight pipeline is intentionally modest. It validates what the server needs, produces a small preview, releases resources promptly, and never risks the original merely to make the interface look faster.

Short-Lived Upload Credentials Without Giving the Browser Too Much Power

Gathmo — Fri, 17 Jul 2026 18:40:44 +0000

A guest upload page sits in a hostile place: an unauthenticated browser, often opened from a photographed QR code, on a network the event organizer does not control. The browser needs enough authority to send one file to one event. It should not receive a reusable credential that can list albums, read other media, or write forever.

Start with an upload intent

Create a server-side intent before issuing storage access. The request contains only information needed for policy checks:

{"eventId":"evt_123","uploadId":"client-uuid","size":7340032,"type":"image/jpeg"}

The server verifies that the event accepts contributions, the type and size are allowed, and the rate limit has room. It then stores an intent with an expiry and expected object key. A retry with the same event and upload ID returns the same intent rather than allocating a second object.

Scope the credential to one object

A signed request should bind the HTTP method, object key, content length range, media type, and a short expiry. Do not sign a bucket prefix if the client only needs one object. Do not return cloud credentials that can be refreshed independently.

Five minutes is often enough for a photograph but not for a large video on congested venue Wi-Fi. Instead of increasing every expiry, let the control API renew an active intent after checking how much progress was made. Renewal should not change the destination key.

Separate bytes from acceptance

A successful storage upload does not mean the application accepted the contribution. The browser should call a completion endpoint that verifies object existence, byte length, checksum when available, and intent state.

created -> transferring -> stored -> accepted -> processing -> ready

The completion call must be idempotent. If the response disappears during a network switch, the next call should return the already accepted state.

Prevent confused-deputy mistakes

Never let the client choose an arbitrary final object key. Derive it from trusted event and upload identifiers. Normalize the declared type, but verify the actual file signature during processing. A file named photo.jpg can still contain another format.

Keep organizer operations on a separate authorization path. A guest token must not become valid for deletion, moderation, export, or album settings simply because those endpoints share a domain.

Make abuse limits explicit

Apply limits at intent creation and completion: requests per network range, active intents per event, total bytes, and file count. Return a stable reason such as event_closed, type_not_allowed, or capacity_reached so the UI can explain what happened without revealing internal infrastructure.

Log credential issuance by event and intent, not by a persistent cross-event guest identity. Retain enough evidence to investigate abuse while avoiding a new tracking system.

Rotate signing keys safely

Include a key identifier and accept the previous verification key during a short overlap. Rotation should not invalidate every upload already in progress. Emergency revocation is different: the control plane may mark an event or intent closed even when a storage signature has not yet expired, and completion must respect that state.

I help build Gathmo and have a commercial interest in this problem. The Gathmo corporate event workflow is one context where scoped browser uploads matter, but the credential design is platform-neutral.

The core rule is simple: give the browser authority for one narrow action, for one narrow object, for one short period. Everything else belongs behind the application control plane.

Resumable Browser Uploads for Crowded Event Networks

Gathmo — Fri, 17 Jul 2026 18:35:04 +0000

Event uploads fail differently from normal office uploads. A wedding guest may move between venue Wi-Fi and mobile data, lock the phone while a video is transferring, or close the browser as soon as the progress bar reaches 100%. Hundreds of devices can share one access point, and users rarely wait around to diagnose an error.

The usual POST request plus optimistic success toast is not enough. A reliable browser flow needs a small protocol that distinguishes local preparation, network transfer, server acceptance, media processing, and final availability.

This article describes a platform-neutral design for that protocol.

The five states users actually experience

Model each file as a durable state machine:

selected
  -> preparing
  -> transferring
  -> accepted
  -> processing
  -> ready

Add terminal or recoverable branches:

preparing    -> rejected_local
transferring -> paused | retryable_error | expired
accepted     -> processing_error
processing   -> ready | processing_error

The key distinction is between transferring and accepted. The browser may have sent every byte while the server has not yet committed the upload. Showing “done” at that boundary creates the most frustrating failure: the guest deletes the original, but the organizer never receives it.

Give every file a client-generated identity

Create an upload ID before the first network request. A UUID is sufficient when combined with the event identifier:

const uploadId = crypto.randomUUID();

const uploadIntent = {
  uploadId,
  eventId,
  name: file.name,
  size: file.size,
  type: file.type,
  lastModified: file.lastModified,
};

Send that identity when creating the server-side upload session. If the browser retries after a timeout, the server returns the existing session instead of creating a duplicate.

This is idempotency at the workflow level. A guest can tap “retry” without having to understand whether the first request reached the server.

Separate the control plane from file bytes

Use a small JSON API for session creation and status, then transfer bytes through a resumable object-storage protocol or chunk endpoint.

POST /events/:eventId/upload-sessions
PUT  /upload-sessions/:uploadId/parts/:partNumber
POST /upload-sessions/:uploadId/complete
GET  /upload-sessions/:uploadId/status

The create response should include:

the canonical upload ID;
part size;
expiry time;
already committed parts;
limits and accepted media types;
a short-lived upload credential;
the status polling URL.

Do not expose permanent storage credentials or organizer privileges to a guest browser.

Choose chunks for mobile recovery, not maximum throughput

Very small parts add request overhead. Very large parts make every interruption expensive. For event photos and short videos, starting around 5–10 MB per part is often a sensible compromise, but the server should be able to adjust by file size and network observations.

Limit concurrency on mobile devices:

const maxConcurrentParts = navigator.connection?.saveData ? 1 : 2;

More parallel requests can reduce throughput on a congested access point. Two predictable streams are often better than eight competing streams.

Persist only metadata that is safe to persist

Store the upload session metadata in IndexedDB so a page reload can recover state:

await db.put('uploads', {
  uploadId,
  eventId,
  name: file.name,
  size: file.size,
  committedParts,
  expiresAt,
  state: 'transferring',
});

Browsers cannot always reopen the original File object after a restart. The UI must say so honestly: “Select the same video to resume.” Compare name, size, modification time, and optionally a lightweight fingerprint before attaching the new file handle to the existing session.

Do not persist private event administration links, access tokens with long lifetimes, or unnecessary media metadata.

Treat network changes as normal

navigator.onLine is only a hint. A device can be online while a captive portal blocks the upload host. Use request outcomes and timeouts as the source of truth.

Pause exponential backoff when the page is hidden, but do not cancel a part that is already close to completion. Add jitter so hundreds of guests do not retry at the same instant after venue Wi-Fi recovers:

function retryDelay(attempt) {
  const base = Math.min(30_000, 1_000 * 2 ** attempt);
  return base / 2 + Math.random() * (base / 2);
}

After switching networks, query committed parts before resuming. The last response may have been lost even though the server stored the part.

Confirm server acceptance explicitly

The completion endpoint should verify the part set, expected byte count, content constraints, and checksum where available. It returns an accepted state only after the durable object exists.

{
  "uploadId": "…",
  "state": "accepted",
  "receivedBytes": 48277123,
  "processingStatusUrl": "/upload-sessions/…/status"
}

The browser can now tell the guest that the original is safely received. Processing may still generate previews, normalize video, scan content, or place the item into moderation.

Design the confirmation screen for impatient humans

A useful confirmation has three layers:

Received — the server has the original.
Preparing — previews or video processing are still running.
Available — the organizer workflow can use the item.

Never use only color. Include text, an icon, and a stable upload ID that support can reference. Let the guest add another item without losing the completed receipt.

In an app-free event workflow such as Gathmo's browser upload flow, that clarity matters because a guest may interact with the product only once. There is no installed app to send a later recovery notification.

Protect the event from abandoned sessions

Upload sessions need expiry and cleanup:

short-lived credentials;
a maximum number of active sessions per guest or network;
server-side size and type validation;
cleanup of incomplete multipart objects;
rate limits that tolerate retries;
an abuse path that does not block legitimate crowded-event traffic.

Keep accepted originals separate from uncommitted parts. Cleanup jobs must never infer abandonment from a missing browser heartbeat after acceptance.

Observability without tracking guests

Operational metrics can remain privacy-preserving:

sessions created;
acceptance rate;
median attempts per part;
bytes retransmitted;
time from selection to acceptance;
time from acceptance to ready;
failure reason by browser and coarse network type;
duplicate intents merged by idempotency key.

Avoid storing full filenames, precise IP history, or persistent cross-event identifiers in analytics when aggregates are enough.

Test the failure boundaries

The happy path is the least interesting test. Automate and rehearse:

timeout after the server commits a part but before the browser receives the response;
refresh midway through a transfer;
captive portal redirect;
Wi-Fi-to-mobile transition;
expired upload credential;
duplicate completion request;
file re-selection with the wrong file;
processing failure after acceptance;
event upload window closing during transfer;
browser closure immediately after the last progress event.

For every test, assert both server state and user-visible wording.

The reliability contract

A reliable event upload flow makes four promises it can prove:

Retry does not create accidental duplicates.
“Received” means the server durably accepted the original.
The guest can recover from common mobile-network interruptions.
The organizer can distinguish transferring, accepted, processing, and ready media.

That contract is more valuable than a perfectly smooth progress animation. Event guests forgive a brief retry. They do not forgive a success message for a file that never arrived.

Designing an idempotent confirmation protocol for browser uploads

Gathmo — Wed, 15 Jul 2026 16:34:46 +0000

A direct-to-object-storage upload removes the application server from the byte path, but it creates a subtle distributed-systems problem at the end of the flow.

The browser can finish uploading the object, send a confirmation request to the API, and lose connectivity before receiving the response. From the user's perspective the result is ambiguous: did the server create the media record, or should the browser try again?

If the confirmation endpoint is not idempotent, retrying can create duplicate records. If the client refuses to retry, a successfully stored object can remain invisible to the application. The protocol needs a stable identity that survives network uncertainty.

Model the upload as two durable operations

The first operation stores bytes. The second operation creates or returns the canonical application record.

browser -> API: authorize attempt
API -> browser: attempt ID, object key, signed upload URL
browser -> storage: transfer bytes
browser -> API: confirm attempt ID and object metadata
API -> browser: canonical media record

The attempt ID is generated once and reused for every confirmation retry. It must not be regenerated when a request times out.

Give the attempt a server-owned scope

A random UUID is useful, but identity alone is not authorization. The authorization response should bind the attempt to the authenticated or temporary guest session, the target event, the expected object key, and relevant constraints such as maximum size or content family.

A minimal record might contain:

type UploadAttempt = {
  id: string;
  eventId: string;
  contributorSessionId: string;
  objectKey: string;
  state: "authorized" | "confirmed" | "rejected";
  createdAt: string;
  confirmedMediaId?: string;
};

The confirmation endpoint looks up this record rather than trusting event or object identifiers supplied again by the browser.

Make confirmation return the existing result

The endpoint should behave like a create-or-return operation.

async function confirmUpload(attemptId: string, input: ConfirmInput) {
  return database.transaction(async (tx) => {
    const attempt = await tx.uploadAttempts.lockForUpdate(attemptId);

    if (attempt.state === "confirmed") {
      return tx.media.findById(attempt.confirmedMediaId);
    }

    assertAttemptBelongsToSession(attempt);
    const storedObject = await inspectStoredObject(attempt.objectKey);
    validateObject(storedObject, input);

    const media = await tx.media.create({
      eventId: attempt.eventId,
      objectKey: attempt.objectKey,
      size: storedObject.size,
      contentType: storedObject.contentType,
      moderationState: "pending",
    });

    await tx.uploadAttempts.markConfirmed(attempt.id, media.id);
    return media;
  });
}

The transaction and uniqueness constraints matter. Two confirmation requests can arrive concurrently after a client retry or double tap. A row lock or compare-and-set transition ensures that only one media record wins.

Do not use the object key as the only idempotency key

Object keys are storage addresses, not necessarily user-intent identifiers. A multipart retry, a replacement workflow, or an administrative recovery may reuse or transform storage paths.

An explicit attempt record gives the application a place to store authorization context, expiry, confirmation state, and the canonical result. It also makes abandoned-object cleanup safer because the system can distinguish an authorized but unconfirmed object from an unrelated storage file.

Reconcile after the browser returns

Persist lightweight attempt metadata in IndexedDB or another durable client store:

attempt ID;
object key;
filename and size;
last known client state; and
timestamps.

On page restore, query the API for each non-terminal attempt. The server response should distinguish at least:

authorized: storage or confirmation may still be incomplete;
confirmed: return the canonical media record;
expired: the client needs a new authorization; and
rejected: show a terminal explanation.

The browser should not infer failure merely because it never received the original response.

Separate upload success from moderation success

Confirmation means the application accepted the media record. It does not mean the item is approved for public display. Returning a separate moderation state avoids the common UX bug where guests retry a successful upload because it has not appeared on a live wall.

The same separation is useful in the browser-based event contribution flow used by Gathmo: transfer, canonical confirmation, and visibility are different states even when the happy path feels like one action.

Test the ambiguous moments

The most valuable protocol tests deliberately interrupt the flow:

Drop the response after the server commits confirmation.
Send the same confirmation twice concurrently.
Retry after the signed upload URL expires but the object already exists.
Confirm an object whose size or content type differs from authorization.
Restore the browser after confirmation completed on another device.
Run cleanup while a confirmation transaction is in flight.

A reliable upload protocol is not one that never encounters ambiguity. It is one that can answer the same question repeatedly and return the same durable result.