[Bug] All media uploads fail with "TauriInvokeError: relay returned 401 Unauthorized: authentication failed"

[kisner1a-glitch]

What I did:
Tried uploading images in two separate contexts:

Setting a new profile avatar (Settings → Identity → avatar upload)
Attaching an image to a chat message (paperclip icon in message composer)

Expected result:
Image uploads successfully in both cases.

Actual result:
Both fail immediately with: TauriInvokeError: relay returned 401 Unauthorized: authentication failed

Steps to reproduce:

Open Buzz Desktop, go to any channel
Click the paperclip/attach icon in the message composer
Select an image
Error appears: TauriInvokeError: relay returned 401 Unauthorized: authentication failed
Same error reproduces when uploading via Settings → avatar

Troubleshooting already tried (ruled out):

System clock is set to auto-sync — not a clock drift issue
No VPN/proxy in use — not a network routing issue
(add here if you also tried logging out/rejoining the community)

Environment:

Buzz version: (fill in — Settings → About)
OS: (Windows/macOS/Linux + version)
Community: self-hosted or buzz.xyz hosted?

Evidence:
(attach both screenshots — avatar upload + chat attachment)

[iroiro147]

The deliberately-opaque "authentication failed" string is 13 distinct MediaError variants collapsed into one 401 response (oracle-enumeration protection in buzz-media/src/error.rs). The actual error is logged server-side by a matching tracing::warn!(error = %self, "authentication failed") line. To make this actionable we need that one line from your relay logs at the moment of the failed upload — it contains the real MediaError variant (e.g. TokenExpired, ServerMismatch, InvalidSignature, TimestampOutOfWindow). If you don't have relay access (buzz.xyz hosted), the desktop's own debug logs around sign_blossom_upload_auth / do_upload would show whether the auth header was even minted. Could you grab one of those?

[gabmichels]

Reporter here — I have the answer to @iroiro147's question, obtained without relay log access.

The variant is TimestampOutOfWindow. The root cause is client-side clock skew, not anything wrong with Buzz.

How I isolated it without server logs

Since the 401 is deliberately opaque, I bisected the one input I could control. I hand-signed a valid Blossom kind:24242 upload auth event against the relay and varied only created_at, holding everything else constant:

created_at offset    0s  ->  401 authentication failed
created_at offset  -10s  ->  200 OK (uploaded)
created_at offset  -20s  ->  200 OK
created_at offset  -30s  ->  200 OK

A signature/scope/server-tag failure would fail at every offset. Only created_at moved, so only a created_at check could be rejecting it.

That points at crates/buzz-media/src/auth.rs:

// 5. created_at must be recent: not in the future (5s tolerance) and not
//    older than 10 minutes.
let created = auth_event.created_at.as_secs();
if created > now + 5 {
    return Err(MediaError::TimestampOutOfWindow);
}

Confirming the skew

> w32tm /stripchart /computer:time.windows.com /samples:2 /dataonly
14:23:27, -06.7541041s
14:23:29, -06.7549910s

> sc query w32time
STATE           : 1  STOPPED
WIN32_EXIT_CODE : 1077  (0x435)     # never started since boot
START_TYPE      : 3   DEMAND_START

My machine was ~6.75s ahead of NTP because the Windows Time service was stopped and the clock had been free-running. 6.75 > 5, so every upload minted a token dated in the relay's future and was rejected. Starting w32time and resyncing fixes it.

This also explains the "it worked a few days ago, now it doesn't" shape of this bug — the drift crosses the 5s threshold at some point and uploads flip from always-working to always-failing, with no client change in between.

Suggested fix upstream

The opacity is doing real damage here: this is a user-fixable, non-Buzz problem presented as an authentication failure, which sends people to look for auth bugs. Two options, either would have saved the hunt:

1. Distinguish this one variant. TimestampOutOfWindow isn't an enumeration oracle in the way the other twelve are — it discloses nothing about blob existence, ownership, or authorization. It only tells the caller something about the caller's own clock, which any client can already derive from the HTTP Date header on any response from the relay. Returning a distinct code/reason for it looks safe under the same threat model that motivates collapsing the rest.
2. Client-side pre-flight. Have the desktop compare local time against the Date header before minting the token, and surface "your system clock is Ns ahead — media uploads will fail" instead of a bare 401. This needs no relay change at all.

Happy to open a PR for (2) if that's the preferred direction.

[iroiro147]

@gabmichels This is a better piece of debugging than the question deserved, and I owe you an apology for the delay in saying so — a week of silence after you did the work is not the trade I intended.

Verified your reading against main. crates/buzz-media/src/auth.rs:102 is if created > now + 5 { return Err(MediaError::TimestampOutOfWindow) }, and error.rs:127 is where that variant joins the collapse into a bare 401. Your bisect is the part worth highlighting: varying only created_at and showing 0s fails while −10s succeeds rules out signature, scope and server-tag in one move, because those fail at every offset. That is a cleaner isolation than the relay log I asked for would have given you, and it needed no access at all.

The 6.75s free-running clock with w32time in STOPPED / 1077 explains the reported shape exactly — including "it worked a few days ago", which drift produces and a code bug does not.

On your two options, I think (2) is the right one, and (1) is worth raising as well, for different reasons.

(2) is the fix with no downside: no relay change, no threat-model argument, and it catches the problem at the only place that can act on it. Comparing local time against the Date header before minting is a few lines, and "your system clock is 6.7s ahead — media uploads will fail" turns a dead end into a self-service fix.

(1) I would frame narrowly, because the collapse exists for a real reason. Your argument is the strongest available: TimestampOutOfWindow is not an enumeration oracle like the other twelve — it discloses nothing about blob existence, ownership or authorization, only something about the caller's own clock, which the Date header already reveals on any response. That is a genuine asymmetry rather than a request to weaken the policy, and it is worth stating in exactly those terms.

Please do open the PR for (2) — it should be yours. You found it, isolated it, and proposed it; I am not going to take that. Happy to review, or to say the above on the PR so the security framing for (1) is on the record from someone other than the person proposing it.

One caveat worth putting in the description: skew goes both ways and the tolerances are asymmetric — 5s fast versus max_age_secs slow. A pre-flight that only warns on "ahead" would miss a badly-behind clock tripping the second branch at auth.rs:105.

[odedlaz]

Adding an iOS occurrence and a direct calibration of the boundary, measured against a running relay on 2026-09-22.

@gabmichels' bisect is the diagnosis and this doesn't displace it — but it was reached by varying created_at and reading success/failure, so it's worth confirming the bound by a second route that can't be confounded by anything else in the request.

Calibrating the window with the 403/401 split

I signed kind:24242 upload tokens against a self-hosted relay, varying only created_at, every other tag identical to the mobile builder (mobile/lib/shared/relay/media_upload.dart). The host clock was anchored at +0.087 ±0.063 s against time.apple.com via sntp at the time of the run.

created_at	HTTP	Body
now +0s	403	relay membership required
now +4s	403	relay membership required
now +6s	401	authentication failed
now +10s / +26s / +60s	401	authentication failed

The 403 is the useful part, not noise. On the upload route the pre-body Blossom check (crates/buzz-relay/src/api/media.rs:177) runs before the membership gate (media.rs:211), so a 403 proves the token was accepted and a 401 proves it was rejected. That turns the opaque 401 into a two-sided boundary probe without needing relay logs. Live boundary is created_at > now + 5 → reject, matching crates/buzz-media/src/auth.rs:102 exactly. That first check is also why no blob was stored and no body was buffered: the timestamp bound is enforced before the request body is read, and the per-type re-verification at crates/buzz-media/src/upload.rs:85 is never reached.

The iOS case, and why chat works while uploads don't

This issue reports desktop. The same bound breaks mobile, and there the skew is much larger: two of my own signed chat events were +25.5 s and +26.0 s ahead of relay receipt, from an iPhone with "Set Automatically" enabled. A PC on the same account measured −1 s.

That's ordinary: iOS takes time from the carrier (NITZ) on cellular rather than NTP, so tens of seconds of drift is unremarkable and invisible to the user.

The asymmetry is what makes it baffling in the field:

• NIP-42 connection auth tolerates ±60 s (crates/buzz-auth/src/nip42.rs:35)
• NIP-98 HTTP auth tolerates ±60 s (crates/buzz-auth/src/nip98.rs:32)
• Media auth tolerates +5 s (crates/buzz-media/src/auth.rs:102)

So a device 26 s fast authenticates its socket, sends and receives messages normally all day, and fails only on media. Everything works except the one thing, which reads as a media-service problem rather than a clock problem.

Two notes on the open PRs

#6929 — the diagnostic it adds is the right idea, but it lands in crates/buzz-cli, crates/buzz-core and desktop/src-tauri. There are no mobile files in it, so the iOS path above would still surface a bare authentication failed. Worth flagging since that PR is currently the one marked Closes #4075.

#7288 — it rewrites verify_blossom_auth_event_for_verb wholesale, and if created > now + 5 { appears in its diff as a context line, not an edit. The new comment block restates created_at <= now + 5s in both the Strict and Permissive arms, so the future bound survives the NIP-FI hardening in both modes. If widening it is wanted, that PR is already inside those exact lines.

A gap worth closing regardless of the fix

MediaError::TimestampOutOfWindow is asserted by no test. Across the whole tree it appears four times: the definition (error.rs:36), the HTTP-status arm (error.rs:133), and the two return Err sites (auth.rs:103, auth.rs:106). Every existing test in auth.rs signs at now. #7288 adds timestamp tests, but they cover the expiration window — none sign created_at in the future.

So the boundary that is actually breaking uploads in the field has never been exercised, before or after that PR. Four cases would cover it: accept at now + (limit − 1), reject at now + (limit + 1), accept at now − (max_age − 1), reject at now − (max_age + 1).

Suggestion

Widening the future tolerance to 60 s, to match the NIP-42 number the same client already has to satisfy, would let any device that can authenticate a connection also upload. The future side buys little replay protection the past side doesn't already provide — token lifetime is bounded independently by max_age_secs and by the expiration tag — so worst case for buffered uploads goes 600 s → 660 s.

Not claiming that's the only reasonable call; the measurement is the contribution, and the tolerance number is the maintainers'.