FNS Core v0

Self-certifying alias claims, capability lineages, and deterministic non-authoritative resolution for Node.js 20+.

한국어 README

Install

npm install fns-v0-validator

The package is licensed under MPL-2.0.

Public API

const fns = require("fns-v0-validator");
const alias = require("fns-v0-validator/alias-binding");
const commune = require("fns-v0-validator/commune-document");
const resolution = require("fns-v0-validator/resolution");
const store = require("fns-v0-validator/store-interface");
const publication = require("fns-v0-validator/publication");
const multiRelay = require("fns-v0-validator/multi-relay-discovery");
const client = require("fns-v0-validator/client-resolution-profile");
const serviceDescriptor = require("fns-v0-validator/service-descriptor");

The root package exports all stable APIs: validateObject, resolveBindingState, validateCommuneObject, resolveSuccessors, effectiveCapabilities, validateAliasBindAttestation, discoverAliasClaims, buildResolutionClaim, inspectCommuneForks, aggregateResolutionClaims, applyLocalTrust, resolveAlias, FnsStore, MemoryStore, SQLiteStore, discoverFromStore, resolveAliasFromStore, createRelayServer, RelayStore, PublicationStore, LocalPublicationStore, discoverFromRelays, resolveAliasFromRelays, discoverServiceDescriptorsFromRelays, validateClientProfile, parseFnsUri, resolveFnsUri, resolveTargetFromUri, validateServiceDescriptor, serviceDescriptorObjectId, and serviceDescriptorSigningInput.

The src/ implementation files are not public import paths; use the root or the documented subpaths.

AliasBinding v0 is implementation-frozen. See ALIAS-BINDING-V0-FREEZE.md for the frozen surface and compatibility gate; CommuneDocument is the next independent object type.

The proposed philosophical minimum for that next type is in COMMUNE-DOCUMENT-V0-DESIGN.md.

The implementation exposes validateCommuneObject, resolveSuccessors, effectiveCapabilities, and validateAliasBindAttestation from src/commune.js.

CommuneDocument v0 is implementation-frozen under COMMUNE-DOCUMENT-V0-FREEZE.md. The cross-object verification contract is in CONFORMANCE.md.

The next read-only interpretation boundary is specified in RESOLUTION-LAYER-V0-DESIGN.md.

Run the thin Resolution CLI with node bin/fns-resolve.js query.json object-store.json options.json.

Resolution Layer v0 is implementation-frozen under RESOLUTION-LAYER-V0-FREEZE.md.

Store Interface v0 provides async read-only discovery without changing the frozen Core resolver. See STORE-INTERFACE-V0-PLAN.md and STORE-INTERFACE-V0-FREEZE.md.

SQLiteStore is the first persistent Store implementation. Its schema and conformance boundary are documented in SQLITE-STORE-V0-PLAN.md.

Relay/Discovery v0 transports Store candidate envelopes over a single HTTP relay without choosing winners or assigning trust. See RELAY-DISCOVERY-V0-PLAN.md and RELAY-DISCOVERY-V0-FREEZE.md.

Publication Layer v0 adds an optional POST /v0/objects candidate-write boundary. It stores candidates idempotently but never validates FNS semantics or grants trust. See PUBLICATION-LAYER-V0-PLAN.md and PUBLICATION-LAYER-V0-FREEZE.md.

Multi-Relay Discovery v0 merges independent relay observations without voting, ranking, hiding conflicts, or claiming global completeness. See MULTI-RELAY-DISCOVERY-V0-PLAN.md and MULTI-RELAY-DISCOVERY-V0-FREEZE.md.

Client Resolution/Profile v0 is the local configuration and fns: URI bridge to Multi-Relay resolution. See CLIENT-RESOLUTION-PROFILE-V0-PLAN.md and CLIENT-RESOLUTION-PROFILE-V0-FREEZE.md.

ServiceDescriptor v0 validates immutable subject-signed service claims. The frozen additive discovery extension transports raw candidates by subject across Store, Relay, and Multi-Relay, then projects independently validated descriptors beneath eligible resolved subjects. It never selects or merges descriptor endpoints. See SERVICE-DESCRIPTOR-V0-PLAN.md, SERVICE-DESCRIPTOR-V0-FREEZE.md, SERVICE-DESCRIPTOR-DISCOVERY-EXTENSION-V0-PLAN.md, and SERVICE-DESCRIPTOR-DISCOVERY-EXTENSION-V0-FREEZE.md.

const { validateObject } = require("fns-v0-validator");
const result = validateObject(object, { [bindObjectId]: bindObject });

result has separate wellFormed, cryptographic, and relationships sections. Each always has status (valid, invalid, or not-evaluated), valid, errors, and warnings; objectId is the ObjectId calculated from the payload.

resolveBindingState(bindingId, store) returns active, released, not-found, or invalid-binding. Only releases that pass all three validation sections change a binding to released; invalid releases are reported but ignored.

The CLI accepts an object and a JSON object store whose keys are ObjectIds:

node bin/fns-validate.js object.json object-store.json

Run the bundled vector with npm test.

CLI

fns-validate object.json object-store.json
fns-resolve query.json object-store.json options.json
fns profile validate profile.json
fns resolve fns:alice --profile profile.json
fns target fns:alice --profile profile.json
fns relay status --profile profile.json [--uri fns:alice]
fnsd --profile profile.json --port 8080
fns-viewer --port 8081

Client CLI v0 is a frozen JSON-only shell surface over the client libraries. resolve and target write the corresponding library result without selecting a winner, head, relay, descriptor, or endpoint. See CLIENT-CLI-V0-PLAN.md and CLIENT-CLI-V0-FREEZE.md.

Local Daemon/API v0 is a frozen loopback-only bearer-token HTTP adapter over the same Client results. It snapshots a validated profile at startup and does not cache, refresh, rank, select, or execute endpoints. See LOCAL-DAEMON-API-V0-PLAN.md and LOCAL-DAEMON-API-V0-FREEZE.md.

Read-Only Target Viewer v0 is a frozen loopback same-origin session proxy and static UI for inspecting /v0/target results. It keeps the daemon token in viewer process memory, renders endpoint strings inertly, and never selects or executes endpoints. See READ-ONLY-TARGET-VIEWER-V0-PLAN.md and READ-ONLY-TARGET-VIEWER-V0-FREEZE.md.

The stable result and error-code contract is documented in VALIDATION.md.

Contributing

See CONTRIBUTING.md. Contributions are licensed under MPL-2.0 and require a Developer Certificate of Origin sign-off.