Use Third-Party Nodes

OAN is not meant to be a single website forever. Third-party Registrars and Discovery nodes can serve specialized communities, domains, enterprises, or research deployments. The important requirement is compatibility with the OAN trust model: governed node identity, authorized-domain scope, Root acceptance, package proof, lifecycle state, and verifiable Discovery responses.

For users, third-party support should feel simple. Configure a baseUrl for the node operator’s public entry, or override individual endpoints when you need more control.

The goal is portability without confusion. A user should not need to know whether an operator places a reverse proxy, gateway, or service mesh behind the public entry. The operator explains the baseUrl; the client derives standard routes; evidence verification decides whether returned resources are trustworthy.

Deployment patterns

Configuration Modes

Mode User experience Best use
baseUrl only One stable entry point for Registrar, Discovery, Root, CDN, and related routes. Normal users and most SDK integrations.
Explicit endpoints Separate registrarEndpoint, discoveryEndpoint, rootEndpoint, or cdnEndpoint. Diagnostics, tests, specialized deployments.
Hybrid Use baseUrl for most services and override one service. Advanced cases, such as using a third-party Discovery with official Root lookup.

The precedence should be clear: explicit endpoints override routes derived from baseUrl service by service. If no override is provided, the client constructs the route from baseUrl.

For example, an application may use an enterprise baseUrl for normal registration and Discovery, but temporarily override discoveryEndpoint to test a new semantic search implementation. That should be an intentional advanced configuration, not the default path for ordinary users.

What a Third-Party Operator Should Publish

A good third-party operator should tell users:

  • the public baseUrl;
  • any direct service endpoints;
  • node DID identities;
  • role of each node, such as Registrar or Discovery;
  • authorized domains;
  • status and lifecycle information;
  • how Root authorization is obtained;
  • what evidence clients should verify;
  • whether the operator is official, recognized, experimental, enterprise-private, or community-run.

This information is not marketing detail. It is how users decide whether the node is appropriate for their resource or query.

Operators should avoid vague claims such as “OAN compatible” without explaining the evidence path. Compatibility should mean that clients can verify node identity, Root proof, package hashes, lifecycle, and domain authorization in the expected way. A pretty search page alone is not enough.

Trust Still Comes From Evidence

A third-party baseUrl is a routing entry, not a trust authority. The client should still verify the node identity, Discovery response signature, Root proof, package hashes, lifecycle, and domain scope. If a third-party operator exposes a nice gateway but the returned candidates cannot be traced to Root-accepted packages, the integration is not a proper OAN trust path.

Similarly, using a third-party Registrar means the Registrar must be authorized for the domains it accepts. A specialized Registrar cannot onboard arbitrary all-domain resources just because its endpoint is reachable.

If an operator is experimental or private, users should know that too. A private enterprise Discovery node may be perfectly valid inside its organization while not being a public ecosystem endpoint. A research node may be useful for ranking experiments while not suitable for production registration. Clear labels protect both operators and users.

When Third-Party Nodes Are Useful

Third-party nodes are useful when:

  • a domain community wants specialized onboarding review;
  • an enterprise wants internal or controlled Discovery;
  • a region wants a local operator;
  • researchers want to test ranking, semantic indexing, or node behavior;
  • product ecosystems want their own Registrar policies while remaining compatible with OAN evidence;
  • public load needs to be distributed beyond official services.

The model supports this without requiring every user to run the entire OAN stack. Ordinary users can keep using official defaults; advanced users can opt into other operators.

This is one of OAN’s ecosystem advantages. It can start with official services and grow toward federated operation. Specialized communities can build better onboarding and search experiences for their domains while still using shared resource identity and verification semantics.

Avoid Mixed Trust Confusion

Endpoint overrides are powerful but can create confusing states. If you use one Root endpoint, another Registrar, and a third Discovery node, make sure they are part of a compatible trust context. A Discovery node indexing packages from one Root may not be meaningful if your client verifies against another Root. A Registrar may accept a resource that your selected Discovery node will never expose because domain scope differs.

For normal usage, prefer one coherent baseUrl from a node operator. Use explicit endpoints when you are debugging or intentionally testing a mixed deployment.

When evaluating a third-party node, start with status endpoints and a small known resource. Check that registration errors are clear, Discovery results include evidence, and domain scope behaves as advertised. Only then move important resources or automated workflows to that operator.

Further Reading