DP5 - Decentralized Namespace
| ID: | ML-Draft-012 |
| Title: | DP5 - Decentralized Namespace |
| Status: | approved |
| Authors: | The Meta-Layer Initiative |
| Date: | 2026-08-05 |
| Workgroup: | dp5-decentralized-namespace |
| Revision: | 02 |
| Pages: | 12 |
| Words: | 5757 |
DP5 defines naming as core infrastructure for identity, ownership, and coordination, not a platform feature. It introduces decentralized, portable identifiers—meta-domains and personal IDs—that anchor people, communities, and artifacts across systems. The draft outlines a full-stack namespace model spanning syntax, resolution, control, meaning, and history, ensuring names remain interpretable and resistant to capture. It addresses threats like spoofing, squatting, and semantic drift, and defines resolution as a governed, inspectable process rather than a hidden lookup. Without DP5, identity remains rented—and everything built on top of it inherits that fragility.
Claim your space in the Meta-Layer — meta-domains and personal identifiers give you sovereign, portable identity, owned by you, not a platform.
This ML-Draft articulates Desirable Property 5 (DP5) as the condition under which people, communities, agents, artifacts, and spaces can be named, addressed, discovered, traded, and governed across the Meta-Layer without dependency on a single platform or registry.
DP5 introduces meta-domains and personal identifiers as sovereign, portable identity and addressability primitives. These identifiers allow participants to claim space in the Meta-Layer, link that space to existing web domains or decentralized identifiers, and use names as anchors for identity, ownership, trust, commerce, and governance.
The core claim is simple:
Meta-domains and personal identifiers give participants sovereign, portable identity – owned by them, not rented from a platform.
The Meta-Layer introduces a decentralized namespace system where identity is not merely a login and addressability is not merely a URL. Names become portable anchors for people, ideas, artifacts, communities, overlays, smart tags, and virtual spaces across the open web.
DP5 guides implementation, governance design, and future ML-RFC development for decentralized naming, meta-domain registration, namespace rights, conflict resolution, and interoperable naming semantics.
Why namespaces matter.
The contemporary web depends on naming systems, but most participant-facing names are not truly participant-owned. Handles, usernames, pages, tags, groups, channels, and platform identities are typically rented from centralized services. They can be revoked, shadowed, duplicated, impersonated, renamed, captured, or made non-portable by the platforms that host them.
This creates recurring failures:
DP5 reframes naming as civic infrastructure. A decentralized namespace is not only a convenience layer. It is the addressability substrate for identity, agency, data, commerce, interoperability, and governance.
Without DP5, the Meta-Layer cannot reliably answer basic questions:
Participants build identity around handles or pages that can be revoked, hidden, renamed, or monetized by platform operators.
Failure mode: identity continuity depends on platform permission.
Dominant registries or intermediaries control which names are valid, visible, or resolvable.
Failure mode: decentralized naming becomes centralized gatekeeping.
Attackers create visually, semantically, or structurally similar names to mislead participants.
Failure mode: names become attack surfaces for scams and trust abuse.
Valuable names are claimed not for use, but to extract rents from future participants or communities.
Failure mode: addressability becomes enclosure before public value can form.
A name carries one meaning in one system and a different meaning elsewhere without signaling.
Failure mode: identity, trust, or ownership claims are misinterpreted across contexts.
Multiple naming systems emerge without interoperability or conflict-resolution pathways.
Failure mode: participants cannot know which namespace claims are authoritative, compatible, or contested.
Objects, tags, posts, paths, and digital artifacts cannot be reliably referenced across systems.
Failure mode: knowledge, provenance, and ownership degrade because identifiers are not stable.
AI agents, organizations, bots, and autonomous systems operate without clear namespace rights or management structures.
Failure mode: non-human actors become hard to distinguish, govern, or hold accountable.
These eight patterns are elaborated in operational detail under Namespace Attack Taxonomy, which adds resolver capture, ownership laundering, registry amnesia, and namespace flooding as concrete attack surfaces with required responses. The distinction is one of altitude rather than kind: this section names the structural failures a namespace must be designed against; the taxonomy names how those failures are actually attempted.
Names in the Meta-Layer must be portable, resolvable, governable, and resistant to capture. A namespace that cannot preserve identity, meaning, and control across systems becomes another platform dependency.
DP5 treats names as more than labels. Names are anchors for participation, reference, ownership, navigation, reputation, and coordination.
A DP5-aligned namespace must therefore support:
DP5 is enacted through mechanism families that together turn a name from a label into an accountable, resolvable, governed object. Each family addresses a distinct question that a namespace must be able to answer, and a namespace that answers some but not others will exhibit the failure modes named above.
The structural condition uniting these is that a name must never assert more trust than it can demonstrate. Every mechanism in this draft exists to close a gap between what a name appears to mean and what can actually be verified about it. Where verification is unavailable, the mechanism's obligation is to signal uncertainty rather than to default to trust — which is why explicit state, resolver provenance, and visible degradation recur throughout.
Meta-domains address virtual spaces within the Metaweb, similar to how traditional domains address web spaces.
A meta-domain may refer to:
Example forms include:
boeing.com.web4apple.com.web4example.com.meta<label>.example.com.metaMeta-domains can link seamlessly to the broader web while functioning within the Metaweb overlay framework.
Personal identifiers address participants and personas, similar to email addresses, handles, or DIDs, but portable across Meta-Layer contexts.
Example:
shiftshapr.web4@jaime@jaime/artifact99Personal identifiers may be connected to decentralized identifiers (DIDs), credentials, proof-of-humanity mechanisms, or zone-specific identity contexts.
Digital artifacts may serve as identifiers, assets, or NFTs that can be bought, sold, transferred, authenticated, or referenced.
Artifacts may include:
Name chains provide structured, semantic identifiers such as:
@user/object@community/tag@publisher/claimName chains function as URI-like trust anchors, combining identity verification, object authentication, and conflict resolution pathways.
DP5 also recognizes publisher-controlled decentralized URI patterns, such as:
/.well-known/trust.txtThese allow trusted data to be anchored under existing publisher-controlled domains without requiring centralized registries.
This section defines DP5 as a runtime-resolvable, multi-layer namespace system rather than a static registry.
A DP5-compliant namespace operates across coupled layers:
Defines canonical forms, label rules, and human-readable structure.
Examples:
<label>.example.com.meta@user@user/objectRequirement:
Failure mode: syntactic ambiguity.
Maps names → entities (people, agents, artifacts, spaces).
Resolution MUST include:
Resolution states MUST be visible:
Failure mode: invisible resolution override.
Defines who can act on a name.
Control may derive from:
Control MUST be:
Failure mode: ghost control (no accountable owner).
Defines what the name means in context.
Includes:
Meaning MUST:
Failure mode: semantic drift.
Names are not static. They evolve.
Systems MUST preserve:
Failure mode: history erasure.
These five layers together define a full-stack namespace. Most systems today only implement 1–2 layers. DP5 requires all five.
DP5 requires a shared resolution model so names can be interpreted consistently across tools, overlays, registries, and communities.
A reference resolution flow SHOULD include:
Resolution must therefore be understood as a governed process, not a hidden lookup.
A minimal response object SHOULD include:
{
"name": "@jaime/artifact99",
"canonical": "@jaime/artifact99",
"entity_type": "artifact",
"controller": "did:example:123",
"state": "verified",
"resolver": "registry.example.meta",
"resolved_at": "2026-04-26T00:00:00Z",
"provenance": {
"snapshot": "graph-snapshot-v12.json",
"checksum": "sha256:...",
"signatures": ["..."]
},
"policy": {
"transferable": true,
"dispute_status": "none",
"zone_constraints": []
}
}
Failure mode: opaque resolution, where a name appears trustworthy but participants cannot inspect how that trust was produced.
DP5-aligned systems SHOULD expose name lifecycle states explicitly.
A name may move through the following states:
available → claimed → provisional → verified → active
↘ disputed → resolved
↘ quarantined → restored / retired
active → transferred → active
active → expired / abandoned → available or archived
active → forked → parallel-governed state
Core states:
State transitions MUST produce receipts where they affect ownership, resolution, trust, or participant expectations.
Failure mode: state invisibility, where participants cannot tell whether a name is safe, contested, provisional, or compromised.
DP5 treats names as attack surfaces. Naming systems concentrate trust, discovery, ownership, and memory, making them attractive targets for adversarial actors.
Common attacks include:
Attackers register visually or semantically similar names to impersonate trusted entities.
Examples:
appIe.meta using confusing characterspaypaI.web4Required response: similarity detection, warnings, and dispute pathways.
Actors claim names for speculative rent extraction rather than use.
Required response: reservation rules, renewal logic, staking, decay, or community challenge mechanisms.
A resolver becomes a de facto authority by controlling defaults.
Required response: multi-source resolution, resolver provenance, and fallback transparency.
A name is transferred repeatedly to obscure harmful history, evade sanctions, or reset trust.
Required response: transfer receipts and visible lineage.
A name is used in a new context to imply trust or meaning it did not originally carry.
Required response: semantic profiles and degradation signaling.
Automated or AI actors adopt names that imply human identity, authority, or community status.
Required response: mandatory entity classification and controller binding.
A registry loses or suppresses prior state, disputes, or ownership transitions.
Required response: append-only logs, snapshots, checksums, and independent archival.
Attackers create many names to overwhelm discovery, governance, or trust review.
Required response: rate limits, economic friction, proof thresholds, and anti-spam containment.
DP5 does not replace existing naming systems. It defines how meta-layer naming can interoperate with them.
DNS provides global resolution and familiar domain semantics, but is vulnerable to centralized registrar control and does not natively express trust state, provenance, or community governance.
DP5 can use DNS-linked anchors while adding overlay-level trust semantics.
DIDs support decentralized identity and controller binding, but may be difficult for ordinary participants to read or remember.
DP5 can bind human-readable names to DID-backed controllers.
Blockchain naming systems support ownership and transfer, but often emphasize asset ownership more than contextual governance, dispute visibility, or semantic profiles.
DP5 can learn from these systems while requiring visible state, provenance, and governance.
Ordinal inscriptions and BRC333-shaped artifacts can anchor durable metadata and namespace records.
DP5 can use inscription ordering, registry snapshots, and graph facts to support canonicality and provenance.
Publisher-controlled paths such as /.well-known/trust.txt allow existing domain holders to publish trust-relevant metadata without centralized registry dependency.
DP5 can compose these with meta-domain records and overlay resolution.
The goal is not one namespace to rule them all. The goal is interoperable naming with explicit trust semantics.
A Meta-Domain Registry may operate as a public ingest and registry service for meta-domains, SNS-shaped JSON, BRC333-related ordinals, and related naming artifacts.
A registry can include:
Such a registry SHOULD distinguish between:
Candidate logs may include:
.meta tokensA registry SHOULD provide:
Where ordinal inscriptions are used, canonicality SHOULD be determined by documented ordering rules, such as lowest qualifying inscription number where adopted, rather than arbitrary string ordering.
Registries SHOULD support pluggable indexers and resolution sources so that namespace infrastructure does not depend on a single data provider.
Failure mode: indexer dependency, where resolver integrity depends on one commercial or centralized API.
DP5 supports concrete registration rules for product-level namespaces.
A v1 product canonical form may be:
<label>.example.com.meta
Where:
<label> is the registrant-chosen segmentexample.com.meta is a configurable suffix or canonical parentA valid label SHOULD satisfy:
a-z, 0-9, -)-Label-only validation:
^(?!-)([a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?)$
Full-domain validation example:
^(?!-)([a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?)\.example\.com\.meta$
Regex alone is insufficient. Reserved-name and integer checks must be separate.
label as the substring before the configured suffix./^\d+$/.label.toLowerCase() is in the reserved set."In use" means that a record already exists with the same normalized domain string under the applicable active status rule.
Storage and comparison SHOULD normalize to lowercase.
Tradeable meta-assets allow participants to exchange digital spaces, objects, and names, fostering virtual commerce and community formation.
However, tradeability must remain bounded by trust, provenance, and governance.
DP5 requires:
A name may be tradable, but the trust attached to the name cannot be treated as a blank commodity. Reputation, history, and community meaning must remain visible across transfer.
This section defines interface-level namespace governance, aligning with the Meta-Layer's overlay architecture.
Namespaces are not governed only in registries. They are governed at the point of interaction via overlays, filters, and community rules.
Participants MUST be able to:
Failure mode: invisible governance.
Meta-layer overlays SHOULD expose:
This turns naming into a live civic surface, not a backend database.
Failure mode: governance hidden behind APIs.
Communities MUST be able to:
Failure mode: centralized naming authority.
All conflicts MUST be visible as states, not silent overrides:
Failure mode: silent winner-take-all resolution.
DP5 aligns with the principle that governance must live at the interface layer, where users experience identity and trust.
Browser overlays act as civic membranes where naming rules become visible, contestable, and enforceable in real time.
Failure mode: governance only enforced off-screen.
Namespaces concentrate value at three points, and each attracts a distinct form of capture. Understanding where the money and leverage sit explains why DP5's structural requirements — multi-source resolution, visible state, transfer receipts, registry snapshots — are economic interventions rather than technical preferences.
Registration is where scarcity is manufactured. Names are a positional good: @jaime has value precisely because no one else can hold it. Any registry therefore issues a monopoly with every name, and holds the power to define what may be issued, reserved, priced, or refused. Squatting is the market's rational response to unpriced scarcity, and anti-squatting mechanisms — staking, renewal, decay, community challenge — are attempts to price holding without pricing out legitimate participants. The tension is unresolved and named as such under Open Questions and Future Work: mechanisms that deter hoarding also burden the communities and individuals least able to pay.
Resolution is where the deepest power sits, and it is the least visible. A resolver that becomes the default for most clients does not need formal authority over the namespace; it exercises effective authority by determining what most participants see. This is the same dynamic through which DNS registrars and app-store search became control points despite holding no formal ownership. DP5's requirement for multi-source resolution and exposed resolver provenance exists because default position is the asset, and because capture at this layer is invisible to the participant by construction. A single commercial indexer dependency reproduces platform risk under decentralized branding.
Transfer is where accountability leaks. A tradeable name accumulates trust and can then be sold, which means reputation built by one party can be exercised by another. Ownership laundering is not an exotic attack but the predictable arbitrage of this gap: buy the history, discard the obligation. Transfer receipts and visible lineage exist to make trust non-fungible even where the name is fungible.
Several further pressures recur:
Example: A registry publishes open registration rules and charges nominal fees, while its own resolver ranks names it has commercial relationships with above equally valid alternatives. Nothing in the naming rules changed; the namespace was captured at the resolution layer.
Why this matters: Naming power is exercised through defaults, ordering, and memory far more often than through explicit denial. DP5 therefore requires that resolution be inspectable, state be explicit, and history be preserved — not because operators are presumed hostile, but because these are the surfaces where capture is otherwise undetectable.
Community submissions and aligned work point to several recurring signals:
These signals indicate that DP5 is not only about naming people. It is about naming the structure of the Metaweb itself.
Namespaces fail slowly and then all at once. For long periods a naming system appears healthy — names resolve, transfers settle, disputes are rare — while the conditions for its capture accumulate beneath the surface. By the time failure is visible, the namespace is usually load-bearing for identity, commerce, and provenance across many systems, which makes correction expensive and migration nearly impossible.
Predictable degradation paths include:
These paths compound in a characteristic sequence. Resolver consolidation makes state flattening consequential, because a single resolver's rendering becomes the participant's only view. Snapshot gaps make ownership laundering undetectable. Undetectable laundering makes semantic profiles unreliable, which makes state signals meaningless, which returns participants to judging names by appearance — the precise condition DP5 exists to escape.
Two properties make namespace failures unusually severe:
Irreversibility of trust transfer. Once a name with accumulated trust has been used to deceive, the harm is distributed across everyone who relied on it, and cannot be recalled by revoking the name. Prevention dominates remedy.
Lock-in by dependency. Names become embedded in links, credentials, contracts, archives, and other systems' data. A namespace that must be abandoned takes that dependent structure with it. This is why forkability, snapshot integrity, and cross-namespace interoperability are safety features rather than conveniences.
DP5 therefore requires safeguards designed in advance:
Failure is expected. Failure that becomes visible only after the namespace is load-bearing is not. A DP5-aligned namespace is one where the concentration of resolution power, the erosion of state visibility, and the loss of registry memory are all observable while they are still reversible.
DP5 is foundational and interdependent.
Two couplings deserve emphasis, because DP5 is where they become concrete rather than aspirational.
DP3 governs the namespace itself. Reserved sets, dispute procedures, quarantine thresholds, fork legitimacy, and canonicality rules are all governance artifacts, subject to DP3's requirements for tiered decisions, receipts, visible diffs, bounded emergency authority, and memory. A registry that changes its reserved set or ordering rules without a traceable, contestable process has made a governance decision outside governance.
DP23 determines who the namespace is for. Unicode support, multilingual naming, and script integrity are the difference between a namespace that serves a global population and one that serves the subset writing in Latin script. This sits in direct tension with spoofing resistance, since script diversity expands the confusable space — a tension DP5 names openly rather than resolving by exclusion.
A failure in DP5 propagates upward. If names cannot be trusted, ownership cannot be trusted, identity fragments, and interoperability becomes deception.
DP5 does not:
DP5 further does not:
Failure mode: namespace maximalism, where DP5 is invoked to justify a single canonical registry, on the grounds that coherence requires centralization. DP5 requires interoperable naming with explicit trust semantics, which is the opposite claim.
DP5 defines conditions under which naming remains interoperable, governable, and accountable across systems.
This section states testable compliance criteria rather than descriptive aspirations.
A system claiming DP5 alignment MUST pass the following checks:
Test: same input → same validity result everywhere
Test: user can inspect where resolution came from
Every name MUST expose state:
Test: UI or API returns state metadata
Test: ownership lineage query returns full chain
Test: same name resolves meaningfully in multiple contexts
Test: registering visually similar name triggers warning or constraint
Test: past state can be reconstructed with checksum validation
Test: dispute creates visible state transition
Test: entity type is explicitly encoded and exposed
These criteria transform DP5 from a principle into a verifiable standard.
These conditions define the minimum viable namespace layer of the Meta-Layer.
DP5 identifies key frontier problems:
How do independent naming systems interoperate without collapsing into monopoly or fragmentation?
How can meaning travel with names across cultural, linguistic, and technical contexts?
What mechanisms balance open access with protection against speculative enclosure?
How should agent identities evolve as they gain autonomy, persistence, and economic activity?
What legitimacy models determine when a community can fork naming rules?
How do we balance usability with cryptographic robustness?
How do we support multilingual naming without increasing spoofing risk?
What pricing, staking, or decay mechanisms prevent hoarding while preserving ownership?
What measures of resolver diversity are meaningful, and what interventions are available when resolution traffic concentrates without any formal change in authority?
What happens to names, artifacts, and communities when a registry, resolver, or community steward ceases to operate, and how is continuity established without a central custodian of last resort?
These questions define the path toward ML-RFC maturation.
Progression toward ML-RFC maturity should include:
Stable portions may be promoted first, especially canonical form rules, validation logic, and registry state semantics.
DP5 is the claim that participants, communities, agents, and artifacts deserve names they can carry across the Meta-Layer.
Without sovereign names, identity is rented, ownership is fragile, and discovery remains platform-shaped.
With DP5, people can claim space, communities can preserve continuity, artifacts can be addressed, and the Metaweb can become navigable without surrendering naming power to a single platform.
DP5 turns names into civic infrastructure.
To claim your space in the Meta-Layer is not merely to register a label. It is to anchor presence, meaning, and accountability in a shared world.