Use OAN

This section turns the OAN architecture into practical tasks. If you want to publish a resource, find a resource, try official services, configure a third-party node, or understand why a request failed, start here.

OAN can be approached at different depths. A first-time user can try the official website pages. A developer can use the TypeScript SDK. A community user can use the OAN community skill from an AI assistant. A node operator can prepare for trial-network participation. These paths share the same underlying model: resource identity, Registrar onboarding, Root acceptance, Discovery visibility, and verification before use.

The practical goal is to make OAN usable before a user understands every internal module. A publisher should be able to register a resource with guided fields. A consumer should be able to search for a resource by describing a task. A developer should be able to script the same actions with SDK calls. The trust model should be present in all of those paths, but it should be carried by clear defaults and evidence rather than by asking every user to become an operator.

The Three Most Common Tasks

The official website should remain simple: registration and Discovery pages are task surfaces, not long technical essays. The deeper explanation belongs in Docs so users can learn as much as they need without making the forms heavy.

That separation is deliberate. The Register and Discover pages are where users act. Docs is where users understand what the action means. SDKs and skills are where the same model becomes repeatable and automatable.

Default Path: Official Services

Most users should begin with official services. The default baseUrl in public SDK and skill workflows should point to the official service entry, and the website can call official Registrar and Discovery endpoints through the configured public entry. This gives users a working path without asking them to understand node topology first.

Using official services does not mean users are locked in. OAN is designed for third-party compatible nodes. A later user or organization can configure a different baseUrl or explicit Registrar and Discovery endpoints when they operate or trust another node set.

This default-and-override pattern is important for adoption. New users get one working official entry. Advanced users keep the ability to point the same SDK or skill at a third-party operator, an enterprise deployment, a test network, or a future production domain. The user-facing workflow stays similar even when the deployment behind it changes.

What Users Still Need To Understand

The official path lowers the barrier, but it does not remove user responsibility. A publisher still needs to describe the resource honestly. A Discovery user still needs to read results as candidates. A developer still needs to verify evidence before installing, connecting, or invoking. An enterprise still needs runtime access controls and policy checks.

The most important terms to keep straight are:

• resource type: what kind of resource is being published or searched;
• authorizedDomains: governance and publication scope;
• capabilityTags: descriptive matching hints;
• lifecycle: whether the resource is submitted, accepted, published, indexed, active, superseded, or revoked;
• proof and hashes: how the client verifies that returned material matches Root-accepted facts.

How To Choose a Path

If you only want to see how OAN feels, use the website. Register a small test resource, then query Discovery for it. If you want repeatable integration, use the SDK. If you want AI-assisted workflows for resource registration and discovery, use the community skill. If you want to operate infrastructure, read the trial-network and governance material before assuming a node can join automatically.

For product teams, the first real milestone is publishing one resource with accurate metadata and verifying that it can be found and checked. For researchers, the first milestone may be reviewing the identity and discovery model. For operators, the first milestone is understanding node authorization, domain scope, and operational responsibilities.

For ecosystem partners, the first milestone may be even simpler: decide which existing resources should become OAN-visible. A team with MCP servers, internal skills, APIs, or agent services does not need to rewrite those systems first. It can begin by wrapping them with did:oan identity, resource metadata, domain scope, and verifiable publication evidence.

What Success Looks Like

A successful OAN use flow usually looks like this:

1. A resource has a stable did:oan identity and clear metadata.
2. Registration succeeds through an authorized Registrar.
3. Root accepts the package version and creates proof.
4. Package material becomes available through the distribution path.
5. Discovery indexes it within the relevant authorized-domain scope.
6. A user or SDK finds it and verifies evidence before use.

Any step can fail or take time. That is normal for a governed distributed system. Good tools should tell you which step you are in.

When learning OAN, it helps to keep two questions separate. “Can I find a resource?” is a Discovery question. “Should I use this resource?” is a verification and policy question. OAN gives you both surfaces, but it does not collapse them into one opaque recommendation.

Further Reading

• Resource registration and discovery guide
• OAN homepage repository
• OAN community skill repository