Investigation: slow Profile-mode wallet load (post sphere-telco-test deploy 2026-06-02)

[vrogojin]

Symptom

User reports: "Loading the profile takes a lot of time" on https://sphere-telco-test.dyndns.org after deploy of bundle index-B4OewTZs.js (sphere-sdk @ 96991eb on PR #385 — the identity-keys cache-only + lazy-backfill fixes).

Browser-console-visible artifacts from the same load that are already understood / not the cause:

• dag/import 400 + dag/export 400 ABORTED on unicity-ipfs1.dyndns.org — gateway capability probe per Issue perf(profile/ipfs): enable CAR-batching at Unicity Kubo gateway + switch SDK to /dag/import + /dag/export #370 (probeEndpointExposed). 400 is the positive signal; one-time per process per gateway.
• [Sphere] Identity read for "master_key" missing from primary storage; consulting fallbackStorage etc. — first post-deploy boot of an existing wallet, expected; backfill (PR fix(profile)(security): keep identity / seed material out of OrbitDB #385 commit 96991eb) runs on this boot and silences future boots.
• POST goggregator-test.../ 400 (Bad Request) — JSON-RPC liveness probe with deliberately bogus shardId per useAggregatorStatus.ts:36-40, intentional.
• GET goggregator-test.../health CORS error — server-side CORS bug, tracked at unicitynetwork/aggregator-go#155. 8 s timeout per round but runs in a React useEffect, NOT on the load critical path.

So the slow-load symptom is a separate concern — needs profiling.

What we know about the load path

Sphere.init in Profile-mode on an existing wallet (see sphere/src/sdk/SphereProvider.tsx:607-744) does:

1. First Sphere.init with legacy createBrowserProviders → spins up Sphere bound to legacy IndexedDB storage.
2. runProfileMigration → reads legacy tokens, writes Profile bundle CAR to IPFS, anchors via aggregator pointer.
3. Sphere.destroy({ force: true, reason: 'uxf-profile-swap' }).
4. Second Sphere.init with Profile-backed providers (createBrowserProfileProvidersFromSphere) + fallbackStorage: legacyStorageForFallback → spins up Sphere bound to OrbitDB.
5. After Sphere ready: setupIpfsSync, address discovery, send-welcome-DM.

Candidate slow-load sources (need profiler to confirm)

Candidate	Source file	Approx cost
First-boot Profile migration (one-time per wallet)	profile/migration.ts	seconds–10s+ depending on legacy data size
OrbitDB pubsub initial peer discovery (second Sphere.init)	profile/orbitdb-adapter.ts	~10–30 s cold
Initial pointer-poll → aggregator → IPFS roundtrip	profile/aggregator-pointer/* + profile/ipfs-client.ts	1–3 s + 2 s gateway capability probe
/sidecar/blob 404 streak before cold-cache trips at 3 misses (PR #384)	profile/ipfs-client.ts:524	~RTT × 3, then short-circuits
First Sphere.init reading legacy tokens before migration	IndexedDBTokenStorageProvider	depends on token count
_payments.load() reading CAR from IPFS (second init)	PaymentsModule.load → ProfileTokenStorage.load	depends on CAR size + gateway RTT

What we need from the next reproduction

To pinpoint without guessing:

1. DevTools → Performance record of a load, from page navigation to "balances visible". User attaches the trace OR shares a few representative User Timing measure names if the SDK already emits them.
2. OR the screen state during the slow phase:
   • Blank page → time is before the React tree mounts.
   • Loading wallet… spinner → Sphere.init (likely Profile migration step or 2nd init's OrbitDB sync).
   • UI visible but balances/messages blank → _payments.load() reading CAR.
3. OR observability data from existing counters in profile/profile-token-storage/flush-scheduler.ts (the incr('flushScheduler.flushToIpfs.calls') / observeMs('flushScheduler.flushToIpfs.totalMs') pair) and similar in the OrbitDB adapter — pull from sphere.metrics if exposed.

Quick instrumentation worth adding (deferred to whoever picks this up)

If the next reproduction confirms the bottleneck is in Sphere.init rather than data-fetch, add structured console.time/console.timeEnd (or performance.measure) milestones at each setInitProgress({step: ..., message: ...}) site in sphere/src/sdk/SphereProvider.tsx:656,704,736 and inside sphere-sdk/core/Sphere.ts at the boundaries of loadIdentityFromStorage, initializeModules, runProfileMigration invocation, second init start, and setupIpfsSync. That gives operator timing without needing a Performance trace.

Not in scope here

• Aggregator CORS — separate issue aggregator-go#155.
• dag/import / dag/export 400 noise — by design per Issue perf(profile/ipfs): enable CAR-batching at Unicity Kubo gateway + switch SDK to /dag/import + /dag/export #370. If we want to silence DevTools red, we'd need to drop the probe (and lose Issue perf(profile/ipfs): enable CAR-batching at Unicity Kubo gateway + switch SDK to /dag/import + /dag/export #370's optimization signal) or accept the noise.

Related

• PR fix(profile)(security): keep identity / seed material out of OrbitDB #385 — identity keys cache-only + lazy backfill (shipped).
• Issue Client-side Helia/libp2p bootstrap is too heavy — clients should HTTP-only to operator Kubo gateway(s) #266 / PR fix(profile)(#264): auto-merge monotonicity violations; gate broadcasts behind flag (default OFF) #265 — HTTP-only IPFS design (prior work on Profile-mode IPFS perf).
• Issue Profile: shutdown must verify remote IPFS + aggregator durability before exit (root cause of #234 manual-test failure) #239 / PR fix(profile)(#239): per-flush + opt-in shutdown remote-durability gate #240 — per-flush + opt-in shutdown gate + deterministic OrbitDB id + FsBlockstore (prior work on Profile-mode pin durability).
• Issue perf(profile/ipfs): enable CAR-batching at Unicity Kubo gateway + switch SDK to /dag/import + /dag/export #370 — dag/import single-roundtrip CAR push (the probe whose noise was misread as a regression here).

🤖 Generated with Claude Code