So a shared struct instance has a stable identity across postMessage, right? To expand on my earlier idea, I think we don't need any stable identity for module blocks or even symbols, we can just use shared structs themselves to dynamically attach behavior to a shared struct kind, given some built-in wiring. Here is a gist where I explore that approach: https://gist.github.com/mhofman/aa23fcc88e1ccd031a3c34f88577eaf7

It does not require any new syntax, or extra magic in postMessage (like module blocks, or symbol identities being preserved). It only requires an automatically generated static property on shared struct classes that represent the kind, and some built-in behavior, plus the dynamic prototype lookup we discussed of course. I'm actually wondering if this could be prototyped (pun intented) in the current experiment.

• the goal is to have: the instance of a shared struct to exist in shared memory, and the reference to this is passed around directly. There is not a per-agent wrapper adding a layer of indirection for prop access.

• if there is a dynamic lookup when [[prototype]] is accessed, if returned functions come from the calling realm then this means that a shared-struct passed between realms (node-VM, or same-origin-iframe, etc) then that means the value returned by getPrototypeOf can observably change, which violates the current description of the sealed integrity level.

• cont: if the lookup is 'cached' per-agent, maybe on first read, then this implies there is additional memory usage for a per-agent-per-instance cache

though I guess that itself can be done in userland

const id = new shared struct class ID{}

shared struct class SSC {
  __type__ = id
}

Is there any reason the origin trial API couldn't be extended to provide a registration mechanism for the shared struct type with a user-provided unique ID (just a string, but could contain a URI, UUID, etc.) and the thread-local prototype to use?

// + fairly flexible
// - requires setup on receiver end, correlation of struct type identity.
// - requires encapsulation for constructor logic

// data.js
// data only structs don't require registration and have no shared type identity.
export const DataOnly = new SharedStructType(["foo"]);

// vector2d.js
// data+behavior structs require registration to define type identity
const { type: _Vector2D, register } = SharedStructType.prepare(["x", "y"]);

// custom construction behavior
export function Vector2D(x = 0, y = 0) {
    const _this = Reflect.construct(_Vector2D, [], new.target);
    _this.x = x;
    _this.y = y;
    return _this;
}

// prototype methods
Vector2D.prototype.distanceTo = function (v) {
    const dx = this.x - v.x;
    const dy = this.y - v.y;
    return Math.sqrt(dx * dx + dy * dy);
};

// Register the type identity, constructor, and prototype to use for this struct type in this thread.
// NOTE: register(id, constructor [, prototype])
register("e3a9bd1f-0f64-4848-b255-3c629d0c44a3", Vector2D, Vector2D.prototype);

export { Vector2D };

// main.js
import { DataOnly } from "./data.js";
import { Vector2D } from "./vector2d.js";
const data = new DataOnly();
data.foo = "data only, no behavior";

const v1 = new Vector2D(1, 2);
const v2 = new Vector2D(3, 4);
const worker1 = new Worker("worker1.js");
worker1.postMessage([data, v1, v2]);

const worker2 = new Worker("worker2.js");
worker2.postMessage([data, v1, v2]);

// worker1.js
// worker1 does not import Vector2D, so can only access its data.
parentPort.on("message", ([data, v1, v2]) => {
    data.foo; // "data only, no behavior"
    v1.x; // 1
    v2.y; // 4
    // NOTE: prototype not registered. This could mean an invalid prototype chain (thus every non-data
    // member acces would throw), or a default prototype chain (where prototype methods throw by nature
    // of them just being `undefined`).0
    v1.distanceTo(v2); // error
    v1.toString(); // error?
});

// worker2.js
// worker2 imports Vector2D, which causes registration as a side-effect.
import "./vector2d.js";
parentPort.on("message", ([data, v1, v2]) => {
    data.foo; // "data only, no behavior"
    v1.x; // 1
    v2.y; // 4
    v1.distanceTo(v2); // ok
    v1.toString(); // ok
});

The user-supplied type identity would allow the user to define the same struct in different bundles, and the registry wouldn't be global, but would rather be thread-local, so there'd be no global mutable registry to worry about. It also doesn't really matter if the prototypes differ slightly between realms/threads, since they all access the same underlying data.

We could eventually extend this to syntax, possibly even using decorators:

// data.js
export shared struct DataOnly {
    foo;

    // NOTE: constructors don't necessarily require registration
    constructor(foo) {
        this.foo = foo;
    }
}

// vector2d.js
// a syntactic declaration doesn't necessarily need to set a type identity, since
// we could infer one for it based on path to the containing file and its offset within
// the file. However, we could still allow the user to explicitly specify type identity
// for use with bundlers, or other cases where the inferred type identity might not
// be sufficient.

@struct.id("e3a9bd1f-0f64-4848-b255-3c629d0c44a3")
// or: @struct.id("https://babylonjs.com/5.0/Vector2D")
export shared struct Vector2D {
    constructor(x, y) {
        this.x = x;
        this.y = y;
    }
    distanceTo(v) {
        const dx = this.x - v.x;
        const dy = this.y - v.y;
        return Math.sqrt(dx * dx + dy * dy);
    }
}

// vector2d.js
// Each shared struct type, whether data only or "prepared" has its own unique type
export const vector2Dtype = SharedStructType.prepare(["x", "y"]);

const _Vector2D = SharedStructType.getConstructor(vector2Dtype);

// custom construction behavior
export function Vector2D(x = 0, y = 0) {
  const _this = Reflect.construct(_Vector2D, [], new.target);
  _this.x = x;
  _this.y = y;
  return _this;
}

// prototype methods
Vector2D.prototype.distanceTo = function (v) {
  const dx = this.x - v.x;
  const dy = this.y - v.y;
  return Math.sqrt(dx * dx + dy * dy);
};

SharedStructType.registerPrototype(vector2Dtype, Vector2D.prototype);

// main.js
import { Vector2D, vector2DType } from "./vector2d.js";
const v1 = new Vector2D(1, 2);
const worker = new Worker("worker.js");
worker.postMessage([vector2DType, v1]);

// worker.js
// worker imports Vector2D, which causes registration as a side-effect.
import { Vector2D, vector2DType } from "./vector2d.js";

const v2 = new Vector2D(3, 4);

parentPort.on("message", ([mainVector2DType, v1]) => {
  SharedStructType.registerPrototype(mainVector2DType, Vector2D.prototype);
  assert(mainVector2DType !== vector2DType);
  assert(
    SharedStructType.getConstructor(mainVector2DType) !==
      SharedStructType.getConstructor(vector2Dtype)
  );
  assert(v1 instanceof Vector2D); // by virtue of sharing a prototype
  v1.x; // 1
  v1.distanceTo(v2); // ok
  v1.toString(); // ok
});

SharedStructType.getConstructor() is needed to allow the program to avoid duplicating type definitions in each agent/realm. I think the burden of such deduplication should be on the program, not on the engine.

If the engine had to deduplicate itself, you'd either need a user provided type identifier at "prepare" time, and a global lock around such type definitions, or you'd need to somehow be able to collapse separate definitions into a single one. In either case you'd have to figure out what to do if the shape definition does not match, and in the case of definition collapse, how do you communicate the error to the program?

By having the type definition generate the unique type identifier, you avoid all those complications in the engine, at the cost of putting more type hydration burden on the program.