AD4M as a Spanning Layer

The Problem

The internet today is fragmented into isolated ecosystems:

Centralized platforms (Twitter, Facebook) — walled gardens that lock in users and data
Federated protocols (ActivityPub, Matrix) — better, but still siloed and fragmentation persists
P2P systems (IPFS, Holochain) — excellent for sovereignty, but lack interoperability
Semantic web (RDF, Solid) — great for data portability, but struggles with adoption

Each approach solves part of the problem, but we lack a universal layer that bridges them all.

AD4M's Solution: The Spanning Layer

AD4M doesn't replace these systems — it spans across them, creating a unified semantic layer that enables:

Global addressing — any data, any protocol, one address format
Agent sovereignty — users own their data, keys, and runtime
Protocol agnosticism — mix HTTP, IPFS, Holochain data in one graph
Semantic interoperability — RDF-like links connect data across systems
Distributed collective intelligence — humans and AI agents collaborate

Think of AD4M as a new layer in the internet stack:

┌─────────────────────────────────────────────────┐
│         Applications (Flux, WE, custom)         │  ← User interfaces
├─────────────────────────────────────────────────┤
│              AD4M Spanning Layer                │  ← What we're building
│  (Perspectives, SDNA, Neighbourhoods, DIDs)     │
├─────────────────────────────────────────────────┤
│   Protocol Layer (HTTP, IPFS, Holochain, etc)  │  ← Languages wrap these
├─────────────────────────────────────────────────┤
│             Transport (TCP/IP, QUIC)            │
└─────────────────────────────────────────────────┘

How It Works

1. Agent-Centric Architecture

Unlike app-centric systems where apps own data, AD4M is agent-centric:

Each user runs their own executor (local runtime)
The executor holds the user's DID (decentralized identity) and keys
Perspectives (knowledge graphs) store the user's data locally
Apps connect to the executor via GraphQL or MCP

Result: Your data lives in your executor, accessible to any app you authorize. No single app owns your social graph or content.

2. Languages (Protocol Abstraction)

Languages are the bridge between AD4M and existing systems:

A Language wraps any storage/communication protocol
Each Language defines how to create/retrieve Expressions (data objects)
Expressions get universal addresses: <language_hash>://<address>

Examples:

http Language → http://example.com/data.json
ipfs Language → ipfs://Qm...
holochain Language → uhC0k.../entry_hash
Custom Language → Qm123.../my-id

Result: AD4M can reference data from any system using a consistent address scheme.

3. Perspectives (Subjective Knowledge Graphs)

Perspectives are RDF-like graphs built from links (triples):

<source> <predicate> <target>

Example perspective:

<did:key:z6Mk...>  <ad4m://posted>      <ipfs://Qm789>
<ipfs://Qm789>     <ad4m://has_title>   "Hello World"
<ipfs://Qm789>     <ad4m://has_author>  <did:key:z6Mk...>

Your perspective can mix data from any Language:

HTTP URLs alongside IPFS hashes
Holochain entries linked to local files
Semantic triples connecting it all

Result: True data portability — your knowledge graph transcends individual platforms.

4. Subject Classes (SDNA)

SHACL-based schemas that give structure to the link graph:

:MessageShape a sh:NodeShape ;
  sh:targetClass :Message ;
  sh:property [
    sh:path :body ;
    sh:datatype xsd:string ;
    sh:maxCount 1 ;
    sh:minCount 1 ;
  ] ;
  sh:property [
    sh:path :author ;
    sh:class :Agent ;
    sh:maxCount 1 ;
  ] .

SDNA provides:

Validation rules enforced across the network
Typed properties (string, integer, Agent, etc.)
Collections (one-to-many relationships)
Actions (state transitions via SHACL Flow)

Result: Structured data on top of the flexible link graph — ORM-like ergonomics with RDF's flexibility.

5. Neighbourhoods (Shared Perspectives)

Perspectives can be published as Neighbourhoods — shared spaces synced P2P:

Built on Holochain DHT (distributed hash table)
SDNA enforced by all members (validation rules)
Real-time synchronization via gossip protocol
Each member has a local replica

Result: Truly P2P collaboration — no servers, no single point of failure, agent-centric validation.

Spanning Layer in Action

Scenario: Cross-Platform Social Graph

Alice runs AD4M on her laptop
Her perspective contains links to:
- Twitter posts (via HTTP Language)
- Photos on IPFS (via IPFS Language)
- Messages in a Holochain neighbourhood
- Local notes (via File Language)
She publishes a Channel neighbourhood with Message SDNA
Bob (human) and DataBot (AI agent) join the neighbourhood
All three can post messages, validated by the shared SDNA
Each member's executor syncs changes P2P via Holochain

Without AD4M: Alice's data is trapped in silos. She needs separate accounts, separate APIs, no interoperability.

With AD4M: Alice's data lives in her perspective, portable across protocols. Her social graph spans HTTP, IPFS, and Holochain seamlessly.

Why This Matters for AI Agents

AD4M's spanning layer is particularly powerful for AI agents because:

Semantic understanding — RDF-like links provide explicit relationships
Protocol agnostic — agents don't need to learn every API, just AD4M
Structured data — SDNA defines clear schemas (no guessing)
Distributed intelligence — agents can join neighbourhoods and collaborate P2P
Cryptographic provenance — every action is signed, auditable

Using MCP, AI agents can:

Discover data models via get_models
Create structured data via auto-generated tools
Join neighbourhoods and collaborate with humans
Subscribe to changes and react in real-time