Define UDNA as a Trust & Communication Primitive (Scope, Non-Goals, and Relationship to Existing W3C Work)

[amir-hameed-mir]

Proposal: Define UDNA as a Trust & Communication Primitive

What Is UDNA?

Universal Decentralized Network Architecture (UDNA) is a trust and communication primitive that operates above transport protocols (e.g., HTTP, QUIC) and below applications (e.g., ActivityPub, Matrix, Solid).

UDNA provides:

• DID-based addressing (who is communicating)
• Trust-aware routing and communication semantics (how communication is coordinated)
• Standards composition, acting as a coordination layer between:
  • W3C identity standards
  • IETF transport and security standards

UDNA is intended to leverage existing specifications, not replace them.

---

What UDNA Is Not

UDNA is explicitly not:

• ❌ A replacement for DID, ActivityPub, Matrix, or Solid
• ❌ A new cryptographic protocol or suite
• ❌ A physical or packet-level networking layer
• ❌ An application framework

---

Simple Analogy (Non-Normative)

Think of UDNA as a postal service for decentralized systems:

• Applications → Letters with specific content (social posts, messages, data)
• UDNA → Addressing, delivery routes, and trust verification
• Transport → Roads and vehicles (HTTP, TLS, QUIC)

This analogy is intended only to clarify layering, not to define behavior.

---

Why This Matters Now

Current decentralized protocols often define their own addressing, trust, and routing mechanisms, even when built on shared standards.

A common primitive like UDNA could enable:

• ActivityPub systems to route or reference Matrix users via shared identity
• Solid pods to resolve and verify DIDs consistently across applications
• New decentralized applications to avoid rebuilding trust infrastructure

---

Immediate Next Steps (Initial Proposal)

Initial work is expected to be exploratory and lightweight:

• Create this issue
• Draft a simple architecture diagram
• Document 2–3 concrete use cases
• Identify potential early adopters or test environments

---

What Success Looks Like (Indicative)

• 1 month: Clear, shared definition document
• 2 months: Minimal prototype using:
  • One W3C specification (e.g., DID)
  • One IETF specification (e.g., HTTP)
• 3 months: First external contributor or collaborator

These are indicative milestones, not commitments.

---

Discussion Starters

Feedback is especially welcome on:

• Does this scope feel appropriate for a CG discussion?
• Which existing protocol or use case should be explored first?
• Are there related efforts we should align with or learn from?

---

Status

Proposal / Seeking Community Input

Author: Amir Hameed Mir
Goal: Establish shared understanding before advancing toward formal work items