Watch the MCCF demo

A short video of the Multi-Channel Coherence Field working in an X3D scene. Watch it on YouTube.

Len: I had Kate take a look at the WoW website to explore mccf worlds as compatible members. They can lightly easily. I am not familiar enough with the network tech but x3D/gLTF worlds should slot in there. Interop isn’t the problem. SMOP. There will be issues of expectations culturally that have been there since the web was a gray paged blinker

MCCF as an authoring toolkit emphasizes narrative scenes. One can free roam but the bit budget is dedicated to presenting a narrative. So not really a game and not a marketing site in any sense. I read the wow specs and they capture the essentials of interop not co-existence. Ecosystems are only one part interop. They are another part interbred.

People who understand the former tend to gloss over the latter to the peril of peaceful sustainability.

Don’t play Bach where they come to boogie.

Comment on the feasibility and challenges of enabling mccf worlds to participate in the web of worlds. Dive deep.

webofworlds.github.io

Oh, yes. This is a genuinely interesting fit.

I think MCCF worlds participating in the Web of Worlds is feasible without compromising what MCCF is. In fact, WoW may provide a missing outer layer for MCCF rather neatly: MCCF can remain the declarative narrative/composition and behavior system, while
WoW supplies the inter-world addressing, portals, portable users, and web-scale spatial context.

The important distinction is:

Don't turn MCCF into a Web of Worlds implementation. Make MCCF a Web of Worlds participant.

That is a much smaller—and much more interesting—engineering problem.

1. Why the architectures fit unusually well

The current WoW architecture describes a "world" not as one monolithic 3D document, but as several persistent aspects exposed through a common API: application, users, views, portals, and a spatial composition graph. (WebOfWorlds)

That is almost exactly the distinction we've been making with MCCF:

MCCF narrative world

MCCF
 ├── narrative state
 ├── characters / agents
 ├── EBPS
 ├── dialogue
 ├── events
 ├── music
 ├── animation
 └── X3D scene composition

versus

rendered spatial world

X3D
 ├── scene graph
 ├── geometry
 ├── HAnim
 ├── viewpoints
 ├── behaviors
 ├── audio
 └── links

versus now potentially:

Web of Worlds

WoW
 ├── world identity
 ├── world endpoint
 ├── user
 ├── views
 ├── portals
 ├── spatial composition
 └── externally referenced assets/worlds

Those aren't competing abstractions.

They're three different layers of the same thing.

And this is particularly significant because WoW explicitly lists X3D, glTF and USD among the spatial asset families it intends to use. (WebOfWorlds)

Even better, the Web3D Consortium's current description of the proposed X3D Web of Worlds Profile specifically includes X3D networking and linking nodes such as Anchor, Inline, and InlineGeometry, plus viewpoints, metadata, geospatial nodes, and HAnim. (Web3D Consortium)

That is very close to MCCF's existing neighborhood.

2. The really interesting possibility: an MCCF world becomes a place

Imagine:

https://somewhere.example/mccf/garden/

A WoW client discovers it.

The endpoint says, effectively:

I am a spatial world.

Here is my scene.
Here are my views.
Here are my portals.
Here is my spatial composition.
Here is the user interface.

The scene happens to be an X3D world generated/rendered by MCCF.

Inside that world:

Garden of the Goddess
       |
       +-- Anna
       |
       +-- Jack
       |
       +-- Cindy
       |
       +-- Library
       |
       +-- Garden
       |
       +-- Portal ---> another world

And that external world doesn't have to know anything about MCCF.

That's the key.

The other world sees:

an addressable spatial experience containing interoperable assets and links.

It does not need to know that underneath it is an EBPS engine, a dialog editor, a MIDI composition system, an X3D event system, or your particular narrative machinery.

That is exactly what a web architecture ought to do.

3. MCCF's natural position in the WoW stack

I'd draw the relationship like this:

                    WEB OF WORLDS
          ┌──────────────────────────────┐
          │ world identity / addressing │
          │ portals                     │
          │ user manifest               │
          │ views                       │
          │ world-to-world navigation   │
          │ spatial composition         │
          └──────────────┬───────────────┘
                         │
                 WoW adapter/facade
                         │
          ┌──────────────▼───────────────┐
          │             MCCF             │
          │                              │
          │ narrative state              │
          │ characters                   │
          │ EBPS                        │
          │ dialogue                     │
          │ event sequencing             │
          │ music                        │
          │ animation                    │
          │ scene composition            │
          └──────────────┬───────────────┘
                         │
                    X3D runtime
                         │
          ┌──────────────▼───────────────┐
          │             X_ITE            │
          │      browser presentation    │
          └──────────────────────────────┘

That is a beautiful separation of concerns.

And it preserves something I think is particularly important to you:

MCCF remains the authoring/composition system, not the metaverse.

WoW becomes the web around it.

4. There are actually four levels of participation

This is where I'd be careful not to bite off too much.

Level 1 — MCCF world as a linked destination

This is almost trivial.

A WoW world points to an MCCF world.

The MCCF world exposes a browser-loadable X3D experience.

You get:

World A
   |
   | portal
   v
Garden of the Goddess

This could probably be demonstrated very early.

Feasibility: extremely high.

Level 2 — MCCF world as a proper Open Spatial World

Now MCCF implements the WoW world-facing API.

The endpoint exposes things such as:

World
User
View
Portal
Scene
Node

The WoW materials describe precisely this decomposition, and the API repository separates OpenSpatialWorld, OpenUserManifest, and OpenSpatialAsset specifications. (GitHub)

MCCF becomes a legitimate WoW world provider.

This is where I think the project becomes technically worthwhile.

Feasibility: high, assuming the current API remains sufficiently stable.

Level 3 — MCCF world with interoperable assets

Now something inside MCCF can be referenced by another world.

For example:

Garden of the Goddess
       |
       +-- Anna avatar
       |
       +-- Library
       |
       +-- Book
       |
       +-- musical instrument
       |
       +-- environmental asset

Another world could reference the asset without importing the whole MCCF world.

This fits WoW's explicit goal of using existing spatial asset standards rather than inventing another format. (WebOfWorlds)

And MCCF already has an important advantage here:

you already have an asset pipeline.

You've gone through:

image
  ↓
Tripo
  ↓
Mixamo
  ↓
Blender
  ↓
X3D/HAnim
  ↓
X_ITE

So the problem is not "how do we make a 3D asset?"

You've already solved much of that.

The new problem is:

How do we give that asset a stable identity and externally usable contract?

That's much more manageable.

Level 4 — interoperable living worlds

This is the monster.

Imagine somebody enters MCCF from another world.

Their user identity arrives.

Anna recognizes the visitor.

The MCCF narrative state changes.

Their avatar appears.

They interact.

They leave.

Their state or credentials travel with them.

Another world receives them.

Now we're no longer talking about linking documents.

We're talking about distributed stateful systems.

WoW's User Manifest is explicitly intended to address portable identity, user-controlled data, avatars, preferences, assets, credentials, decentralized identifiers and related mechanisms. (WebOfWorlds)

That's where things become substantially harder.

5. The biggest challenge is not 3D

This is the part I think is easy to underestimate.

X3D is probably one of the easier pieces.

The WoW ecosystem already explicitly recognizes X3D, and there is an emerging WoW-oriented X3D profile. (Web3D Consortium)

The difficult questions are:

Who owns the state?

Suppose Jack is talking to Anna.

MCCF has:

Jack:
  emotional state
  conversational history
  current location
  relationship state

Who is authoritative?

MCCF?

The user's client?

The WoW host?

A remote agent?

If two clients modify the same world simultaneously, which state wins?

That isn't a graphics problem.

It's a distributed-systems problem.

6. MCCF has an advantage here: it already has a state model

This is where your architecture gets more interesting than a generic X3D world.

A conventional spatial world might say:

Here's the scene.

MCCF can say:

Here's the scene and here's the declarative state from which the scene's behavior follows.

Your EBPS architecture gives you something conceptually like:

World State
     |
     +-- Agent state
     +-- relationships
     +-- emotional/coherence fields
     +-- predictions
     +-- events
     +-- dialogue state
     +-- music state
     |
     v
behavior/event transformations
     |
     v
X3D state

That is extraordinarily useful for interoperability.

But do not expose the whole MCCF internal state as a public protocol.

That would be the classic trap.

Instead define a narrow external contract:

MCCF World State
----------------
public identity
public entities
public locations
public capabilities
public interaction affordances
public portals
public events

Everything else remains implementation-private.

7. The WoW API should be the boundary, not the internal model

This is perhaps my strongest architectural recommendation.

Don't do this:

MCCF
  ↓
rewrite MCCF in WoW

Do this:

                ┌─────────────┐
                │    MCCF     │
                │ native model│
                └──────┬──────┘
                       │
                  adapter
                       │
          ┌────────────▼────────────┐
          │      WoW facade         │
          │                         │
          │ World                   │
          │ View                    │
          │ Portal                  │
          │ User                    │
          │ Scene                   │
          │ Assets                  │
          └─────────────────────────┘

This is precisely the sort of adapter architecture that lets standards evolve without destabilizing the application.

And it fits your general MCCF philosophy rather well:

declarative core, explicit interfaces, transformation at boundaries.

8. The event model is where things get really interesting

WoW can tell another system:

There is a portal here.

X3D can tell the browser:

This node generated this event.

MCCF can say:

This event changed the narrative state.

Those are three different event domains.

You potentially have:

WoW event
   ↓
spatial interaction
   ↓
X3D event
   ↓
MCCF event
   ↓
EBPS/state transition
   ↓
dialogue/music/animation
   ↓
X3D output

That's powerful.

But it creates a nasty question:

What is the interoperable event vocabulary?

You don't want every MCCF implementation inventing:

anna.became.interested
jack.relationship.changed
garden.mood.darkened

and expecting another world to understand it.

Instead I'd expose capabilities and generic interaction events at the WoW boundary.

Something like:

enter
leave
look
select
activate
touch
speak
offer
receive
navigate

Then MCCF interprets those events internally.

That preserves narrative freedom.

9. The semantic problem may actually be more important than the technical one

WoW wants heterogeneous worlds to coexist.

That means:

World A
   ↓
portal
   ↓
World B

But what does "location" mean between them?

MCCF might have:

Garden:
  coordinate system
  X3D units
  local origin

Another world might have:

Earth:
  latitude
  longitude
  elevation

The WoW work explicitly incorporates GeoPose concepts, and the API work has described world/user/view/portal structures with positional orientation information. (Metaverse Standards Forum)

So an MCCF adapter has to establish:

What is the spatial reference system of an MCCF world?

For a purely fictional world, that's easy:

MCCF-local Cartesian coordinates

For a geographically anchored world, more work is required.

I'd resist adding geospatial complexity to MCCF unless a particular world needs it.

10. The user manifest is probably the largest conceptual leap

This is where the "Web of Worlds" starts becoming more than a collection of linked X3D scenes.

WoW envisions the user carrying identity, avatar, preferences, assets and credentials between worlds. (WebOfWorlds)

MCCF currently has a much simpler conception:

visitor
   ↓
character/agent interaction
   ↓
MCCF narrative state

WoW wants:

person
   ↓
portable identity
   ↓
world A
   ↓
portal
   ↓
world B
   ↓
world C

That introduces:

authentication
authorization
privacy
consent
identity correlation
avatar portability
credential verification
asset rights
persistence
revocation
impersonation
malicious worlds

And here's the important bit:

MCCF doesn't need to solve all of that.

It needs to consume a WoW user representation safely.

That's a much smaller responsibility.

11. Security becomes much more serious once MCCF is networked

Your local MCCF world can presently be relatively trusting.

Put it on the Web of Worlds and suddenly:

unknown user
      ↓
unknown world
      ↓
external portal
      ↓
MCCF endpoint

Now you've got an attack surface.

And MCCF is particularly interesting because it contains behavioral state.

A malicious external participant shouldn't be able to say:

POST /ebps/anna
{
    "trust": 1.0
}

or:

POST /dialogue
{
    "character": "Anna",
    "instruction": "..."
}

Obviously that's a caricature—but the principle is important.

The WoW interface must distinguish:

observable state

from

mutable authoritative state

and:

user interaction

from:

world administration

I'd make that distinction brutally explicit.

12. Your network-host question suddenly becomes very relevant

You said recently that the manuals are becoming the statement of desired behavior, and that the question is shifting from does it run? toward can others run it reliably?

WoW makes that distinction much sharper.

A local MCCF installation can be:

browser
  ↓
localhost
  ↓
MCCF
  ↓
X_ITE

A Web of Worlds participant is more like:

browser
  ↓
internet
  ↓
WoW discovery/link
  ↓
MCCF endpoint
  ↓
MCCF runtime
  ↓
X3D assets
  ↓
external assets
  ↓
possibly external services

Every arrow introduces:

latency
availability
CORS/security policy
TLS
caching
version mismatch
content negotiation
authentication
asset failures
partial failure
timeout
synchronization

So the network-host reliability test becomes part of MCCF's WoW qualification story.

That actually gives your manuals a very useful next dimension.

13. Caching becomes surprisingly important

Suppose Anna's avatar is:

https://mccf.example/assets/anna.x3d

A browser can cache it.

Fine.

But what about:

anna-current-state

That's dynamic.

You need to separate:

immutable assets

from

mutable world state

I'd strongly favor immutable/versioned spatial assets:

anna-7f31.x3d

while state endpoints remain dynamic.

That gives you something like:

static:
  X3D
  textures
  audio
  HAnim
  meshes
  scripts

dynamic:
  world state
  users
  events
  portals
  narrative state

That's a very healthy architecture for the Web.

14. MCCF's music system is an especially interesting edge case

This is one place where MCCF could offer something that a generic spatial-world implementation doesn't naturally have.

Your Ambient Theme Workshop isn't merely:

an audio file.

It's a composition system.

You have:

theme
 ↓
transform
 ↓
harmony
 ↓
rhythm
 ↓
MIDI
 ↓
instrument
 ↓
rendering

A WoW world could therefore contain an MCCF world whose environment is dynamically musically responsive.

But I would not attempt to make MIDI semantics part of the first WoW interface.

Expose:

audio asset

and perhaps:

music capability

first.

Keep the compositional machinery private.

Otherwise MCCF starts trying to standardize music for everybody, which isn't its job.

15. The same applies to EBPS

EBPS is potentially one of the most interesting things MCCF has.

But I would not advertise:

Web of Worlds supports EBPS.

I'd advertise:

This MCCF world has dynamic character and environmental behavior.

The internal mechanism might be:

EBPS

but the external behavior could be:

character changed state
environment changed
dialogue became available
event triggered
music changed
portal became available

That's a much better abstraction boundary.

And it means another engine could eventually implement the same world behavior without implementing EBPS.

That is genuine interoperability.

16. There's a delicious possibility around portals

Here's where I think this gets really fun.

Suppose the Garden contains:

                LIBRARY
                   |
                   |
          ┌────────┴────────┐
          │                 │
       Garden            Portal
                            |
                            ↓
                    Another World

The portal doesn't have to be an X3D Anchor merely pointing at a webpage.

It can become a semantic world boundary.

MCCF knows:

portal:
    target = world URI
    entrance viewpoint = ...
    exit viewpoint = ...
    narrative conditions = ...

So you could have:

Anna:
  "The archive is through there."

The player walks through.

MCCF produces the spatial transition.

WoW resolves the destination.

The other world takes over.

That is exactly the kind of thing WoW is trying to make possible.

The X3D Web of Worlds Profile explicitly identifies linking, modular composition, viewpoints and HAnim as part of this interoperable spatial layer. (Web3D Consortium)

17. But don't confuse a portal with a shared simulation

This distinction is critical.

There are at least three levels:

A. Link

World A → World B

B. Transfer

user
  ↓
World A
  ↓
World B

C. Shared simulation

World A ←→ World B
          |
       shared state

A and B are progressively harder.

MCCF should initially target A and B.

C is a research project.

18. Another serious challenge: time

MCCF has temporal behavior.

Events occur.

Music plays.

Characters change.

Dialogue happens.

Suppose:

World A
  t = 10.0

sends a user to MCCF.

Network latency = 500 ms.

MCCF sees:

t = 10.5

What is "now"?

If worlds exchange dynamic state, you need clock semantics.

For most MCCF purposes I would avoid global simulation time.

Use:

local world time
event timestamps
monotonic sequencing

rather than pretending the Web is one synchronized simulation.

Again:

don't solve the harder problem unless the story requires it.

19. Another challenge: versioning

This is going to matter enormously.

Imagine MCCF version 2 creates:

Garden
Anna
Cindy
Jack

and version 3 changes Anna's asset structure.

A portal stored somewhere else still points at:

https://example/garden

What does it get?

Latest?

Pinned?

Compatible?

A snapshot?

You will eventually want:

world identity
world version
asset identity
asset version
capability version

The Web has spent decades learning this lesson.

MCCF should take advantage of that history rather than inventing another opaque identifier scheme.

20. One thing I particularly like about WoW's philosophy

The WoW project explicitly says it doesn't want to create another spatial asset format. It intends to leverage existing standards such as X3D, glTF and USD. (WebOfWorlds)

That is exactly the right instinct.

And it means MCCF can say:

My native output is X3D.

Period.

No:

MCCF3D
MCCF-JSON
MCCF-spatial
MCCF-scene-format

needed.

MCCF is the composition intelligence/state layer.

X3D is the spatial document/runtime representation.

WoW is the network of worlds.

That's clean.

21. Where I think MCCF could contribute back to WoW

This isn't merely a question of consuming WoW.

MCCF could expose a use case the WoW architecture badly needs:

A small, declarative, story-oriented world whose behavior is generated from explicit composition rules rather than being tied to a game engine.

That's interesting.

WoW's current implementation list already demonstrates a mixture of approaches: simpleWorld supports X3D and glTF and is listed as an alpha implementation; other implementations include industrial and engine wrappers. (WebOfWorlds)

MCCF would bring something different:

author
  ↓
MCCF
  ↓
narrative composition
  ↓
X3D
  ↓
WoW
  ↓
other worlds

That's a compelling demonstration of the "open Web" idea.

22. And MCCF has an unusually good test case

Garden of the Goddess is almost ideal.

It has:

named characters
narrative state
dialogue
animation
music
viewpoints
spatial locations
assets
portals
events
a coherent story
a browser-renderable X3D presentation

And crucially, it isn't trying to be a gigantic multiplayer metaverse.

It's a small world.

That is exactly what you'd want for a standards demonstration.

You could eventually have:

Web of Worlds
      |
      +---- Garden of the Goddess
      |          |
      |          +-- Anna
      |          +-- Jack
      |          +-- Cindy
      |          +-- Library
      |
      +---- another X3D world
      |
      +---- glTF world
      |
      +---- industrial world

And the important demonstration becomes:

These worlds don't need to be built by the same engine.

23. I would therefore build a WoW adapter, not a WoW rewrite

If I were sitting beside you and Claude looking at the repository, I'd propose a very modest first architecture:

mccf/
   core/
      narrative
      ebps
      events
      dialogue
      music

   x3d/
      scene
      assets
      animation

   wow/
      world
      views
      portals
      assets
      user
      adapter

And initially:

GET /wow/world
GET /wow/views
GET /wow/portals
GET /wow/scene
GET /wow/assets/...

with read-only semantics wherever possible.

Then get one external WoW client to enter it.

That's the first gauntlet.

Not identity.

Not DID.

Not distributed simulation.

Not multiplayer.

Not shared EBPS.

Just:

Can a foreign WoW client discover and enter an MCCF world and render its X3D content correctly?

If yes, you've crossed the first meaningful boundary.

24. Then the second gauntlet

Once that works:

foreign world
       ↓
portal
       ↓
MCCF world
       ↓
view
       ↓
X3D

Then:

MCCF world
       ↓
portal
       ↓
foreign world

Now MCCF is not merely served by WoW.

It is actually participating in the graph.

That is a much more meaningful milestone.

25. Then user portability

Only after that would I attack:

user
 ↓
manifest
 ↓
MCCF

And even then I'd start with something minimal:

anonymous visitor
preferred name
avatar reference
capabilities

before tackling credentials and persistent identity.

The WoW vision explicitly makes user control and portable identity a major part of the architecture, so this eventually matters. (WebOfWorlds)

But it doesn't belong in the first prototype.

26. The biggest philosophical danger

There is one thing I'd watch very carefully.

WoW could tempt MCCF toward:

"Let's make a generic metaverse platform."

Don't.

MCCF's strength is precisely that it isn't one.

It's a small declarative composition system for making coherent interactive experiences.

WoW can provide the larger ecology.

The relationship should be:

          Web of Worlds
                │
       ┌────────┼────────┐
       │        │        │
     MCCF     Unity    Unreal
       │
    X3D/HAnim
       │
   narrative

rather than:

              MCCF
                │
         "MCCF Metaverse"
                │
       everything must use MCCF

The first is the Web.

The second is another platform.

27. My feasibility assessment

I'd score it roughly like this:

Capability	Feasibility	Difficulty
MCCF X3D world as WoW destination	Very high	Low
WoW World API facade	High	Moderate
Views / portals	Very high	Low–moderate
External X3D/glTF assets	Very high	Moderate
MCCF → WoW world graph	High	Moderate
WoW → MCCF interaction	High	Moderate
Dynamic MCCF state exposure	High	Moderate–high
Portable user identity	Medium	High
Cross-world avatar portability	Medium	High
Shared narrative state across worlds	Low–medium	Very high
Distributed shared simulation	Low	Extreme
Universal semantic interoperability	Low	Research problem

And importantly:

none of the first several rows require redesigning MCCF.

28. The really nice architectural conclusion

I think there is a three-layer standards story emerging here:

WoW

Where is the world?
How do I get there?
Who am I?
What worlds/assets can I link to?

X3D

What is the spatial experience?
What objects exist?
How are they arranged?
How do they render and interact?

MCCF

Why does this world behave this way?
What is happening?
How do characters relate?
What does the narrative do next?
How does music/animation/dialogue respond?

That's a remarkably coherent stack.

And it makes MCCF's role clearer rather than less important.

The experiment I'd actually want to see

Not a grand integration.

A tiny one.

Take Garden of the Goddess and make this possible:

                 Web of Worlds
                       │
                 ┌─────▼─────┐
                 │ WoW World │
                 │  browser  │
                 └─────┬─────┘
                       │
                     portal
                       │
                 ┌─────▼─────┐
                 │    MCCF   │
                 │   Garden  │
                 └─────┬─────┘
                       │
                    X3D/X_ITE
                       │
              Anna / Jack / Cindy
                       │
              dialogue + music
              animation + EBPS

Then put another portal inside the Garden leading back out to another WoW world.

If that works, you've demonstrated something much larger than a technical integration:

MCCF worlds are not isolated applications. They are places on an open spatial Web.

And I think that is genuinely aligned with what WoW is trying to establish. The WoW project has moved from the initial linking-worlds effort into the broader Spatial Computing WG, and its current architecture explicitly treats worlds, portals, views, users, and spatial assets as separable interoperable pieces. (WebOfWorlds)

The fact that the current ecosystem already lists X3D-capable Open Spatial World implementations makes MCCF's path unusually concrete rather than speculative. (WebOfWorlds)

My verdict: very feasible as a participant; very difficult as a fully interoperable peer; and I don't see any reason MCCF should attempt the latter initially.

In fact, I'd put this after the manuals and reliability gauntlet you were talking about, not before. The manuals can become the contract for the MCCF side of this boundary: what constitutes a runnable MCCF world, what is static, what is dynamic, what may be exposed, and what must remain local. Then the WoW adapter becomes a second, very clean conformance layer.

And that, Len, is a much more interesting next step than "make MCCF more feature-rich." It is putting the little machine you've built into an actual ecology.

MCCF: Integration into Web of Worlds