Remote Is Configuration, Not Topology

"The moment you hardcode where the brain lives, you've welded your client to one network. Make it a setting and the client goes anywhere."

The Hardcoding Temptation

When you're building a client that talks to your own backend, it's tempting to just write the address in. You know where the server is; why make it configurable? Because the instant that address is baked into source, three things go wrong at once: the client only works from one network, the topology becomes a fact anyone reading the code can see, and any secret that rode along with it (a PIN, a token) is now living in a place secrets must never live. Remote location and authentication are configuration — user settings resolved at runtime — never constants compiled into the client.

What Stays Out of Source, Always

The rule is strict and worth stating as a list, because each item is a real failure if violated:

The remote origin — where the Pippa backend lives — is a setting, so the same client works from home, from a phone network, from anywhere the user configures.
Authentication material — PINs, tokens, minted session credentials — never enters source code or a committed config file. It's entered by the user and held in appropriate secure storage, not in the repo.
Network coordinates — specific addresses and access details — stay out of committed code entirely. Code that reveals a private topology is a leak even in a private repo.

Configurable Is Also More Honest

Beyond safety, configuration is the more honest design. A hardcoded address pretends there's only one true place the backend lives; a setting admits the truth that where it lives is the user's choice and may change. This is the same respect-the-owner instinct as the rest of the quest, pointed at deployment: the person running the client decides its topology, supplies its secrets, and controls its access — none of which should be presumed and frozen by whoever wrote the code. Make it config, and the client becomes something the user owns and steers, not something welded to one builder's network.

Code

Resolve remote + auth at runtime, never from constants·typescript

// WRONG: topology and secrets welded into source.
const REMOTE = "http://<some-fixed-address>";  // client works from ONE place
const PIN = "1234";                              // a secret in the repo — never

// RIGHT: remote and auth are user settings, resolved at runtime.
async function getRemoteConfig(): Promise<RemoteConfig> {
  return {
    origin: await settings.get("pippaOrigin"),    // user-configured
    // auth material is entered by the user and held in secure storage,
    // never read from source or a committed config file
  };
}

// The same built client works from any network the user points it at.

Exercise

Audit a client you've built for hardcoded topology: search for any literal address, host, port-as-endpoint, or credential in the source. For each, decide where it should live instead (a user setting, secure storage, an environment value) and how the client would resolve it at runtime. Then ask the leak question: if this repo became public tomorrow, what did the hardcoded values reveal that they shouldn't have?

Hint

The tell is any network coordinate or secret you can grep for as a string literal. The fix is to replace each with a runtime lookup — a setting for locations, secure storage for secrets — so the code reveals the shape of the system without revealing its specific address or keys.