feat: add data: and ipfs:// URI support in fetchRegistrationFile

[vraspar]

Summary

• Support all three ERC-8004 agentURI schemes in fetchRegistrationFile:
  • https:// (existing)
  • data:application/json;base64,... and data:application/json,... (on-chain storage)
  • ipfs://<cid> via configurable gateway (default: ipfs.io)
• Add FetchRegistrationFileOptions with optional ipfsGateway parameter
• Thread ipfsGateway through resolveServiceEndpoint
• Bump to 0.1.0-alpha.2

Depends on #7 (revert of direct push) being merged first.

Test plan

• 103 tests pass (14 new: 9 data URI + 4 IPFS + 1 error message)
• pnpm typecheck passes
• pnpm build clean

🤖 Generated with Claude Code

[A1igator]

SDK Review

Found 2 issues (reviewed: tests, conventions, dead code, SDK design):

1. [Conventions / Portability] Buffer.from(payload, 'base64') is a Node.js-only API. The SDK uses globalThis.fetch everywhere else to stay runtime-agnostic, but Buffer breaks that contract and will throw ReferenceError in browsers, Cloudflare Workers, and Deno. Additionally, Buffer.from silently discards invalid base64 characters instead of throwing (the test file itself acknowledges this at line 367), which means malformed base64 data URIs produce a misleading "not valid JSON" error instead of "Failed to decode data URI (base64)". The commit message says "Fix atob -> Buffer.from for correct UTF-8 handling" but JSON is ASCII-safe, and atob() + TextDecoder handles UTF-8 correctly while being available in all runtimes.

   Fix: replace Buffer.from(payload, 'base64').toString('utf8') with atob(payload) (sufficient for JSON) or new TextDecoder().decode(Uint8Array.from(atob(payload), c => c.charCodeAt(0))) for full UTF-8.

   erc8004/src/registration/fetch.ts

   Lines 94 to 95 in 0e5eb8d

   	decoded = isBase64
   	? Buffer.from(payload, 'base64').toString('utf8')

2. [Conventions / Security] IPFS CID is extracted with uri.slice(7) and concatenated directly into the gateway URL with no validation. Two concerns: (a) ipfs://QmFoo/../../../other path-traverses to https://ipfs.io/other after URL normalization, causing an SSRF against the gateway; (b) ipfs:// with no CID produces https://ipfs.io/ipfs/ which hits the gateway's listing endpoint. Since agentURI values come from an on-chain registry (attacker-controllable), this is a realistic attack surface. Impact is limited to the IPFS gateway host, not arbitrary hosts.

   Fix: validate the extracted path before constructing the URL -- reject empty CIDs and .. path segments.

   erc8004/src/registration/fetch.ts

   Lines 30 to 34 in 0e5eb8d

   	if (uri.startsWith('ipfs://')) {
   	const gateway = options?.ipfsGateway ?? DEFAULT_IPFS_GATEWAY
   	const base = gateway.endsWith('/') ? gateway.slice(0, -1) : gateway
   	const path = uri.slice(7) // strip "ipfs://"
   	fetchUrl = `${base}/ipfs/${path}`

---

Generated with Claude Code using review-sdk skill