`/chunks` (and other Bee API routes) unreachable from a `bzz://` origin — iOS already allows them

[petfold]

Labels: enhancement

---

buildGatewayUrl in the desktop bzz: handler can only ever produce one shape
of upstream URL (src/main/swarm/bzz-protocol.js:142, and the ENS branch at
:219):

url: `${antApiUrl}/bzz/${host}${parsed.pathname}${parsed.search}`,

Everything after the reference is treated as a path inside that manifest. So a
page served from bzz:// cannot reach any other Bee API route — notably
/chunks/<ref>, but also /bytes/, /feeds/, /soc/.

iOS does allow this

freedom-browser-ios routes reserved Bee API paths straight through
(Freedom/Freedom/BzzSchemeHandler.swift:259-294):

When the path looks like a reserved Bee API route (/bzz/<ref>,
/bytes/<ref>, /chunks/<ref>, /feeds/<owner>/<topic>, /soc/<owner>/<topic>),
route directly — this is how Swarm SPAs issue relative fetch('/bzz/<ref>/')
calls. Otherwise treat the path as a subpath inside the current origin's
manifest.

…with the discrimination in isBeeGatewayPath (:296). So the same page gets
different capabilities on the two platforms, and the iOS comment suggests
relative-fetch passthrough is considered normal for Swarm SPAs.

Why it matters

/chunks/<ref> is what makes client-side verification possible: fetch a
chunk, BMT-hash it, confirm it matches the reference you asked for. Without it a
page on bzz:// can only take the handler's word for what it received. On
desktop that's tolerable — the request goes to the user's own node — but it means
verification code can't be exercised on the platform where most development
happens, and a page can't offer the same guarantees across platforms.

Concretely this is the blocker for the verified read path in
swarmlite
(js/src/verify.js, js/src/index.js:33-40), which canopy could use to verify
its network index rather than trusting it (filed on canopy separately).

The awkward part

The two platforms currently block different halves of the same feature:

	desktop	iOS
Range → 206	works	dropped (filed separately)
/chunks reachable	no	yes

So neither platform supports both lazy range reads and client-side verification
today, and any page wanting both has to degrade per platform.

Options

• Mirror iOS: add an isBeeGatewayPath-style branch. Simplest, and makes the
  platforms consistent.
• Narrower: allow only /chunks/<64-or-128-hex> — enough for verification
  without opening the wider API surface.
• Deliberately not: if desktop's manifest-scoping is a security decision
  rather than an omission, that's a reasonable answer — but then the iOS
  passthrough is the bug, and it'd be worth saying so in one place so the next
  person doesn't assume parity.

I don't know which of these is intended, which is why this is a question as much
as a request. Note that /chunks is GET-only and content-addressed, so widening
to it doesn't expose write or node-control surface.

[petfold]

Correction to my own issue — the motivation section above is partly wrong, and I'd rather flag it than let it stand.

I claimed a page on a bzz:// origin "can only take the handler's word for what it received." That's true of the fetch path, but not of the browser: the window.swarm provider already exposes

• swarm_readChunk — and it's permission-free (swarm-provider-ipc.js:716, listed at :91)
• swarm_readSingleOwnerChunk

…and readChunk verifies rather than trusting: it unmarshals the CAC and compares the derived address against the reference requested (chunk-service.js:132-143, ensureSameReference). So client-side-verifiable chunk reads are available on desktop today, and the main process is doing the address check itself.

What I think still stands:

• The asymmetry is real: a relative fetch('/chunks/<ref>') works on iOS (BzzSchemeHandler.swift:259-294) and not on desktop, so the same page code takes different paths per platform. That's worth a deliberate answer either way.
• It's a convenience/portability question, not a capability gap. Readers written against fetch — e.g. swarmlite's verified mode — need an adapter on desktop rather than being blocked. Since that reader takes an injectable fetchFn, adapting it to swarm_readChunk looks straightforward and needs no change here.

Suggest re-reading this as: "should /chunks be reachable via fetch on desktop for parity with iOS?" — with much lower priority than the original text implied. Happy for it to be closed as wontfix if the provider is the intended route; if so, saying that somewhere would help, since the iOS passthrough currently reads as the norm.

Apologies for the noise — I should have grepped the provider surface before filing.