Switch nodes.
Not identities.

Genycaster routes named capabilities to typed provider instances. Choosing a protocol reader does not automatically replace your indexer, write validator or private signing key.

Three different connections

Role	What it can do	What it cannot promise
Raw Snapchain reader `snapchain-v1`	FID-scoped casts, profile UserData, social links and scoped cursors.	No aggregated follower counts, global search, notifications or guaranteed worldwide Explorer.
Indexed read API `hypersnap-v2`	Derived feeds, richer profile presentation, search and aggregated counts where actually supported.	It is not the canonical protocol and usually depends on a service's API contract.
Write validator separate write route	Accept locally signed protocol messages and support message reconciliation.	A read-only API does not become a writer just by changing its URL.

Switch a reader through the backend

1 Inspect route state

Resolve the active reader, default provider and saved preference independently. An active route is not a guarantee of endpoint health or chain synchronization.

2 Register an adapter

Declare the provider ID, contract, origin, supported capabilities and authorization requirements. Raw Snapchain and indexed APIs use different response schemas; a URL alone does not establish compatibility.

3 Probe and bind

Probe a representative API resource, record latency and response shape, save the selection and rebind the active reader. A successful response does not establish synchronization or every capability.

4 Enforce fallback consent

Off: no cross-provider reads for unsupported capabilities. On: a policy-compatible indexed service may fill gaps, subject to your choice. Derived counts shown with a raw reader can come from the indexer or an earlier local snapshot.

Provider routing flowchart

Requested capabilitye.g., user casts, global search or submit cast

Registry resolutionWhich adapter declares the operation?

Routing policySelected ID, privacy, health and consent

↓

Supported raw readOnly Snapchain protocol operation

Opt-in indexed fallbackOnly if feature and policy permit

Signed write routeIndependent validator, pinned in outbox

↓ Normalize canonical result / preserve endpoint affinity

Local canonical statePersistence update → notify consumers; previously fetched records can remain available offline

Provider profile example

The following is a schema illustration using reserved invalid example origins, not a live API endpoint or a claim of working compatibility.

Read provider profiles · illustrative JSON

{
  "readProviders": [
    {
      "id": "my-own-reader",
      "label": "Home Snapchain",
      "contract": "snapchain-v1",
      "endpoint": "https://reader.example.invalid",
      "selfHosted": true
    },
    {
      "id": "secondary-index",
      "label": "Optional indexed API",
      "contract": "hypersnap-v2",
      "endpoint": "https://index.example.invalid",
      "selfHosted": false
    }
  ],
  "allowCompatibleReadFallback": false
}

Actual persisted settings use network/readProviderProfilesJson and network/allowCompatibleReadFallback; write profiles use a separate record and endpoint binding.

Correctness and privacy invariants

Never send a signer private key or recovery phrase to a read API.
Never copy credentials to a second provider unless expressly configured for that destination.
Do not assume that two domains implement the same endpoint contract.
Opaque cursors are bound to provider instance and endpoint; changing provider invalidates that continuation rather than mixing result pages.
Durable writes keep their original chosen validator; an unresolved write does not jump to the next reader.

See engineering source and architecture map.

Switch nodes. Not identities.