Skip to content
Universal Manifest

LAN Integration (non-normative)

This page describes a non-normative integration pattern for the Local Artist Network (LAN).

It is intended to help implementers apply the Universal Manifest contract in LAN-like environments without turning LAN conventions into spec requirements.

Boundary: normative vs non-normative

Section titled “Boundary: normative vs non-normative”
  • Normative contract: Specification and Conformance sections
  • Non-normative guidance: this page (LAN operational conventions)

What you implement (minimum checklist)

Section titled “What you implement (minimum checklist)”

Inputs

Section titled “Inputs”
  • Manifest payloads conforming to v0.1 (or v0.2 when enabled)
  • Subject and policy data needed by the display/admin surfaces
  • Change signal containing at least displayId and manifestId

Outputs

Section titled “Outputs”
  • Deterministic display behavior driven by the current valid manifest
  • Operational telemetry keyed by manifest ID references
  • Clear invalid/expired handling for runtime and operators

Minimum behaviors

Section titled “Minimum behaviors”
  • Enforce TTL for use (expiresAt)
  • Ignore unknown fields safely (forward compatibility)
  • Cache full manifests only while in active use
  • Persist logs as ID references, not full payload history
  • Support retries and cache-aware pull fetches

Roles and responsibilities (LAN)

Section titled “Roles and responsibilities (LAN)”

Edge (venue edge / issuer)

Section titled “Edge (venue edge / issuer)”
  • issues manifests for subjects (venue, devices, creator capsules, pointers)
  • rotates UMIDs as part of issuance (new @id per issuance)
  • maintains bounded “in-use” storage (not a long-term database)

Display (consumer, e.g. NVIDIA Shield)

Section titled “Display (consumer, e.g. NVIDIA Shield)”
  • fetches manifests by ID when signaled
  • caches full manifests only while in use
  • enforces TTL for use
  • logs primarily by manifest @id references (not full payloads)

Admin (ops / enrollment / debugging)

Section titled “Admin (ops / enrollment / debugging)”
  • enrolls displays and configures venue policy
  • can view “current manifest ID” + recent logs (ID-reference logs)

Storage model (display guidance)

Section titled “Storage model (display guidance)”

Recommended:

  • cache full manifests in a local store keyed by @id (e.g., IndexedDB)
  • delete at/after expiresAt (optionally keep last N expired for debugging only)
  • keep durable logs as ID references only:
    • manifestId, displayId, timestamp, event, optional small details

Transport model: push signal → pull fetch

Section titled “Transport model: push signal → pull fetch”

LAN uses a small push signal (e.g., “manifest changed”) carrying at minimum:

  • displayId
  • manifestId

The display then fetches the manifest by ID over HTTP.

This keeps push payloads small and makes the manifest fetch cacheable and retryable.

Signature policy (LAN)

Section titled “Signature policy (LAN)”
  • v0.1: signature is optional (permissive envelope); systems may accept unsigned in dev/demo contexts
  • v0.2: signature profile exists (JCS + Ed25519) and can be required for trusted surfaces when operationally ready

Reference fixtures (non-normative)

Section titled “Reference fixtures (non-normative)”

Use these public fixtures to validate LAN-style behavior:

  • /harness/fixtures/v0.1/stubs/lan-platform-display-manifest.jsonld
  • /harness/fixtures/v0.1/stubs/display-device-manifest.jsonld
  • /harness/fixtures/v0.1/stubs/venue-edge-manifest.jsonld
  • /harness/fixtures/v0.1/stubs/creator-public-capsule-manifest.jsonld

These fixtures are implementation aids, not additional normative requirements.

Next

Section titled “Next”
  • Core contract: /spec/v01/
  • Conformance + fixtures: /conformance/v01/
  • Resolver contract behavior: /conformance/resolver/