v0 and modular v1 comparison :: Unofficial EVE Frontier Development Notes

Architecture and lifecycle

Mon, 01 Jan 0001 00:00:00 +0000

v0’s world package models concrete shared assemblies. An assembly owns fixed fields such as its deterministic tenant/item key, owner-cap ID, status, location, energy, and metadata; anchoring and sharing are direct lifecycle operations. v1’s active packages are core, character, and inventory; the former world package is archived. An Entity is deterministically derived from a tenant-scoped key and holds dynamically installed typed modules. flowchart LR V0[Fixed shared assembly] --> Fields[Fixed domain fields] V1[Entity] --> Modules[Installed Module values] Modules --> Action[Named Action] Action --> Request[Locked Request] Request --> Requirements[Typed requirements] Requirements --> Complete[Unlock and complete] install, uninstall, action changes, and interaction lock an entity and return a no-ability Request. Each Requirement must be consumed before completion. This retains Sui Move, shared objects, deterministic identity, tenant partitioning, on-chain rules, and atomic transactions, but requires builders to compose a request flow rather than call a fixed assembly API.

Domain coverage

Mon, 01 Jan 0001 00:00:00 +0000

The table classifies source at the reviewed commits. Archived legacy is not active v1 functionality; generic Entity primitives do not prove that a gameplay domain has been ported. v0 domain or v1 module v1 state Evidence and consequence Entity, Action, Request, Requirement Active v1 implementation core supplies the modular foundation. Character identity Redesigned equivalent Identity is an installed module, not v0’s Character layout. Item and storage inventory Active v1 implementation Active inventory is request-routed. Assemblies: gate, turret, storage unit Archived legacy only v0 modules remain under contracts/archive/world. Network nodes, killmails, rifts No active v1 equivalent / not yet ported Present on v0/main, absent from the active v1 package set. Fuel, energy, status, metadata Archived legacy only v0 primitives are retained in archive, not active modules. Access, location, registry Partially represented Active core has services and registry concepts, with materially different interfaces and checks. Extension examples Archived legacy only Examples were moved below archive. v1 deployment Deployment unknown or separately evidenced dev/world.json names some artifacts, not every active package or a production environment. The coverage rows are intentionally conservative: a domain can be partially represented by generic platform features without possessing its v0 lifecycle, type, API, or authorization checks.

Identity, access, and location

Mon, 01 Jan 0001 00:00:00 +0000

v0 Character is a dedicated deterministic shared object carrying tenant identity, tribe, wallet, metadata, and owner-cap identity. v1 uses a generic Entity with an installable Identity module. Package IDs, layouts, capabilities, and event contracts are therefore incompatible. v0 combines GovernorCap, sponsor-aware AdminACL, and typed OwnerCap; see access_control. v1 represents authorization as requirements consumed while completing an Entity request and uses AccessCap. A caller cap records the authorized entity for downstream routing; it must not be described as ownership of an action target.

Inventory, bridges, and events

Mon, 01 Jan 0001 00:00:00 +0000

v0 inventory dynamically attaches inventory to an assembly and moves transit items with parent, tenant, and location metadata. Its bridge flow relies on game-server/location-proof handling and emits domain events carrying assembly and character identity. v1’s active StorageInventory is an Entity module with a main inventory and lazy ephemeral inventories keyed by the request-authorized entity. Item type and quantity requirements constrain operations. Tenant-scoped identity is derived from the enclosing EntityKey and emitted event keys, rather than retained as item-carried provenance. Builders must configure the enclosing action and consume the module-scoped requirements.

Developer experience and operations

Mon, 01 Jan 0001 00:00:00 +0000

v0 exposes direct, domain-specific TypeScript scripts around the world package. v1 adds world-sdk, whose PTB builders resolve MVR package names or local overrides and compose Entity creation, cap verification, actions, requests, identity, and inventory. That is an architectural integration change: applications build modular request flows. package.json excludes archive packages from active Move build/lint/test and adds SDK checks. Its pnpm version, Biome/Husky choices, workflow triggers, and cache mechanics are branch-maintenance divergence unless a consumer relies on them.

Migration guidance

Mon, 01 Jan 0001 00:00:00 +0000

Do not reuse v0 package/type identities, object layouts, OwnerCap assumptions, fixed-assembly calls, or v0 event schemas with v1. Start by mapping the integration’s concrete v0 domain to the coverage state, then decide whether it has an active module, a redesigned equivalent, only partial platform support, or no active port. For active modules, create or locate the deterministic Entity, install/configure the module through its typed request, supply and consume requirements in order, and complete the request. Update PTB code to the SDK builders, rework indexers from active event sources, and make authorization/location/bridge checks explicit in tests.

Evidence, contradictions, and limits

Mon, 01 Jan 0001 00:00:00 +0000

Evidence has an order of authority: pinned Move source and tests establish implemented behavior; manifests and deployment artifacts establish only their explicit environment facts; upstream prose is contextual and can be stale. All factual upstream references in this chapter are immutable commit URLs from the canonical cursor. The reviewed dev tree retains v0 source below contracts/archive, while active packages are elsewhere. The decoder README’s contracts/world wording conflicts with that active layout. The dev deployment manifest lists core and character but not inventory. These are recorded contradictions/limits, not gaps to fill with inference.