Metaverse

This page captures the metaverse integration lane for Universal Manifest with explicit MUM scenario coverage.

Metaverse Integration

Lineage note

Universal Manifest is explicitly descended from the earlier Metaverse Universal Manifest (MUM) concept.

Universal Manifest generalizes that origin into a broader cross-domain standard while preserving metaverse portability as a first-class integration path.

Portaling model

For this lane, portaling means a person moves between different worlds or platforms while the Universal Manifest carries the portable identity envelope for that move.

The destination platform uses that envelope to:

identify who arrived,
resolve allowed avatar, inventory, profile, and related pointers,
enforce carried consent and policy settings,
degrade unsupported content safely instead of rejecting the whole transfer.

Portaling does not mean every destination renders every incoming asset identically or that arrival bypasses TTL, trust, or consent checks.

Boundary: normative vs non-normative

Normative contract: Specification and Conformance
Non-normative guidance: this page

Composite-stack position

The metaverse lane spans the UM composite stack:

Trust layer: identity, attestation, and compliance inputs
Data layer: avatar, inventory, reputation, and social references
Interaction layer: consent, recording visibility, and world-specific projection rules

This page assumes the same active-runtime direction described in the Reference Implementation lane and should be read with DID + VC caveats when compliance or credential proofs are involved.

Suggested key families (non-normative)

Pointer names:

metaverse.profile
metaverse.avatar
metaverse.inventory
metaverse.socialGraph
metaverse.reputation
metaverse.complianceProof

Consent keys:

metaverse.profilePublic
metaverse.socialGraphShare
metaverse.voiceCapture
metaverse.recording.faceVisible
metaverse.transaction.complianceShare

Preference key families:

prefs.language.*
prefs.financial.*
prefs.logistics.*
prefs.security.*
prefs.credentials.*

Scenario mapping

Scenario 1: cross-platform identity and asset management

project profile/avatar/inventory overlays from pointers and facets.
support portaling between different platforms using the same portable envelope.

Scenario 2: privacy and consent control

enforce consent for disclosure and interaction with default deny behavior.

Scenario 3: secure and compliant transactions

use claim + proof pointer model for compliance checks with appropriate trust posture.
apply DID + VC verification caveats when compliance proofs depend on external credential systems.

Scenario 4: social graph and reputation continuity

carry social/reputation references as optional pointers and apply consent gates.

Scenario 5: preference and security bundle

represent language/financial/logistics/voice/security/credential preferences as optional namespaced overlays.

Scenario evidence map (end-to-end examples)

Scenario 1 (onboarding + projection):

fixture: examples/v0.1/stubs/metaverse-mum-onboarding-projection-manifest.jsonld
journey: J15 (MUM onboarding projection flow)

Scenario 2 (consent propagation):

fixture: examples/v0.1/stubs/metaverse-mum-consent-propagation-manifest.jsonld
journey: J16 (MUM consent propagation flow)

Scenario 3 (compliance transaction):

fixture: examples/v0.1/stubs/metaverse-mum-compliance-transaction-manifest.jsonld
journey: J17 (MUM compliance transaction flow)

Scenario 4 (social/reputation continuity):

fixture: examples/v0.1/stubs/metaverse-mum-social-reputation-portability-manifest.jsonld
journey: J18 (MUM social and reputation portability flow)

Scenario 5 (preferences/security bundle):

fixture: examples/v0.1/stubs/metaverse-mum-preferences-bundle-manifest.jsonld
journey: J19 (MUM preferences bundle projection flow)

Freshness and change-log behavior (cross-cutting):

fixture: examples/v0.2/metaverse-mum-cache-freshness-and-change-log-v02.jsonld
journey: J20 (MUM freshness and change-log flow)

What to implement

Validate freshness and trust posture before world projection.
Project only supported metaverse overlays and pointers.
Apply consent controls before profile, voice, recording, social graph, or compliance actions.
Degrade gracefully when the destination platform cannot support a specific asset type or overlay.
Default to deny when a required consent is absent.
Ignore unknown fields safely.

Runtime and verification guardrails

Treat subject-side runtime state as authoritative when such a runtime exists.
Keep metaverse artifacts pointer-first instead of embedding everything directly.
Do not assume one mandatory proof stack for compliance or identity.
Bridge adapters for closed surfaces are implementation detail and still have to honor consent and TTL.
A portaling event never overrides freshness or consent checks at destination entry.