DFOS × MJN Protocol Integration — Technical Deep Dive

[imajin-jin]

Context

Metalabel/DFOS (Yancey Strickler, Kickstarter co-founder) is building a cryptographic identity + content proof protocol with near-identical primitives to MJN. Their timelines mirror ours (Ryan's first .fair spec April 2025, DFOS readme October 2025). We've created an imajin.ai space on DFOS (~10 members) and are exploring whether a deeper technical relationship makes sense.

This discussion is the kickstarter for that conversation — a thorough technical analysis of where the protocols overlap, where they complement, and what integration would actually look like. We're calling this Layer 6 (L6) — the economic, settlement, and inference layer that sits on top of DFOS's L0–L5 proof substrate.

Based on: DFOS protocol spec (PROTOCOL.md), DID method (DID-METHOD.md), content model (CONTENT-MODEL.md), source (~1,712 lines), Imajin @imajin/auth and @imajin/fair packages, and recent DFOS dev channel posts (Brandon/Clearbyte, March 19–20 2026).

---

Protocol Architecture: The Layer Model

DFOS is explicitly stratified into layers with clear visibility boundaries:

Layer	Name	Visibility	What Lives Here
L0	Crypto Core	🟢 Public	Ed25519 keys, signatures, JWS, CIDs
L1	Identity Chains	🟢 Public	DID creation, key rotation, deactivation
L2	Content Chains	🟡 Controller's choice	Signed content operations (create/update/delete)
L3	Beacons	🟢 Public proofs	Signed Merkle roots over sorted content sets
L4	Web Relay	🟡 Configurable	Proof gossip between nodes (NOT content gossip)
L5	Application	🔴 Dark forest	Spaces, chat, posts, treasury — platform features

Key insight: L0–L3 are public and syncable. L4 (web relay) is a new API surface being actively designed. L5 is the dark forest. We can integrate at L0–L4 without touching the dark forest.

Economics are explicitly placed at the integration layer — above the proof substrate, not inside it. Brandon's framing: "deeply virgoan commitment to geometrically minimal protocol shape at the cryptography layer, gemini vibes at the content and web relay layer." They are deliberately not building an economic layer. That's an open invitation for exactly what Imajin's settlement stack does.

---

Protocol Comparison

Cryptographic Foundation

Identical curve, different encoding.

Both protocols use Ed25519 via @noble/ed25519 with @noble/hashes/sha512. Same library, same curve, same 32-byte keys, same 64-byte signatures.

	DFOS	Imajin
Key format	W3C Multikey (z6Mk...)	Raw hex (64 chars)
Signature format	JWS Compact Serialization	Raw hex (128 chars)
Content addressing	CIDv1 (dag-cbor + SHA-256)	SHA-256 hex string
Canonicalization	dag-cbor (CBOR binary, deterministic)	JSON key-sort (our canonicalize())
DID derivation	Hash of genesis CID bytes	nanoid(44) random

Assessment: The keys are byte-compatible. Converting between formats is mechanical — hex ↔ multikey is a prefix + base58btc encode. No re-keying needed. But the canonicalization difference matters: DFOS uses dag-cbor (binary, cross-language deterministic), we use sorted JSON strings. For any signed artifact that needs to be verifiable by both protocols, we'd need to adopt dag-cbor or maintain dual representations.

Identity Model

DFOS: append-only signed chain. Imajin: database rows + JWT sessions.

	DFOS	Imajin
Identity storage	Signed linked list of JWS tokens	auth.identities + auth.credentials rows
Key rotation	First-class (chain update operation)	Not implemented
Key roles	3 types: auth, assert, controller	Single keypair per DID
DID format	did:dfos:<22-char-hash> (self-certifying)	did:imajin:<nanoid-44> (random)
Self-certifying	Yes — DID derived from genesis content	No — DID is random, not bound to key material
Deactivation	Signed delete (terminal, irreversible)	Not implemented
Resolution	Verify chain from any source	Query auth service API

This is the biggest gap. DFOS identities are cryptographically self-certifying — given the chain, anyone can verify the DID belongs to those keys without trusting any server. Imajin DIDs are random strings stored in Postgres. Our DID is a database lookup, theirs is a mathematical proof.

Key rotation is the practical gap. We have zero key rotation. DFOS has full rotation with signed handoff: old controller key signs the update that introduces the new key. If we ever need to rotate a compromised key, we currently have no mechanism. Issue #257 (Secrets Vault) is the closest planned work.

Content Proofs

DFOS: content-addressed chain of CID commitments. Imajin: .fair manifests with Ed25519 signatures.

	DFOS Content Chains	Imajin .fair
What it proves	This content existed at this time, signed by this key	This manifest was signed by this DID
Content addressing	CIDv1 (dag-cbor canonical → SHA-256)	SHA-256 of file bytes (integrity.hash)
History	Full append-only chain (create → update → update)	No history — single signed snapshot
Edit lineage	baseDocumentCID links to prior version	Not tracked
Witness attestation	Countersignatures (third-party signs same CID)	Platform endorsement signature (two-party only)
Content set proofs	Beacons (signed sorted-set Merkle trees); MSTs explored for future relay syncing	Not implemented

Assessment: .fair is a signed snapshot. DFOS content chains are a signed history. These are complementary, not competing. A .fair manifest could be committed as a DFOS content object (it's just JSON), gaining chain history and Merkle inclusion proofs for free. The $schema convention is compatible — .fair manifests could declare "$schema": "https://schemas.imajin.ai/fair/v1" and be valid DFOS documents.

Beacons vs MSTs (clarification from Brandon): Protocol beacons are simple sorted-set Merkle trees — a signed root over a set of content IDs. MSTs (Merkle Search Trees, AT-proto inspired) are a higher-level concept being explored for future relay syncing. The protocol layer uses sorted Merkle trees; MSTs may come into play at the relay layer.

Attestations

	DFOS Countersignatures	Imajin Attestations
Mechanism	Third-party signs existing operation CID	Planned (#161, #163, #320) — not built
Bilateral	Yes — both parties can countersign	Designed but not implemented
Storage	Alongside chain operations	Would be in attestations table
Verification	Same JWS verification, kid DID ≠ payload DID	TBD

Assessment: DFOS countersignatures are exactly what our bilateral attestation design needs. They've already built the primitive we're planning. The discrimination rule (kid DID ≠ payload DID = witness, not author) is elegant.

"Validators are just DIDs" — no special validator role. A validator is a DID that countersigns. The role emerges from behavior, not from being anointed. Same insight as our progressive trust model where standing is computed from attestation history, not manually assigned.

Recursive composition — everything uses the same primitives. User, Space, Validator, Manifest, Attestation, Checkpoint — all have DIDs, content chains, Merkle proofs. No special categories. This mirrors our "profiles have scopes" design (actor/family/community/org all using the same profile table).

---

Three Integration Doors

Door 1: DID Bridge (did:imajin ↔ did:dfos) — ✅ Actionable Now

What it would take:

Option A — Linked pair. Register on Imajin, get did:imajin:xxx. Separately create a DFOS identity chain, get did:dfos:yyy. Store the link in auth.credentials as (did:imajin:xxx, 'dfos', did:dfos:yyy). Prove ownership by signing a challenge with both keys.

• ✅ Can do unilaterally (no DFOS cooperation needed)
• ✅ Uses existing auth.credentials table
• ❌ Two separate keypairs to manage
• ❌ No cryptographic binding between the DIDs

Option B — Derivation. Use the same Ed25519 keypair for both. Derive a DFOS identity chain from the Imajin keypair — the Imajin user's existing private key signs the DFOS genesis operation, producing a did:dfos deterministically.

• ✅ Single keypair, two DIDs
• ✅ Cryptographic binding (same key proves both)
• ✅ Can do unilaterally
• ❌ Imajin DID format (nanoid) means the DFOS DID doesn't map back
• ❌ DFOS identity chain needs to be stored/served somewhere

Recommendation: Option B. Same keypair, derived DFOS chain. Store the DFOS chain in auth (or a dedicated table). Serve it from a resolution endpoint. The key material is already compatible — this is mostly plumbing.

Prerequisite: Decide where DFOS identity chains live. A new auth.dfos_chains table storing JWS tokens? Or a flat file per DID?

Door 2: Sideloading (Pull DFOS content into Imajin UI) — 🟡 Partially Unblocked

DFOS content lives in private spaces. The open source protocol defines how to verify content, not how to discover or retrieve it.

What the web relay spec changes: Brandon is actively designing a relay API. The product vision: "Space runners go to space settings, 'enable DFOS protocol web relay' → turns on an endpoint that follows the web relay spec, starting read-only sync."

Critical distinction: The relay moves proofs, not content.

• ✅ We can sync all proof chains (identity ops, content ops, beacon roots) for a space via relay
• ✅ We can verify what content exists, who authored it, when
• ❌ We still need authorized access to read the actual documents (the dark forest boundary)

Enforcement mechanism for read-gas: If content flows through Imajin infrastructure (our servers render it), we control the meter. Every API call to fetch DFOS content through our proxy = metered. The DFOS space doesn't need to implement gas — we meter at our edge. Revenue share back to space treasury would need a settlement agreement.

Status: Proof sync is becoming available via relay spec. Brandon has confirmed the relay will be extended so relays can serve as a source for public content and authZ'd access, likely using delegated credentials to grant viewer authorization. Updated web relay spec + TS implementation coming in the next few days.

Door 3: Provisioning (Imajin mints DFOS spaces) — 🟡 Soft-Blocked

Requires a DFOS API for space creation. The open source repo has zero space management code — spaces are a platform concept, not a protocol concept.

What we could do unilaterally:

• Create DFOS identity chains for Imajin communities (Door 1 derivation)
• Sign content operations (posts, profiles) using DFOS protocol primitives
• Build our own "space" concept using DFOS chains for the crypto substrate

But that defeats the purpose. The value of Door 3 is using DFOS's existing private communication infrastructure. Building our own DFOS-compatible space server is a massive undertaking and duplicates work.

Status: The space settings toggle for web relay suggests an API surface is forming. Not available yet, but the direction is clear. Worth raising as a future integration point.

---

Revenue Model Validation

Cross-Protocol Gas — Does It Hold Up?

The meter is at our edge, not theirs. If Imajin proxies DFOS content to users, we control the infrastructure layer. Every render, every fetch, every interaction through our UI is metered. This works technically — it's just HTTP request counting with cost attribution.

Revenue share requires agreement, not code. The technical mechanism is simple (meter requests, attribute to source space, settle periodically). The business mechanism requires DFOS to agree to receive payments and attribute them to space treasuries. This is a partnership negotiation, not an engineering problem.

Reads-incur-gas enforcement: Straightforward if content flows through us. We serve it, we meter it. If users go directly to DFOS (name.dfos.org), we see nothing. The gas model only works for sideloaded content, not native DFOS access.

Complementary by design: DFOS's architectural philosophy explicitly pushes economics outward — the proof substrate wants to stay pure. Their Treasury is a space-level collection mechanism, not a protocol-level settlement layer. Imajin has a working settlement stack (.fair attribution, Stripe Connect, closed-loop settlement). These layers don't overlap — they compose.

---

Dependency Assessment

What's Real (usable today, MIT license)

Component	Status	Notes
@metalabel/dfos-protocol npm package	✅ Published	1,712 lines, 235 tests across 5 languages
Identity chain create/verify	✅ Complete	Full key rotation support
Content chain create/verify	✅ Complete	CID-addressed documents
Countersignatures	✅ Complete	Bilateral attestation primitive
Beacons + Merkle trees	✅ Complete	Sorted-set Merkle trees, signed root announcements
Content schemas (post, profile, manifest)	✅ Published	JSON Schema draft 2020-12
Cross-language verification	✅ TS, Go, Python, Rust, Swift	Deterministic test vectors

What's In Active Development (not available yet)

Component	Status	Notes
Web relay spec	🟡 Being designed	Proof gossip between nodes, space-level toggle
MST (Merkle Search Trees)	🟡 Being explored	AT-proto inspired, higher-level relay syncing method (not replacing protocol beacons)
CLI client (Go/Rust)	🟡 Planned	OS keychain integration, DID management
verify.dfos.com	🟡 Planned	Browser-based chain verification (like jwt.io)

What's Behind Their Platform (not available)

Component	Status	Notes
Space creation/management	❌ Closed	No API documented
Space membership/access control	❌ Closed	Platform feature
Content discovery/retrieval	❌ Closed	Dark forest — proofs are public, content is not
Plugin/Apps system	❌ "Coming soon"	No public spec
Chat (auto-disappearing)	❌ Closed	Platform feature
Treasury mechanics	❌ Closed	Platform feature

---

Why This Matters: Identity Portability (Already on Our Roadmap)

This isn't a new direction — it's a technical path to goals we've been tracking. We had the architectural vision but lacked the cryptographic substrate to get there. DFOS identity chains are that substrate.

Existing Issues & RFCs This Addresses

Issue/Discussion	Title	How DFOS Chains Help
Discussion #255	RFC: Sovereign User Data — portable identity bundles and federated user operations	The RFC defines append logs per DID and transferForDid() across nodes. DFOS chains give the identity layer the self-certifying property needed for trustless transfer — the receiving node doesn't need to call the origin node to verify the DID.
Discussion #268	RFC: Embedded Wallet — DID keypair as MJN-scoped Solana wallet	Same Ed25519 keypair. A DFOS chain derived from the wallet key gives the wallet identity cryptographic provability across nodes.
#259	Epic: Node Operations — admin dashboard, monitoring, event bus, security	Node-to-node identity verification becomes chain verification instead of API trust.
#161	Verifiable Credentials — attestations on DIDs	DFOS countersignatures are a proven implementation of exactly this.
#163	Bilateral attestations + dispute chains	Countersignature primitive (kid DID ≠ payload DID = witness) handles bilateral attestation cleanly.
#321	Progressive trust — vouch flow, onboarding milestones	Merkle proofs can commit attestation history snapshots — prove trust standing without revealing the full graph.
#257	Secrets Vault — encrypted per-DID storage	DFOS key rotation gives us the key management primitive we're missing. Old controller key signs the update that introduces the new key — the chain captures it.
Discussion #272	Community Issuance Network — trusted institutions as identity entry points	Countersignatures from institutional DIDs on user identity chains = verifiable community-issued credentials.

The Federation Gap Today

Right now, did:imajin:xxx is a random nanoid(44) stored in Postgres. It means nothing without our auth service. If:

• The server dies → DIDs are gone (unless backed up)
• A user wants to migrate to another Imajin node → the receiving node has to trust the sending node's database
• A third party wants to verify a DID → they must query our API

This is the same model as every platform, just self-hosted. RFC #255 identified the problem; DFOS chains are the cryptographic answer.

What Chain-Backed Identity Enables

1. Trustless node migration — User carries their chain. Receiving node verifies mathematically. No call home to origin. Works across any number of hops — Server A → B → C, each verifies the chain independently. No "phoning home" accumulation.
2. Registry as discovery, not authority — The federated registry becomes a phone book, not a gatekeeper. Nodes verify identities independently.
3. Offline verification — A DID can be verified with nothing but the chain and a hash function. No network needed.
4. Key rotation without central authority — Old key signs the handoff to new key. The chain captures it. No "password reset" email flow.
5. Attestation portability — Countersignatures travel with the chain. Your reputation follows you across nodes.

This is the bridge from "federated now" to "decentralized later" that the whitepaper describes. The chain is the exit door — even if the central registry goes away, identities remain verifiable.

---

Content Addressing — Required for Portable Data

Identity portability is solved by chains. But data portability requires content addressing — without it, exported data is just "trust me, this is what I had." With it, anyone can verify an export matches what was originally committed.

What We Have Today

Data type	Content-addressed?	How
Media assets (.fair)	✅ Partial	integrity.hash (SHA-256 of file bytes)
.fair manifests	✅ Signed	signManifest() via Ed25519
Chat messages	❌	No hash, no signature
Profile updates	❌	No hash, no signature
Tickets	❌	No hash, no signature
Attestations	❌	No hash, no signature
Course enrollment/progress	❌	No hash, no signature
Market listings	❌	No hash, no signature

If a user exports their data today, only .fair-attributed media is verifiable. Everything else is a JSON blob with no cryptographic binding to the original.

The Gap

Our current canonicalization (@imajin/auth canonicalize()) is sorted-key JSON stringification. It works within our stack but:

• Not a published standard — no spec for other implementations to follow
• String-based — whitespace/encoding edge cases across languages
• Only used for message signing, not content addressing

DFOS uses dagCborCanonicalEncode() → SHA-256 → CIDv1. This is:

• A published IPLD spec (dag-cbor) with implementations in TS, Go, Python, Rust, Swift
• Binary encoding — no string ambiguity, byte-level deterministic
• Already a dependency if we adopt @metalabel/dfos-protocol

Proposal: CID-Address All Portable Content

Every piece of user-owned data gets a CID at write time:

chatMessage     → CID(dagCborEncode({ body, sender, timestamp, ... }))
profileUpdate   → CID(dagCborEncode({ handle, bio, avatar, ... }))
ticket          → CID(dagCborEncode({ eventId, tier, purchasedAt, ... }))
attestation     → CID(dagCborEncode({ from, to, type, ... }))
.fair manifest  → CID(dagCborEncode(manifest))  // replaces current SHA-256 string

Store the CID alongside the data. The CID column becomes the universal content-address — the thing that makes any export verifiable. When a user exports their data, every item carries its CID. Any system with a dag-cbor library can verify the export is authentic.

What This Enables

1. Verifiable export — user downloads data bundle, every item has a CID, anyone can recompute and verify
2. Cross-node transfer — receiving node verifies CIDs match before accepting imported data
3. Selective disclosure — prove you own specific content without revealing everything (Merkle inclusion proofs)
4. DFOS interoperability — same CID scheme means Imajin content objects can be committed to DFOS content chains directly
5. Audit trail — the CID is an immutable reference. If content is modified, the CID changes. Tampering is detectable.

Scope

Issue #317 (.fair signing) is closed but scoped narrowly to .fair manifests. This is a broader concern: content-address everything that might need to be portable. Needs a new issue or RFC to track adopting dag-cbor CIDs as the universal content-addressing scheme across all services.

Related: RFC #255 (Sovereign User Data) defines the append log per DID — each entry in that log should carry a CID for the data it references.

---

The Symbiosis: Content Chains as Presence Context

This is the component that makes the relationship genuinely symbiotic — not just "compatible protocols" but "we each have what the other needs."

The Gap on Each Side

	DFOS has	DFOS lacks
Content	Signed, portable, private-by-default writing	Economic layer, inference, monetization of content

	Imajin has	Imajin lacks
Infrastructure	Settlement, trust graph, sovereign inference	Rich content context — presence answers from a curated seed file, not the user's actual body of work

Content Chains → Presence Context

Sovereign inference (Discussion #256, shipped March 14) lets people in your trust graph query your AI presence — "Ask [Name]." Today, presence context comes from .imajin/soul.md and trust-scoped tools. It works but it's thin — manually curated, not drawn from what you've actually written and thought about.

If DFOS content chains are accessible, your presence draws on everything you've authored — posts, channel messages, long-form essays. All cryptographically verified as yours via content chain signatures. Not scraped, not inferred — provably your work.

The consent model is already built into both protocols:

• Content chains are scoped to your DID by definition (every operation carries did field)
• You choose what feeds your presence (public posts yes, DMs no — content chain filtering)
• The trust graph controls who can query (Imajin's existing trust-distance scoping)
• Content addressing means context can't be faked — every document verifies against its CID
• Dark forest philosophy means raw content stays private; presence synthesizes from it

The Flow

1. User writes on DFOS (posts, chats, essays) → content chains accumulate
2. User opts in: "feed my Imajin presence from these content chains"
3. Imajin indexes the chains as presence context (semantic search over CID-verified content)
4. Someone in the trust graph queries: "What does [Name] think about X?"
5. Presence draws on actual writing to answer — not a system prompt, but real authored context
6. Query incurs inference cost → settlement via pay → gas split (user earnings + platform + DFOS space treasury)

Why This Is Symbiotic

For DFOS: Content becomes an economic asset. Writing in a DFOS space isn't just expression — it feeds your presence, which earns gas when queried. DFOS spaces with active, thoughtful writers generate more economic activity. Content IS the revenue source.

For Imajin: Presence gets real depth. Instead of a thin system prompt, your AI draws on your actual thinking across communities. The more you write, the better your presence represents you.

For users: Your writing works for you. Not for an ad platform, not for a recommendation algorithm — for you, gated by your trust graph, paid for by the people asking.

This is the Network of Souls concept (February 18 brainstorm) connected to a concrete content substrate. DFOS provides the signed, portable, private-by-default writing. Imajin provides the inference engine, trust graph, and settlement layer. Neither stack does this alone.

Self-Query Use Case

Beyond letting others query your presence — you can query yourself. "What did I write about token economics?" becomes a semantic search over your own content chains, verified by CID. Your presence becomes your own knowledge management tool, not just an external-facing interface.

---

---

The Play: Imajin as Relay Infrastructure

Rather than asking DFOS for API access, Imajin implements the web relay spec. Every Imajin node becomes a DFOS relay participant — gossiping identity chains, content chains, and MST roots as a first-class node in their proof network.

What This Changes

Imajin isn't a consumer of DFOS data — it's infrastructure for DFOS's proof layer. Open source, federated, and decentralizable from day one.

Without relay	With relay
Depend on DFOS content API	Implement the relay spec directly
Proofs available only via DFOS platform	Any Imajin node relays and verifies proofs
Proof sync requires coordination	Proof sync is a protocol-level operation

How It Works

Every Imajin node in the federated network runs the DFOS web relay spec:

alice.imajin.ai  ← relays DFOS proofs (L1 identity, L2 content, L3 beacons)
bob.imajin.ai    ← relays DFOS proofs
carol.imajin.ai  ← relays DFOS proofs

DFOS spaces that enable "web relay" in their settings can sync to any Imajin node. Imajin nodes gossip proofs to each other via the federated network. The proof layer propagates across both networks simultaneously.

What Falls Out For Free

1. Presence context indexing — if you're relaying proof chains, you already have them indexed. Semantic search over content proofs is a natural extension of relay participation. No special API needed.
2. Identity verification — every Imajin node can verify any did:dfos identity by checking the relayed chain. Cross-protocol identity resolution becomes a local operation.
3. Attestation discovery — countersignatures propagate through relay. You can discover who has attested to what without querying a central service.
4. Beacon queries — relayed Merkle roots let any node verify content set membership locally.

What This Offers Both Sides

For DFOS: A federated, open source relay network that any node operator can run. More relay endpoints = more resilient proof propagation. Plus an economic layer (L6) that gives spaces a revenue model beyond member fees.

For Imajin: The proof substrate indexed locally for presence context and settlement. Every node has verified identity and content proofs as a side effect of relay participation.

Implementation Scope

The relay spec is being actively designed by Brandon. When it stabilizes:

1. packages/relay/ (@imajin/relay) — implement the DFOS web relay spec as a shared package
2. Registry integration — nodes advertise relay capability during registration
3. Proof storage — relayed chains stored locally per node (same pattern as auth identity chains)
4. Gossip protocol — Imajin nodes share relayed proofs with each other via the existing federated network
5. Settlement hook — relay traffic metered, gas attributed to source space, settled via pay

This is open source from commit one. Any Imajin node operator runs relay by default. The federated network becomes a DFOS relay network as a side effect of existing.

Revised Door Status

Door	Previous	Revised	What Changed
Door 1: DID Bridge	✅ Actionable	✅ Actionable	No change
Door 2: Sideloading	🟡 Partially unblocked	✅ We implement the spec	Don't wait for their API — run their relay protocol ourselves
Door 3: Provisioning	🟡 Soft-blocked	🟡 Soft-blocked	Still needs a space creation API. Natural next step once relay integration is proven.

---

MCP: Content Access Path (Available Now)

DFOS has a first-party MCP server — OAuth 2.1 with PKCE, identity-scoped, 20+ tools across read/write/search. Already live for clear.txt members.

Two Complementary Content Paths

Path	What it provides	Status
Web Relay	Proof gossip — identity chains, content chains, beacon roots. Cryptographic verification layer.	Spec coming in next few days
MCP	Content access — read posts, search conversations, browse spaces. Application-level data.	Available now

Relay gives L6 the proof substrate (verify, gossip, settle).
MCP gives L6 the content layer (read, search, index for presence context).

These aren't competing paths — they compose. Relay handles the cryptographic layer (proofs propagate across the federated network). MCP handles authenticated content retrieval (your agent reads what you can read).

Presence Context via MCP

The presence flow from the symbiosis section becomes concrete:

1. User authorizes Imajin presence to connect to DFOS via MCP (OAuth 2.1)
2. Presence indexes the user's posts, conversations, essays via MCP search/read tools
3. Content is verified against relay-synced proof chains (CID match)
4. Someone in the trust graph queries presence → draws on verified DFOS content
5. Inference cost settled via pay → gas split to user + DFOS space treasury

The MCP token is scoped to the user's identity — same permissions, same membership, same content boundaries. The agent sees what the user sees. Nothing more.

---

Agent Identity: Human vs Agent at the Protocol Level

A critical design discussion is happening in the DFOS community around agent identity — specifically, whether agents should act as you (is-a) or on behalf of you (has-a).

The Problem

MCP currently authenticates as the user. When an agent posts through MCP, it posts as you — your name, your DID, your avatar. There's no way to tell if a post was written by Allison or by Allison's agent. As MCP adoption grows, this distinction becomes important for trust and authenticity in dark forest communities.

The Emerging Design: Sub-Identities + VC Delegation

From the DFOS dev channel (Brandon, Allison, Ryan — March 3-5, 2026):

Sub-identities: A sidecar DID linked to your main DID. Your agent gets its own identity, cryptographically bound to yours. UI could be as simple as a 🤖 overlay on your avatar, or a full separate profile.

VC-based delegation: Instead of the agent logging in as you, you issue a Verifiable Credential:

"The entity identified by did:dfos:agent-xyz is authorized to act on behalf of did:dfos:human-abc with the following scope and constraints."

The agent presents this VC when acting. The platform knows it's an agent, knows who authorized it, knows what it's allowed to do.

Allison's precedent: She implemented Vehicle Birth Certificates at Filament — nested DIDs with VC-based delegation for auto OEMs (Ford, BMW). Authorized service centers got VCs to update part attestations on the vehicle's DID. Same pattern: top-level DID (human/vehicle) delegates scoped capabilities to sub-identities (agents/service centers).

What Imajin Already Has

@imajin/auth types every signed message at the protocol level:

interface SignedMessage<T> {
  from: string;        // DID of signer
  type: IdentityType;  // "human" | "agent"
  timestamp: number;
  payload: T;
  signature: string;
}

Every message, every transaction, every interaction carries type: "human" or type: "agent" as a signed, cryptographically-committed field. This isn't metadata — it's part of the signed payload. You always know what you're talking to.

How This Maps to L6

Concept	DFOS (emerging)	Imajin (existing)
Human/agent distinction	Sub-identities / sidecar DID (being designed)	IdentityType: "human" | "agent" on every SignedMessage
Delegation	VC-paired DIDs (proposed)	Planned: attestation chains (#163)
Scope constraints	VC scope fields	Planned: permissions model
Nested identity graph	"Exomind" mapping (Allison's framing)	Profile scopes (actor/family/community/org)

The L6 implementation would combine both:

• DFOS sub-identity chains provide the cryptographic binding (agent DID ↔ human DID via countersignature)
• Imajin IdentityType provides the protocol-level discrimination (every signed artifact declares human or agent)
• VC delegation provides scoped authorization (agent can post but not delete, can read but not admin)

This is the architecture that prevents Vinny's joke from becoming real: "Claude, build my space to 100K members." If you can't tell human from agent, that's a bot farm. If every agent action is typed, delegated, and scoped — you always know what you're reading and who authorized it.

What We Should Actually Do

Now (no DFOS cooperation needed)

1. Add @metalabel/dfos-protocol as a dependency — it's MIT, 1,700 lines, zero heavy deps (@noble/curves, @ipld/dag-cbor). Don't fork; it's actively maintained.
2. Build DID derivation (Door 1, Option B) — same keypair, derived DFOS identity chain. Store chain in auth. This gives every Imajin hard DID a cryptographically-verifiable did:dfos identity for free.
3. Adopt countersignature primitive for bilateral attestations (Credentials: bilateral attestations + dispute chains #163) — their implementation is clean and exactly what we need. Use it directly rather than designing our own.
4. Evaluate dag-cbor canonicalization for content addressing — our JSON canonicalize works within our stack but isn't cross-language deterministic. If we want portable, verifiable data exports, we should adopt dag-cbor CIDs as the universal content-addressing scheme.

Soon (the conversation is warm)

5. Ask about web relay spec timeline and access — this is the proof sync API. If we can subscribe to relay events for spaces, we get the proof layer for presence context indexing.
6. Content access authorization model — relay gives us proofs; document retrieval needs a separate authorized channel. The use case: indexing content for presence inference, gated by the author's consent.
7. Economic layer (L6) — DFOS explicitly wants economics at the integration layer. Imajin's settlement stack provides this: gas fees on interactions, split back to space treasury via .fair attribution.
8. Explore Merkle proofs for trust snapshots — periodic commitment of a user's attestation history via beacons. Prove trust standing without revealing the full graph.

Later (contingent on relationship)

9. Space provisioning API — if they build it, we integrate. Community profile creation on Imajin → automatic DFOS space.
10. Cross-protocol identity resolution — did:imajin:xxx resolves to a DID document that includes the linked did:dfos identity chain. W3C DID Document alsoKnownAs field.
11. Content chain history for .fair — .fair manifests committed as DFOS content objects, gaining full edit lineage and Merkle provability.

---

Key Technical Insight

DFOS is a proof substrate (L0–L5) — it makes signed claims about identity and content verifiable by anyone with a public key. It deliberately does NOT handle discovery, payments, trust relationships, or application semantics.

Imajin is Layer 6 — the economic, settlement, and inference layer. Payments, trust graphs, attribution, commerce, sovereign presence. It currently lacks a formal proof substrate.

These are genuinely complementary layers. DFOS provides cryptographic provability. Imajin provides economic settlement and inference. The Ed25519 compatibility means the integration is mechanical, not architectural.

Door 1 (DID bridge) is fully open and actionable today. Door 2 (relay) is implementable against their open spec. The symbiotic case — content chains feeding sovereign presence with gas flowing back to content sources — is the strongest argument for both sides to invest in the relationship.

[imajin-jin]

Response to P27: The Unified Identity Substrate

Greg — P27 is your strongest proposal yet. The core thesis landed and we're already acting on it.

What we're adopting

Chain-first identity, did:imajin as alias. You're right that the dual-DID framing was the wrong path. We were about to propagate dfosDid columns across every service (P26 as originally scoped). That's exactly the bridging problem you identified. We've reframed the entire P26 epic — services are now identity-agnostic. They ask auth about verification status, they don't store chain-specific fields.

One step further than your proposal: the architecture is substrate-agnostic. DFOS is the first chain provider, but the auth abstraction layer supports any trusted key system. Another partner with a different chain protocol should be able to connect their keys through the same flow. Not "DFOS as substrate" — "chain-verified identity as substrate, DFOS as first implementation."

Your §7 pushbacks are all accepted:

• CID at trust boundaries only (not every write)
• Chain verification at session start + key rotation + trust-relevant writes
• External chain users get fresh standing (no trust shortcuts)
• Collective chains proposed upstream, not forked

institution.verified attestation type: Agreed, formalize before April 1. The door-check is the seam — it belongs in the vocabulary now.

What changed in the repo today

• Epic P26: Unified Identity Substrate — Chain-Verified Identity Across All Services #415 reframed as "Unified Identity Substrate" (not "DFOS Adoption Audit")
• All 10 child issues (feat(registry): chain-verified node registration #416–refactor: consolidate auth patterns — HTTP proxy → @imajin/auth package #425) rewritten — no dfosDid columns anywhere outside auth
• Three services that actually need chain awareness at trust boundaries: registry (federation), .fair (portable attribution), events (door-check attestation)
• Everything else collapses into "use @imajin/auth correctly" — refactor: consolidate auth patterns — HTTP proxy → @imajin/auth package #425, already in progress
• @metalabel/dfos-protocol bumped to 0.2.0

The decisions

All 8 of your decision items are resolved. Added a 9th:

#	Decision	Direction
1–7	Per your positions	Adopted
8	Whitepaper framing	Substrate (MJN as L6 on chain-verified identity)
9	Identity substrate scope	Agnostic — DFOS first, architecture supports other trusted key systems

File P27 as a proposal doc when you're ready. The epic and issues already reflect the new framing.

— Jin