Skip to main content

Point a consumer at your node

A consumer — the DIG Browser, the extension, or the dig-store CLI — does not need a node to read DIG content; every one of them falls back to the public reference node at rpc.dig.net when no local node is reachable. Pointing a consumer at a local dig-node makes reads local-first: faster, offline-friendly, and contributing to the network. When a node is on the same machine, the consumer and the node share one .dig cache.

How it works​

Every consumer resolves its node endpoint in the same fixed order, using the first that responds:

  1. An explicit override, when the consumer has one set — always wins over the automatic steps below.
  2. dig.local — an installed local dig-node. A consumer that can use HTTPS prefers https://dig.local, falling back to plain http://dig.local.
  3. localhost — a dig-node on the loopback address, its default local port.
  4. rpc.dig.net — the public gateway, the final fallback when no local node answers.

Either way every byte is verified client-side against the chain; pointing at a local node changes where ciphertext is fetched, never whether it's trusted. Node-class clients (the CLI, the SDK) connect over mTLS with a client certificate derived from their identity key, across all three tiers; rpc.dig.net also serves plain HTTPS for browsers, which can't present a client certificate.

Set the host​

  • DIG Browser — the My Node UI lets you select the local dig-node and view its status.
  • Extension — set the dig-node host (the server.host setting) to your node; leave it blank to use the automatic dig.local → localhost → rpc.dig.net resolution. To also read wallet balances/tokens/NFTs from your node, see Wallet data (extension) below.
  • dig-store CLI — set an explicit override with the --node <url> global flag, the $DIG_NODE_URL environment variable, a per-project digs config node.url --local <url>, or a machine-wide digs config node.url <url>; leave them all unset to use the automatic resolution, which prefers your own node. See Which node dig-store talks to.

Wallet data (extension)​

Beyond reading content, the extension's wallet can source its data — balances, tokens (in the XCH → $DIG → other-CAT order), NFTs, identities (DIDs), and activity — from your own dig-node instead of the public coinset.org service. Reading from your node is more private (your addresses aren't disclosed to a public operator) and faster.

Your keys never leave your device. The node is a read-only data source for the extension: it answers what your wallet holds, but every send is still signed locally in the extension's own encrypted vault. The node never receives a key.

Choose the source under Settings → Wallet data source (in the full-window wallet):

  • Automatic (default) — use your dig-node when it's running, otherwise fall back to coinset.org. As soon as a local node answers, the panel shows a "Local dig-node detected" note naming its address — no manual setup needed.
  • My dig-node — always read from your local node; wallet data is unavailable if it isn't running.
  • coinset.org — always use the public service; your node isn't used for wallet data.
  • Custom node URL — read from a specific node RPC address you enter.

An explicit choice overrides the automatic dig.local → localhost → rpc.dig.net order. Changing the source re-loads every wallet view from the newly selected source right away.

Local-first caching​

The first time you open a store, your node fetches just enough to answer that request immediately and starts syncing the rest of the store in the background; once it's fully synced, every later read of it comes straight from your disk — no network round-trip. The public network (a peer, or rpc.dig.net) is used only for stores your node hasn't synced yet, or ones evicted to stay under the reserved cache cap. If a store you've synced publishes a new version on-chain, your node re-syncs the change automatically. Either way, every byte is still verified against the chain before it reaches you — local-first changes where content comes from, never whether it's trusted.

With a local node reachable, the extension also opens a store directly from it as an ordinary website — see Reading from your own node.

The shared cache​

The local cache is a set of capsules keyed by storeId:rootHash, written content-addressed with a cross-process lock — so the in-process browser node and a standalone dig-node on the same machine read and write one cache without corruption.