CONCEPT: realmNode - A decentralized peer-to-peer runtime for persistent MMO worlds

[Morkah]

realmNode
A decentralized peer-to-peer runtime for persistent MMO worlds

Core Idea

realmNode is a decentralized runtime that allows compatible game clients and externally published world rulesets to share a persistent MMO world without relying on one permanent central game server.

A world publisher provides:

* the compatible game client
* world data
* game rules
* runtime logic
* updates
* migrations
* publisher identity

Players run realmNode alongside that game environment.

The game client connects locally to realmNode. realmNode then communicates with other compatible realmNode peers and collectively handles networking, simulation, validation, persistence, world state, player synchronization, routing, and security.

Code: Select all

Game Client
|
v
localhost
|
v
realmNode
|
|-- P2P networking
|-- distributed simulation
|-- validation
|-- persistence
|-- storage
|-- relay
|-- cryptographic identity
|-- authority management
`-- world compatibility
|
v
realmNode Network

The publisher defines the world.

realmNode provides the distributed machinery that keeps it running.

The players collectively execute it.

1. Platform Architecture

realmNode is shared decentralized infrastructure capable of supporting many separate games, versions, rulesets, and community worlds.

Code: Select all

realmNode
|
|-- OctoWoW
|-- Vanilla-compatible world
|-- TBC-compatible world
|-- Wrath-compatible world
|-- Classic+ project
|-- Hardcore world
|-- Custom community MMO
`-- Original multiplayer game

Each world remains its own network.

Players interact only when their:

* world identity
* runtime
* ruleset generation
* client compatibility
* protocol compatibility
* persistent-state generation

agree.

realmNode organizes the architecture into three layers:

Code: Select all

+----------------------------+
| realmNode Core             |
+----------------------------+
| networking                 |
| peer discovery             |
| identity                   |
| encryption                 |
| relay                      |
| storage                    |
| sharding                   |
| authority                  |
| validation                 |
| replication                |
+-------------+--------------+
|
v
+----------------------------+
| World Runtime              |
+----------------------------+
| entities                   |
| combat                     |
| abilities                  |
| quests                     |
| items                      |
| NPC AI                     |
| world rules                |
| progression                |
+-------------+--------------+
|
v
+----------------------------+
| Client Adapter             |
+----------------------------+
| Client/version A           |
| Client/version B           |
| Custom client              |
| Original game client       |
+----------------------------+

The realmNode core works with general distributed-systems concepts:

Code: Select all

peers
messages
entities
state
authority
validators
transactions
shards
identities
signatures
worlds
versions
snapshots

The external runtime gives those concepts their game-specific meaning.

A runtime may interpret:

Code: Select all

ENTITY 10421
ACTION 183
TARGET 5572
STATE CHANGE -142

as:

Code: Select all

a character
casts an ability
on a creature
dealing 142 damage

This makes realmNode reusable across different games and world projects.

2. Local Gateway and Player Experience

The game client connects locally to realmNode.

Code: Select all

Game.exe
|
v
127.0.0.1
|
v
realmNode

From the client's perspective, realmNode provides the connection normally associated with a conventional game server.

Internally, the local node translates between the game protocol and the distributed realmNode protocol.

Code: Select all

Game Protocol
|
Client Adapter
|
realmNode Protocol
|
Peer Network

The intended player experience is:

Code: Select all

1. Install realmNode.

2. Install or select a compatible game client.

3. Install the desired world's runtime and data
   from its publisher.

4. realmNode detects available worlds.

5. Choose a world.

6. realmNode verifies the publisher,
   runtime and ruleset.

7. realmNode joins compatible peers.

8. The game launches.

9. The game connects to localhost.

10. Enter the distributed world.
    

A world browser could display:

Code: Select all

WORLD

OctoWoW Official

Publisher:
OctoWoW

Signature:
VALID

Client:
1.18.1

Runtime:
1.19.4

Ruleset Generation:
185

Players:
742

Network Health:
Excellent

Relays:
38

Verification:
FULL

The complexity of the distributed network remains beneath the ordinary game experience.

3. World Publishers, Identity and Releases

A decentralized world can still have an identifiable developer or publisher.

A project such as OctoWoW can create and maintain its world while realmNode provides the infrastructure through which players collectively operate it.

Each publisher has a cryptographic identity.

Code: Select all

OctoWoW Publisher Key
7A91-42C8-18EE-...

World definitions and releases are signed with the corresponding publisher key.

A world identity can include:

Code: Select all

World:
OctoWoW Official

Publisher:
OctoWoW public key

Compatible Client:
1.18.1 build 7272

Runtime:
OctoWoW 1.19.4

Ruleset Generation:
185

Runtime Hash:
A91C84...

World Data Generation:
185

Network Protocol:
realmNode 1

The basic relationship is:

Publishers create worlds. realmNode makes them run.

The publisher provides:

* client requirements
* world data
* runtime logic
* rules
* scripts
* database changes
* balance changes
* migrations
* updates
* new content

The realmNode network provides:

* simulation
* validation
* connectivity
* replication
* storage
* authority assignment
* persistence
* routing
* failover

A publisher can release a signed manifest:

Code: Select all

OctoWoW World Manifest

Release:
1.19.4

Publisher:
OctoWoW

Requires:
realmNode >= 0.8

Compatible Client:
1.18.1 build 7272

Ruleset Generation:
185

Runtime Hash:
A91C84...

World Migration:
184 -> 185

Signature:
VALID

The player obtains the game, world package, and updates through the publisher's chosen distribution channels.

realmNode verifies the installed world identity and connects the player to peers running the same compatible generation.

Compatible infrastructure updates can coexist where the protocol allows it.

Changes to game behavior create a new ruleset generation.

Code: Select all

Ruleset 184
|
World Update
|
Ruleset 185

Old and new generations can temporarily exist as separate logical networks.

Publishers may also define scheduled activation points.

Code: Select all

Generation:
185

Activation:
2026-09-12 18:00 UTC

Persistent-state changes can be performed through deterministic signed migrations.

Code: Select all

Generation 184
|
v
Publisher Migration
|
v
Generation 185

Every validating node can confirm that the migration produced the expected state.

Forks remain natural.

A different team may create another world based on compatible technology and publish it under its own cryptographic identity.

Code: Select all

OctoWoW Official
Publisher Key A

Community Fork
Publisher Key B

Both remain clearly distinguishable.

4. Distributed World Simulation and Authority

A world can be divided into simulation regions.

A fantasy world might expose regions corresponding to:

Code: Select all

Continent
|
|-- Region A
|-- Region B
|-- Region C
|-- Region D
`-- ...

A World of Warcraft runtime could interpret those as:

Code: Select all

Kalimdor
|
|-- Durotar
|-- Barrens
|-- Mulgore
|-- Ashenvale
`-- ...

Busy regions can split dynamically.

Code: Select all

Large City
|
|-- District A
|-- District B
|-- District C
|-- District D
`-- Central Area

Quiet areas can remain larger.

Each active region receives a temporary authority group.

Code: Select all

Region 352

Primary Simulator
|
|-- Validator A
|-- Validator B
`-- Validator C

The simulator calculates immediate world state.

Validators independently check its results.

If the simulator disappears:

Code: Select all

Primary lost
|
v
Validator promoted
|
v
New validator recruited

Simulation continues through another participating node.

Authority can move geographically toward active players.

Code: Select all

Players:
Sweden
Denmark
Germany
Finland

Authority candidates:
Northern Europe

Player location and computation location remain separate.

A player may be the only person inside a particular zone while several independent validators elsewhere in the network verify the simulation.

If only one node remains online, the world can continue locally.

Code: Select all

Game Client
|
v
realmNode
|
v
Local Simulation

Without independent validators, that state is classified as:

Code: Select all

UNVERIFIED

When more peers return, verified network operation can resume according to the world's persistence rules.

5. Latency, Determinism and Validation

realmNode distinguishes immediate simulation from persistent history.

Immediate state

Examples:

* movement
* combat
* NPC AI
* ability use
* temporary effects

Priority:

Code: Select all

speed

Persistent state

Examples:

* item ownership
* currency
* character progression
* quest completion
* guild membership
* trades
* market activity

Priority:

Code: Select all

verification
durability
consistency

Latency-sensitive actions use a fast path.

Movement can operate as:

Code: Select all

Player presses W
|
|-- local prediction
`-- send movement input
|
v
regional simulation
|
v
validation

Combat can operate as:

Code: Select all

Ability Input
|
Local Prediction
|
Regional Simulator
|
Result
|
Validator Verification

Persistent events use stronger agreement.

Code: Select all

Persistent Event
|
v
Transaction Proposed
|
v
Validator Group
|
v
Agreement
|
v
Persistent State Committed

The central latency principle is:

Consensus protects history. Immediate simulation remains fast.

Independent validators rely on deterministic runtime behavior.

Code: Select all

same starting state
+
same player input
+
same shared random seed
+
same ruleset
============

same result

Randomized game behavior therefore uses reproducible shared seeds.

For example:

Code: Select all

Simulator:
Damage = 142

Validator A:
Damage = 142

Validator B:
Damage = 142

Agreement confirms the result.

6. Node Roles and Adaptive Contribution

A realmNode instance may perform several roles.

Player Gateway

Connects the local game client to the world.

Simulator

Computes an active part of the world runtime.

Validator

Independently checks simulation results.

Storage Node

Maintains replicated persistent state.

Router

Helps peers discover routes and other peers.

Relay

Forwards encrypted network traffic.

Archive Node

Stores durable snapshots and persistent-state history.

The network assigns responsibilities according to capability.

Code: Select all

Laptop
Wi-Fi
limited upload

Roles:
player gateway
light validation

Code: Select all

Desktop
fiber
strong CPU
stable uptime

Roles:
player gateway
simulator
validator
storage
relay

Selection can consider:

* CPU
* memory
* bandwidth
* latency
* uptime
* network reachability
* reliability
* current workload

The network therefore gains usable infrastructure as capable players join.

Instances such as dungeons, raids, arenas, houses, or private spaces become temporary simulation clusters.

Code: Select all

Instance 8721

Players:
A B C D E

Simulator:
Node X

Validators:
Node Y
Node Z

When the instance ends, its temporary simulation closes while validated persistent results remain part of the world state.

Large world events can dynamically recruit additional nodes.

Code: Select all

Normal Region

3 simulators
5 validators

Code: Select all

Large Event

12 simulators
20 validators
multiple simulation partitions

Capacity scales with demand.

7. Persistent World State

Persistent data is replicated across multiple peers.

Examples include:

* characters
* inventories
* professions
* guilds
* mail
* markets
* quest state
* currency
* ownership
* world progression

A persistent shard might exist on:

Code: Select all

Shard 492

Peer 17
Peer 51
Peer 82
Peer 133
Peer 201

If one peer disappears, replicas remain available.

The network periodically creates cryptographically verifiable snapshots.

Code: Select all

World Snapshot

Generation:
185

World Height:
942991

State Root:
8A773E...

Signatures:
Validator Group

A new node can synchronize from a recent snapshot and then obtain subsequent changes.

Archive nodes preserve long-term state while ordinary players are offline.

Archive nodes can be operated by:

* players
* communities
* publishers
* volunteers
* long-running home machines
* dedicated infrastructure providers

Multiple archives provide redundancy.

Persistent economic systems receive strong validation.

Examples:

Code: Select all

item creation
item destruction
currency creation
currency destruction
trade
market settlement
ownership transfer

A cryptographically linked ledger is useful for these histories.

realmNode can therefore combine:

Code: Select all

real-time simulation
-> fast distributed authority

persistent important events
-> cryptographically verifiable history

This provides durable world integrity without placing every movement or combat action into a global ledger.

8. Networking, Peer Discovery and Relays

realmNode uses decentralized peer discovery.

Possible mechanisms include:

Code: Select all

DHT
+
cached peers
+
multiple bootstrap peers
+
manual peer entry
+
LAN discovery

Bootstrap peers introduce new nodes to the network.

After discovery, the peer network continues through distributed connections.

Where possible, nodes communicate directly.

Code: Select all

Player A <------------> Player B

Direct communication provides the lowest latency.

When a relay path is preferable:

Code: Select all

Player A
|
v
Relay
|
v
Player B

A relay forwards encrypted realmNode traffic.

Normal participants may volunteer network capacity.

Code: Select all

Relay Mode:
ON

Bandwidth:
50 Mbps

Maximum Connections:
100

Players behind restrictive NAT can establish outgoing connections to relays.

Code: Select all

Player A -----> Relay <----- Player B

This allows communication even when direct inbound connections are unavailable.

Relay eligibility can be detected automatically.

Public reachability may come from:

* port forwarding
* IPv6
* UPnP
* NAT-PMP
* PCP
* public hosting
* compatible tunneling

Connection modes may include:

Code: Select all

DIRECT

lowest latency
direct peer connection

Code: Select all

RELAYED

traffic passes through relay
peer connection is indirect

Code: Select all

STRICT PRIVATE

game peer traffic always uses relays

Relay traffic remains end-to-end encrypted between participating nodes.

The relay forwards packets without requiring access to the game payload.

9. Security and Anti-Cheat

realmNode treats every peer as independently verifiable.

Peers may:

* send invalid state
* disappear
* collude
* send malformed packets
* spam requests
* attempt impersonation
* consume resources
* use outdated software
* submit conflicting information

Player nodes submit intentions.

Code: Select all

Player:
Use Action 182 on Entity 5572.

The simulation authority determines the outcome according to the world runtime.

For example, the runtime may verify:

Code: Select all

ability available?
resources available?
target valid?
range valid?
cooldown available?
action completed?
result valid?

Cryptographic signatures identify the sender.

Deterministic simulation and independent validation establish whether the proposed state is valid.

The peer protocol uses narrowly defined message types.

Code: Select all

PLAYER_INPUT
OBJECT_UPDATE
STATE_HASH
VALIDATION_RESULT
STATE_REQUEST
PEER_DISCOVERY
SIGNED_TRANSACTION
AUTHORITY_HANDOFF
SNAPSHOT_REQUEST

Network operations are constrained by resource limits.

Code: Select all

connection limits
request limits
bandwidth limits
memory limits
CPU limits
timeouts
validation quotas
storage limits

A remote peer therefore receives only bounded access to the resources required for participation.

External world runtimes can operate through a restricted runtime interface.

Code: Select all

World Runtime
|
v
realmNode Runtime API
|
|-- state access
|-- deterministic random source
|-- entity operations
|-- simulation interface
`-- persistence interface

This creates a defined boundary between world logic and the host machine.

10. Sybil Resistance and Validator Selection

A distributed network must distinguish independent participation from large collections of artificial identities.

An attacker could attempt to create:

Code: Select all

Node1
Node2
Node3
Node4
...
Node10000

realmNode can combine multiple signals when selecting validators.

Possible inputs include:

Code: Select all

long-lived identity
node history
network diversity
resource contribution
behavioral reputation
random selection
rate-limited identity creation
independent network paths
uptime
latency

Validator selection can consider:

* stability
* CPU availability
* bandwidth
* network independence
* geographic diversity
* historical behavior
* latency
* uptime
* randomness

The selected validator group should remain difficult for one participant to predict or control.

11. Identity, Characters and Social Systems

Players can use cryptographic identities.

Code: Select all

Player Identity
|
|-- public key
`-- private key

The private key authorizes actions associated with that identity.

A world runtime can associate game entities with it.

Code: Select all

Character:
Buxor

Owner:
Public Key 7AF2...

World:
OctoWoW

State Root:
18EE...

Signed actions prove which identity requested them.

The network validates whether those actions are permitted by the world state.

Recovery systems can be built into the identity layer so that persistent player access can survive lost devices or credentials.

Traditional persistent social systems become distributed state.

Code: Select all

Guild State
-> replicated persistent state

Mail
-> signed delayed transactions

Market
-> distributed persistent state

Trade
-> validated atomic transaction

These systems favor consistency and durability.

12. DDoS Resilience and Failure Handling

A conventional multiplayer architecture concentrates availability around a small number of public endpoints.

Code: Select all

GAME SERVER
/     |     
/      |      
Player   Player   Player

realmNode spreads active responsibilities across many replaceable participants.

Code: Select all

Node A
Node B
Node C
Node D
Node E
Node F
...

If a simulator disappears:

Code: Select all

select replacement simulator

If a validator disappears:

Code: Select all

recruit replacement validator

If a relay disappears:

Code: Select all

select another route

If a storage node disappears:

Code: Select all

retrieve another replica

If a bootstrap peer disappears:

Code: Select all

use cached peers or DHT discovery

The architecture is built around one fundamental assumption:

Any individual machine may disappear at any moment.

Critical roles therefore have multiple possible providers.

Code: Select all

simulation
validation
relay
bootstrap
storage
archive
authority

The network routes around failures.

Relays also allow home nodes to keep their direct endpoint away from ordinary game peers.

Network health can degrade gradually.

Code: Select all

1000 peers
Full distributed operation

300 peers
Reduced redundancy

40 peers
Smaller validator pool

5 peers
Minimal distributed operation

1 peer
Local unverified simulation

The central availability principle is:

Code: Select all

Machines are temporary.

The world is persistent.

13. World Updates

A world publisher can release new generations independently from realmNode itself.

For example:

Code: Select all

OctoWoW Runtime 1.19
|
v
OctoWoW Runtime 1.20

This may change:

* game systems
* quests
* creatures
* items
* spells
* balance
* maps
* progression
* runtime logic

realmNode itself can evolve independently.

Code: Select all

realmNode 0.8
|
v
realmNode 0.9

Infrastructure updates might improve:

* networking
* relays
* NAT traversal
* encryption
* storage
* validator selection
* performance
* replication
* compression

Protocol-compatible realmNode versions may continue participating together.

World generations remain determined by the publisher's signed world manifest.

14. World Discovery

realmNode can present worlds through a common browser.

Code: Select all

WORLD

OctoWoW Official

Publisher:
OctoWoW

Publisher Signature:
VALID

Compatible Client:
1.18.1

Runtime:
1.19.4

Ruleset:
185

Players:
742

Network Health:
Excellent

Validators:
Healthy

Relays:
38

Persistence:
FULL

Verification:
FULL

A second world might appear as:

Code: Select all

WORLD

Community Classic+

Publisher:
Community Project

Compatible Client:
1.12

Runtime:
0.7

Ruleset:
42

Players:
116

Network Health:
Good

The browser becomes the meeting point between externally published worlds and the shared realmNode infrastructure.

15. The OctoWoW Example

An OctoWoW deployment could work as follows:

Code: Select all

OctoWoW Developers
|
|-- develop the game
|-- publish client requirements
|-- publish world data
|-- publish runtime
|-- publish ruleset
|-- publish updates
`-- sign releases
|
v
Players install OctoWoW
and realmNode
|
v
realmNode verifies
the world identity
|
v
Compatible peers discover
one another
|
v
Distributed simulation
|
+-- simulation
+-- validation
+-- replication
+-- persistence
+-- routing
`-- failover
|
v
OctoWoW World

The OctoWoW developers continue building:

* zones
* quests
* classes
* spells
* items
* balance
* systems
* content updates

realmNode supplies the decentralized infrastructure through which compatible players operate that world.

The world publisher remains the author.

The players become the infrastructure.

16. Publisher Independence

Publishing infrastructure and live simulation are separate systems.

A publisher may operate:

Code: Select all

website
forum
documentation
download service
update service
community tools

The running world exists through realmNode peers.

This means an established player network can continue operating independently from any single web service or hosting endpoint.

The same applies to realmNode itself.

Once peers possess compatible software, world data, runtime state, and known peer information, the network can operate through its distributed discovery mechanisms.

17. Development Strategy

realmNode can be developed from a minimal distributed simulation outward.

Prototype 1

Code: Select all

3 nodes
1 shared object
movement
temporary authority
replication
validation
node failure
authority reassignment

Test:

Code: Select all

Node A OFFLINE
|
v
Node B takes authority
|
v
simulation continues

Prototype 2

Add:

Code: Select all

cryptographic identities
signed messages
encrypted transport
persistent state
snapshots

Prototype 3

Introduce malicious participants.

Test:

Code: Select all

invalid movement
fake state
bad signatures
packet spam
conflicting state
outdated protocol

Prototype 4

Add:

Code: Select all

relay support
NAT traversal
relay discovery
relay failover
privacy modes

Prototype 5

Build the generic runtime interface.

Code: Select all

realmNode
|
v
Runtime API
|
v
Test World Runtime

Prototype 6

Connect a real game client through a client adapter.

Code: Select all

Game Client
|
v
localhost
|
v
realmNode
|
v
Test Distributed World

Prototype 7

Connect an existing MMO-compatible runtime and begin testing:

* real movement
* world regions
* combat
* NPC simulation
* character persistence
* instances
* reconnects
* migrations
* high player density

The architecture can then expand to additional clients and worlds.

18. Fundamental Principles

World Principle

Code: Select all

The publisher defines the world.

Execution Principle

Code: Select all

The players collectively execute it.

Infrastructure Principle

Code: Select all

realmNode provides the distributed server layer.

Authority Principle

Code: Select all

Authority is temporary and transferable.

Security Principle

Code: Select all

Every important state transition can be independently verified.

Availability Principle

Code: Select all

Every critical role can move to another node.

Compatibility Principle

Nodes simulate together when they agree on:

Code: Select all

world identity
publisher identity
runtime
ruleset generation
client compatibility
network protocol
persistent-state generation

Latency Principle

Code: Select all

Movement:
fast

Combat:
fast

Simulation:
fast

Trade:
strong validation

Persistence:
strong consensus

Persistence Principle

Code: Select all

Temporary machines maintain persistent worlds.

Final Principle

Traditional MMO architecture places the world inside a server.

realmNode turns the server into a network.

The publisher defines the world. The players collectively keep it alive.

A project such as OctoWoW defines its game, client compatibility, rules, content, and updates.

realmNode determines which participating nodes currently simulate, validate, route, replicate, and preserve that world.

The game remains the creation of its publisher.

The server becomes a shared protocol executed by the community.

You can have that, do with it what you wish!
/Morkah

[Cartman]

Thank you for copy+pasting from GPT.

[Morkah]

Thank you for copy+pasting from GPT.

you are welcome.