Browser package behavior
Browser entrypoint resolution, lower-level auth imports, and persistent storage.
Start new applications with Build a browser dapp. That guide is the canonical source for service-worker, Vite, startup, hosting, and verification instructions.
Entrypoints
Import the application surface from @enbox/browser. It re-exports the
high-level API, auth lifecycle, wallet connect handler, and DWeb helpers.
@enbox/browser, @enbox/api, @enbox/auth, and @enbox/agent publish
browser-conditioned entrypoints. Browser-aware bundlers resolve their bare
package imports to browser bundles in both page and service-worker builds.
Current releases do not need Enbox-specific process, global, Node
standard-library, dynamic-import, or IIFE workarounds.
Applications that deliberately own the lower-level auth lifecycle can import its browser surface:
import { AuthManager, PasswordProvider } from '@enbox/auth/browser';Most dapps should use createConnectionStore() from @enbox/browser so one
owner handles restoration, readiness, monitoring, facade replacement, and
teardown.
Storage
The browser agent stores its local replica through level, which resolves to
browser-level over IndexedDB. Keep this default: IndexedDB persists offline
data and coordinates concurrent access from same-origin tabs and workers.
In-memory storage and @enbox/dwn-sql-store do not provide that browser model.