Blossom: the url a server returns is embedded into page content without a scheme check

[usekaneo]

From the CON-43 security audit (2026-09-14). Severity low — defence in depth, not an open hole.

src/nostr/blossom.ts:76-78:

const body: unknown = await response.json()
const descriptor = body as Record<string, unknown>
const url = typeof descriptor.url === 'string' ? descriptor.url : `${BLOSSOM_SERVER}/${hash}`

The only test is typeof … === 'string'. That string goes straight into attachmentMarkdown (blossom.ts:103-110) and is written into the page's Markdown as ![label](url). A Blossom server that answered {"url": "javascript:…"} would get that scheme into stored content.

Why it is low, and worth doing anyway

It does not become executable XSS: on render, the pipeline from finding A2 runs again — rehype-sanitize's protocol allowlist plus react-markdown's defaultUrlTransform — and both reject anything that is not http(s). And the Blossom server is operator-configured infrastructure (VITE_BLOSSOM_SERVER), not something an attacker supplies; anyone able to spoof it already has a bigger foothold than this app's code is defending against.

What makes it worth a small fix is the asymmetry right next to it. attachmentMarkdown is careful about the label — it strips [, ] and line breaks, with a comment explaining that a file called notes].md would otherwise end the link early and swallow the rest of the line. The url in the same template gets no equivalent care, even though a ) in it truncates the link exactly the same way. The file already knows this class of problem; it just handles one half of it.

Task

• Accept descriptor.url only if it parses as an absolute http: or https: URL; otherwise fall back to the deterministic ${BLOSSOM_SERVER}/${hash}, which is what the code already does when the field is missing.
• Handle a ) or whitespace in the accepted url so the generated Markdown cannot be truncated — percent-encoding it is enough, and it keeps the link working.
• One test per case in src/nostr/blossom.test.ts: a non-http scheme falls back, a url with ) survives as a working link, a normal url is untouched.

Acceptance

• A server response with a non-http(s) url never reaches page content.
• A normal upload is unchanged — same url as today.
• npm run typecheck && npm run lint && npm test && npm run build pass.

Affected: src/nostr/blossom.ts

Source: CON-43, finding A3.

---

_{Task: znjfo3t0bd7owdbrcd94oux8}

[usekaneo]

CON-47

[usekaneo]

**** commented:

Technical refinement — Blossom attachment URL

1. Confirmed state

• src/nostr/blossom.ts:76-78 — the only check on the server-returned URL is typeof … === 'string', so a javascript:/data: URL lands in the descriptor.
• :103-110 — attachmentMarkdown escapes the label (:108 strips [, ], CR/LF, with the comment explaining why) but interpolates result.url verbatim; a ) or a space in it truncates the Markdown destination exactly as a ] would truncate the label.
• src/nostr/blossom.test.ts covers only the label handling. The upload path is untested, and no test in the repo stubs fetch or import.meta.env today — so the ticket's "non-http scheme falls back" case cannot be tested through uploadAttachment without new mocking machinery. Extracting a pure helper (below) avoids needing any.

2. Adjacent bug worth fixing in the same helper

The fallback at :78 uses BLOSSOM_SERVER directly, while the upload request at :59 strips a trailing slash (BLOSSOM_SERVER.replace(/\/$/, '')). A configured VITE_BLOSSOM_SERVER=https://blossom.example/ therefore produces https://blossom.example//<hash> on the fallback path. Route both through the same stripped base.

3. Recommended shape: a pure resolver, then a safe destination

resolveAttachmentUrl(descriptor, hash, server = BLOSSOM_SERVER) — exported, pure:

const candidate = (descriptor as Record<string, unknown> | null)?.url
if (typeof candidate === 'string') {
  try {
    const url = new URL(candidate)
    if (url.protocol === 'http:' || url.protocol === 'https:') return candidate
  } catch {
    /* not absolute — fall through to the deterministic path */
  }
}
return `${server.replace(/\/$/, '')}/${hash}`

• new URL('javascript:alert(1)') parses fine but the protocol check rejects it; a relative string throws and falls through.
• The injectable server parameter is what makes the fallback testable without vi.stubEnv and a module re-import (the module reads import.meta.env at load time). uploadAttachment keeps calling it with the default.
• uploadAttachment then replaces :76-78 with const url = resolveAttachmentUrl(body, hash).

attachmentMarkdown additionally sanitises the destination:

function markdownDestination(url: string): string {
  return url.replace(/[()<>\s\\]/g, (c) =>
    '%' + c.charCodeAt(0).toString(16).toUpperCase().padStart(2, '0'),
  )
}

• Encode (, ), whitespace, <, > and backslash. A bare ) would end the destination early, whitespace would end it too, </> are ambiguous with the <…> destination form, and backslash is an escape character.
• Percent-encoding is safe: HTTP servers decode %29 back to ) when resolving the path, so the link keeps working while the Markdown stays unambiguous.
• Deliberately not encodeURIComponent: that would also encode :///?/&/=, making the stored URL noisier and harder to read in a diff (this content is diffed and merged) for no benefit.
• Do it at insertion time, where the label handling already lives — the stored text has to be valid for every reader and survive the three-way merge; a render-time fix would only help this client.

4. Why it is still defence in depth

Per finding A2, react-markdown's defaultUrlTransform plus rehype-sanitize reject any non-http(s) URL at render, and the Blossom server is operator-configured (VITE_BLOSSOM_SERVER), not attacker-supplied. This ticket is about the stored content and about the asymmetry with the label escaping — not about closing an executable hole. Say that in the commit message so a later reader does not mistake it for the load-bearing XSS fix.

5. Tests (src/nostr/blossom.test.ts)

• resolveAttachmentUrl({ url: 'javascript:alert(1)' }, 'abc', 'https://b.example') → https://b.example/abc
• resolveAttachmentUrl({ url: 'data:text/html,x' }, 'abc', 'https://b.example') → fallback
• resolveAttachmentUrl({ url: 'https://cdn.example/abc' }, 'abc', 'https://b.example') → unchanged
• resolveAttachmentUrl({}, 'abc', 'https://b.example/') → https://b.example/abc (single slash)
• resolveAttachmentUrl({ url: '../relative' }, 'abc', 'https://b.example') → fallback
• attachmentMarkdown({ url: 'https://x/a)b.png', type: 'image/png' }, 'p.png') → ![p.png](https://x/a%29b.png); assert no stray ) and that a space is encoded
• a normal URL is byte-for-byte unchanged.

6. Acceptance / commands

• a non-http(s) url never reaches page content; a normal upload is unchanged; npm run typecheck && npm run lint && npm test && npm run build.
• Affected: src/nostr/blossom.ts, src/nostr/blossom.test.ts.

[usekaneo]

**** commented:

Implemented — branch con-47-blossom-attachment-url (uncommitted, in its worktree)

Files: src/nostr/blossom.ts, src/nostr/blossom.test.ts. All three refinement points are in, unchanged from the sketch:

1. resolveAttachmentUrl(descriptor, hash, server = BLOSSOM_SERVER) — exported and pure. Accepts the server's url only when it parses and its protocol is http:/https:; javascript: and data: parse fine, so it is the protocol check and not the parse that rejects them, and a relative string throws and falls through. uploadAttachment is now a single resolveAttachmentUrl(body, hash) call. The injectable server is what makes the fallback testable without vi.stubEnv and a module re-import.
2. The adjacent trailing-slash bug is fixed in the same helper. VITE_BLOSSOM_SERVER=https://blossom.example/ produced https://blossom.example//<hash> on the fallback path, because the upload request stripped the slash and the fallback did not. Both go through the stripped base now.
3. markdownDestination() percent-encodes (, ), <, >, whitespace and backslash at insertion time, next to the existing label escaping. Deliberately not encodeURIComponent — that would also encode :///?/&/= and make stored pages noisier in a diff and a three-way merge, for no gain.

Framing, so a later reader does not misread the commit

This is the second line, not the load-bearing fix. At render time rehype-sanitize plus react-markdown's defaultUrlTransform already reject any non-http(s) URL, and the Blossom server is operator-configured, not attacker-supplied. What justified the change is the asymmetry: the label was carefully escaped and the destination — where a ) truncates the link just as effectively — was not, and stored Markdown has to be valid for every reader, not only this client's renderer.

Verification (re-run independently)

npm run typecheck clean · npm run lint clean · npm test 44 files, 447 passed (11 in blossom.test.ts) · npm run build clean. Only caller of attachmentMarkdown is src/ui/PageEditor.tsx:184, unaffected.

[usekaneo]

**** commented:

Reviewed in worktree .claude/worktrees/agent-a170dfc4de2160645 (con-47-blossom-attachment-url (uncommitted)). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-47: Blossom: the url a server returns is embedded into page content without a scheme check

Verdict

⚠️ Approve with nits — no must-fix blockers. The ticket's acceptance criteria are met and the defence-in-depth goal is achieved; the two findings below are small correctness nits in the new code, not reasons to hold the merge.

Summary

The change closes the half of the Markdown-escaping problem the file had left open. A new resolveAttachmentUrl(descriptor, hash, server) accepts the server's descriptor.url only when it parses as an absolute http:/https: URL, otherwise returning the deterministic ${BLOSSOM_SERVER}/${hash} fallback; uploadAttachment now calls it instead of the bare typeof … === 'string' test (src/nostr/blossom.ts:64-73, used at :113-114). On the insertion side, a new markdownDestination() percent-encodes ()<>, whitespace and backslash so a ) in the destination can no longer end the link early, and attachmentMarkdown applies it to the url exactly as it already did to the label (src/nostr/blossom.ts:144-148,170). Test coverage is added for each ticket case plus the surrounding edges.

Acceptance criteria

#	Ticket item	Where it is satisfied	Status
1	Accept descriptor.url only if it parses as an absolute http:/https: URL; otherwise fall back to ${BLOSSOM_SERVER}/${hash}	src/nostr/blossom.ts:64-73; new URL + explicit protocol check at :67-68, fallback at :73. Tests src/nostr/blossom.test.ts:60-67,78-89.	✅
2	Handle a ) or whitespace in the accepted url so the Markdown cannot be truncated (percent-encoding enough, link keeps working)	markdownDestination at src/nostr/blossom.ts:144-148, applied at :170; ) → %29, whitespace → %20. Tests src/nostr/blossom.test.ts:36-50.	✅
3	One test per case: non-http scheme falls back; url with ) survives as a working link; a normal url is untouched	src/nostr/blossom.test.ts:60-67 (scheme), :36-50 (paren/space/backslash), :52-55 and :69-76 (normal url byte for byte).	✅
4	A server response with a non-http(s) url never reaches page content	The only production caller of uploadAttachment is src/ui/PageEditor.tsx:174, and it writes attachmentMarkdown(result, …) at :184; result.url comes from resolveAttachmentUrl at blossom.ts:114. No other descriptor path exists (grep for descriptor.url/resolveAttachmentUrl).	✅
5	A normal upload is unchanged — same url as today	blossom.ts:68 returns candidate verbatim (not url.href), so an ordinary absolute https://…/<hash> is stored byte for byte; guarded by blossom.test.ts:52-55.	✅
6	npm run typecheck && npm run lint && npm test && npm run build pass	Not run here by instruction; deferred to the separate CI job.	⏳ CI

Findings

No blocker or major findings. Everything below is minor/nit and verified by reading the code.

1. minor — markdownDestination is not a correct percent-encoder for non-ASCII whitespace

src/nostr/blossom.ts:145-147

return url.replace(/[()<>\s\\]/g, (c) =>
  '%' + c.charCodeAt(0).toString(16).toUpperCase().padStart(2, '0'),
)

The regex character class is the correct set for Markdown () closes the destination, whitespace starts the title, <> select the angle-bracket form, \ escapes), but \s in JavaScript also matches non-ASCII whitespace, and charCodeAt(0) plus two padded hex digits only produces a valid escape for code points ≤ 0xFF. Verified with Node:

"https://x/a\u00a0b.png" -> md "https://x/a%A0b.png"
"https://x/a\u2003b.png" -> md "https://x/a%2003b.png"

%A0 is not valid UTF-8 percent-encoding for U+00A0, and %2003 is worse: it encodes % plus four hex digits and decodes to %20 + 03. So the comment's promise at :137-138 — "a server decodes %29 back to ) while the link keeps working" — does not hold for those characters; the generated link points at the wrong bytes. This requires a server-supplied url containing a Unicode space (U+00A0, U+1680, U+2000–U+200A, U+2028, U+2029, U+202F, U+205F, U+3000, U+FEFF), so impact is small — but the fix is one line and makes the helper honest.

Fix: let the platform do the UTF-8 encoding:

const markdownDestination = (url: string): string =>
  url.replace(/[()<>\s\\]/g, (c) => encodeURIComponent(c))

(encodeURIComponent(' ') is %20, encodeURIComponent(')') is %29 — same output for every ASCII case already asserted — and non-ASCII whitespace becomes proper multi-byte escapes.)

2. nit — the accepted candidate is returned untrimmed, so a whitespace-padded url is stored as a broken link

src/nostr/blossom.ts:65-68

if (typeof candidate === 'string') {
  try {
    const url = new URL(candidate)
    if (url.protocol === 'http:' || url.protocol === 'https:') return candidate

new URL strips leading/trailing C0-control and space characters, so " https://x/a " passes the check — and then return candidate hands the unstripped string on, which markdownDestination renders as %20https://x/a%20. That destination decodes to a relative URL with a literal space, i.e. a broken link. It is not a regression (the old code embedded the raw spaces too, and the link was already broken), and returning candidate is exactly what keeps the "normal url unchanged" guarantee, so this is a nit rather than a defect in the ticket's scope. If the gate is meant to reject anything malformed, reject a padded candidate instead of silently keeping it:

if (candidate !== candidate.trim()) throw new Error('padded url')

or return the trimmed/parsed value only for that case. Low priority; the current behavior is no worse than before.

Tests

The tests are meaningful and would fail against the pre-change code:

• resolveAttachmentUrl did not exist before, so import { …, resolveAttachmentUrl } would fail immediately; independently, the old inline expression typeof descriptor.url === 'string' ? descriptor.url : … would return javascript:alert(1) for the case at blossom.test.ts:60-67 and would embed the raw ) for :36-50. Both new cases genuinely pin the fix.
• describe('resolveAttachmentUrl') takes server as the third argument (blossom.test.ts:61,64,70,…) instead of relying on import.meta.env. That is the right call given the module-level constant at blossom.ts:16, and the reason is written down at :55-57. The server parameter exists for exactly this.
• Edge cases present: non-string url (:80), null descriptor (:81), missing url (:79), relative url throwing in new URL (:85-89), trailing-slash server (:91-94), plus the http: (not just https:) branch (:73-75) and a byte-for-byte normal url (:52-55). Mixed-case schemes are covered only implicitly (the tests use lowercase); that is fine, since new URL lowercases the protocol before the comparison.

Nice-to-have, not required by the ticket:

• No test exercises uploadAttachment itself with a stubbed fetch. The wiring at blossom.ts:113-114 (the actual place the ticket cites) is therefore only covered indirectly through the extracted helper. An integration test with a mocked fetch would guard the call site against a future refactor that drops resolveAttachmentUrl.

• blossom.test.ts:41-42

  const withParen = attachmentMarkdown({ url: 'https://x/a)b.png', type: 'image/png' }, 'p.png')
  expect(withParen.slice(0, -1)).not.toContain(')')

  is dead weight: lines 37-39 already assert the exact output ![p.png](https://x/a%29b.png), which is strictly stronger. Harmless, but it can go.

• The finding-1 character class is untested with a non-ASCII whitespace url; if the encodeURIComponent fix is taken, one assertion such as '%C2%A0' would lock it in.

Docs

No documentation file was touched — the diff is confined to src/nostr/blossom.ts and src/nostr/blossom.test.ts, which matches the ticket's "Affected: src/nostr/blossom.ts". The docs that touch this behavior remain accurate:

• docs/09-security-privacy.md:37 — "no javascript: links" via rehype-sanitize; still true, and now true one layer earlier as well. The new gate is consistent with that claim. The strongly-worded design rationale lives in the function comment at src/nostr/blossom.ts:39-58 rather than in the security doc.
• docs/13-editing.md:444-451 — describes the attachment entry and "the resulting ![alt](url) … inserted at the cursor"; still an accurate description, since %29-style escaping does not change the shape.

Nice-to-have: a one-line row in the docs/09-security-privacy.md client-surface table ("Blossom descriptor url | accepted only as absolute http(s), else addressed by hash") would record the second-line defence where the rest of the threat model lives. Not required to satisfy this ticket.

What is good

• The gate is at the right layer. The check is applied where the URL enters the app (resolveAttachmentUrl, blossom.ts:114), so what is stored in a page event is already sound for every future reader and every other client — not only for this renderer's rehype-sanitize/defaultUrlTransform path. That is the correct reading of "defence in depth".
• Protocol, not parse. new URL(candidate) alone is correctly identified as insufficient (javascript: and data: parse fine) and the explicit url.protocol === 'http:' || 'https:' at :68 is what actually rejects them — exactly the ticket's point.
• Normal uploads are truly unchanged. Returning candidate rather than url.href at :68 avoids URL's normalization rewriting stored content (trailing slash, host case, re-encoding); the :52-55 test pins it.
• The fallback is deterministic and consistent with the upload path. Both :73 and the request URL at :96 strip one trailing slash, so a VITE_BLOSSOM_SERVER ending in / cannot yield //.
• The asymmetry the ticket names is genuinely closed: the destination now gets the same care the label already had (:169-171), and the comment at :150-163 records why the fix belongs at insertion time rather than in the renderer.
• The test seam is deliberate and explained: server as a parameter with a documented reason (:55-57) instead of trying to mutate import.meta.env after load.

---

Bottom line: mergeable as-is; both findings are optional polish. If only one is taken, take finding 1 (encodeURIComponent in the replacer) — it is one line and makes the percent-encoding claim in the comment actually true for every character the regex matches.

[usekaneo]

**** commented:

Review follow-up — branch con-47-blossom-attachment-url (uncommitted, in its worktree)

Both findings from the review are addressed. One of them is fixed differently from the suggestion, because the suggested one-liner would have reintroduced the bug this ticket exists to fix — details below, with the measurement.

Files touched: src/nostr/blossom.ts, src/nostr/blossom.test.ts, docs/09-security-privacy.md.

---

Finding 1 (minor) — markdownDestination is not a correct percent-encoder for non-ASCII whitespace

Verified: the diagnosis is right. Encoding from the UTF-16 code unit produces escapes no reader can resolve:

"https://x/a b.png" -> %A0    (decodeURIComponent throws URIError)
"https://x/a b.png" -> %2003  (decodes to "%20" + literal "03")
"https://x/a　b.png" -> %3000  (decodes to a literal "000")
"https://x/ab.png" -> %FEFF  (throws)

So the comment's promise — a server decodes %29 back to ) and the link keeps working — did not hold for those characters.

Not fixed as suggested. The review proposes url.replace(/[()<>\s\\]/g, (c) => encodeURIComponent(c)) and states that encodeURIComponent(')') is %29, "same output for every ASCII case already asserted". That is not correct: encodeURIComponent deliberately leaves the RFC 3986 mark characters ( ) ! ' * unescaped. Measured:

encodeURIComponent("https://x/a)b.png".replace(...)) -> https://x/a)b.png   <- unchanged

Taking that fix would have left a bare ) in the destination — exactly the truncation this ticket closes — and the existing test at blossom.test.ts asserting ![p.png](https://x/a%29b.png) would have failed. Flagging it rather than quietly applying it.

Fixed instead by encoding the character's UTF-8 bytes (src/nostr/blossom.ts, markdownDestination):

url.replace(/[()<>\s\\]/g, (character) =>
  [...UTF8.encode(character)]
    .map((byte) => '%' + byte.toString(16).toUpperCase().padStart(2, '0'))
    .join(''),
)

Percent-encoding is defined over bytes, so this is the honest form of what the old code was approximating. Every ASCII case already asserted is byte-for-byte identical (%29, %20, %3C, %3E, %5C, %28), U+00A0 now becomes %C2%A0 and U+2003 %E2%80%83, both of which decode back to the original. TextEncoder also cannot throw on a lone surrogate (it substitutes U+FFFD), unlike encodeURIComponent. The character class is unchanged, so the ticket's deliberate choice not to encode :///?/&/= — readability in a diff and a three-way merge — is untouched. The function comment now records why bytes and not code units, and why encodeURIComponent is wrong in both possible placements.

New test: encodes non-ASCII whitespace as the bytes a reader can decode again.

---

Finding 2 (nit) — the accepted candidate is returned untrimmed

Verified. new URL(" https://x/a ") parses (the parser discards leading/trailing C0 controls and spaces), the gate passes, and the unstripped string was handed on and stored as %20https://x/a%20 — a destination that decodes to a relative path with a literal space. A URL that was fine turns into a broken link.

Fixed, but not with trim() (the review's first option) and not by rejecting a padded candidate (its second). Both over-reach: trim() also strips Unicode whitespace that the URL parser treats as path content. Measured — new URL("https://x/a ").href is https://x/a%C2%A0, so the U+00A0 addresses a different blob, and trimming it would silently point the link elsewhere; rejecting the candidate would drop a URL the parser accepted.

New private helper withoutUrlPadding() removes exactly what the parser ignores (leading/trailing U+0000–U+0020), and resolveAttachmentUrl parses and returns that same string — so what is stored is precisely the string that was validated. Written as a loop rather than a regex, since a character class over the C0 range is what no-control-regex exists to flag.

New tests: drops the padding the URL parser ignored (space padding and \r\n…\t) and keeps Unicode whitespace the URL parser counts as part of the path (the over-trim guard).

---

Nice-to-haves

• Dead-weight assertion removed. Agreed — expect(withParen.slice(0, -1)).not.toContain(')') is strictly weaker than the exact-output assertion three lines above it. Gone.
• Non-ASCII whitespace assertion added — as the review suggested, %C2%A0 is now pinned.
• Docs row added. docs/09-security-privacy.md, client-surface table: the descriptor url is accepted only as an absolute http(s) URL, else the blob is addressed by its sha256, and the destination is percent-encoded at insertion time — with the second-line framing stated in the row itself so it is not misread as the load-bearing XSS fix.
• uploadAttachment integration test with a stubbed fetch: not added, with evidence. There is no .env in the repo, only .env.example, so under vitest BLOSSOM_SERVER === '' and attachmentsEnabled() === false (measured with a throwaway probe test, since removed). uploadAttachment therefore returns NO_BLOSSOM_SERVER and never reaches fetch. Such a test needs vi.stubEnv plus a dynamic re-import of the module — the machinery the injectable server seam was introduced to avoid. The call site at blossom.ts stays covered only indirectly; that is a deliberate, unchanged trade, not an oversight.

Knowingly out of scope

The URL parser also strips ASCII tab and newline from anywhere in the input, not just the ends, so a server url with an interior tab is stored as %09 and addresses a path the parser would not. Neither the review nor the ticket raises it, a fix means giving up the "normal url byte for byte" guarantee (returning url.href), and the current behaviour is strictly better than before the ticket (a raw tab used to break the Markdown outright). Left alone deliberately.

Verification (run in the worktree, after the changes)

• npm run typecheck — clean
• npm run lint — clean
• npm test — 44 files, 450 tests passed (14 in blossom.test.ts)
• npm run build — built in 1m 3s; only the pre-existing chunk-size advisory

One caveat, stated plainly: the first two full-suite runs failed in src/ui/markdown-live.test.ts ("draws a task list as real checkboxes that carry their state") — two failures, then one, then zero. That file imports nothing from blossom.ts and passes 3/3 in isolation, so it is flaky under the 44-worker parallel run and not caused by this change. Worth its own ticket; not treated as a result for this one.

Nothing is committed or staged — the changes are left in the working tree for review.

[usekaneo]

**** commented:

UI test pass — 2026-09-15, PR #92, 0824d4e

Tested in the running dev app (:5273) against a Blossom stub on port 3355 that answers an upload with whatever descriptor it is told to answer, so every branch of resolveAttachmentUrl could be reached with a real HTTP round trip. uploadAttachment and attachmentMarkdown were called as the shipped modules, not reimplemented. All cases pass. Merge-ready from the UI side.

Schemes that must never reach page content

Each row is a real upload; the stub returned the descriptor in column 1.

Server answered	Stored url
{"url":"javascript:alert(1)"}	http://localhost:3355/<hash> ✓
{"url":"data:text/html,<script>alert(1)</script>"}	http://localhost:3355/<hash> ✓
{"url":"vbscript:msgbox(1)"}	http://localhost:3355/<hash> ✓
{"url":"/evil/path"} (relative)	http://localhost:3355/<hash> ✓
{} (no url field)	http://localhost:3355/<hash> ✓
{"url":42} (not a string)	http://localhost:3355/<hash> ✓
{"url":"https://cdn.example/blob/abc.png"}	unchanged ✓

Markdown destination cannot be truncated

Server answered	Generated Markdown
http://localhost:3355/a b(c).png	 ✓
http://localhost:3355/a\b<c>d	 ✓
" https://cdn.example/x " (padded)	 — the stored string is the one the parser validated, no %20 padding ✓

The UTF-8-bytes detail the code comment argues for holds: with http://localhost:3355/a b c the destination comes out as a%C2%A0b%E2%80%83c — not %A0 and not %2003. That is the case a naive per-code-unit encode would get wrong.

The encoded destination is still a working link: fetching http://localhost:3355/a%20b%28c%29.png reaches the server with the decoded path, status 200.

Trailing slash

resolveAttachmentUrl({}, 'HASH', …):

server	Result
http://localhost:3355/	http://localhost:3355/HASH ✓ no //
http://localhost:3355	http://localhost:3355/HASH ✓
http://localhost:3355//	http://localhost:3355//HASH

The last one is an observation, not a defect: /\/$/ strips one trailing slash, and a VITE_BLOSSOM_SERVER ending in // is not a configuration anyone produces. Noting it only so the next reader does not rediscover it as a surprise.

A normal upload is unchanged

Against the real scripts/dev-blossom.mjs, not the stub: a text file uploads, the returned url is <server>/<sha256>, the generated Markdown is [notiz (v2).txt](http://localhost:3355/<hash>), and fetching that url returns the exact bytes that were uploaded. No behaviour change on the path that actually runs.