The P2P Metaverse: Distributed Foundations for Virtual Worlds

Thousands of people roaming one virtual space: supporting that load on central servers alone is expensive. From the limits of centralization (server cost, single points of failure, item ownership) through P2P and decentralized approaches, to the realities of NFT-based asset portability, this page draws on more than two decades of research.

The limits of the centralized metaverse

The metaverses and MMOGs (massively multiplayer online games) dominant today are client-server systems in which a fleet of servers run by the operating company holds every player's state in one place. That design carries three fundamental limits.

• Server cost: as concurrent users grow, server count, bandwidth, and operations staff must scale more than linearly, and the operating company foots the entire bill. When popularity spikes suddenly, capacity often can't keep up, leading to connection caps and login queues.
• Single point of failure: if the servers holding world state go down, the "world" as players see it disappears with them. Once a service reaches end-of-life, every virtual asset, structure, and social record built up over its lifetime is lost at once.
• Item ownership: an item a player bought or earned is ultimately just a database record owned by the operating company. A change of terms of service, an account suspension, or a shutdown can unilaterally strip access to assets a player paid for: a risk built into the architecture itself.

Interest management (AOI): synchronize only what you can see

Synchronizing every participant and every object in a whole world is impossible, so the golden rule is to exchange only information around each avatar: its AOI (Area of Interest). The central question of P2P NVE (networked virtual environment) research has been how to maintain this "connect only to nearby peers" structure. Landmark approaches include VON, which manages neighbor relations by partitioning space with Voronoi diagrams; pSense, which maintains a position-based multicast structure; and Colyseus, which assigns manager nodes per object.

One notable pattern wires AOI directly into P2P connection maintenance: cap the number of connections each node keeps open at once, then choose which peers fill those slots by two criteria together: (a) spatial distance and (b) directional diversity, partitioning the sphere of directions around a node into a fixed set of sectors and keeping the nearest peer found in each sector. Distance alone tends to cluster a node's connections with whichever single group of neighbors happens to be nearby, leaving the opposite direction essentially unmonitored; deliberately spreading connections across directions corrects that bias.

Caching can be made spatial in the same spirit. When evicting cached world content (models, textures, state for objects out of view), weight the eviction decision by distance from the node's current position rather than treating it as a plain LRU problem: never evict anything within a protection radius around the current position, and let eviction probability grow the farther content sits from it. Data explicitly pinned by the application is exempt from this policy entirely, the same "cache vs. storage" distinction that shows up wherever caching and durable storage are layered together.

World types and architecture: how to divide the world and how to deliver it

Designing a metaverse requires two independent decisions up front: how to divide the world among players (the world type), and how to deliver that world's state to each client (the architecture).

World types: parallel worlds vs. a single world

As concurrent population grows, worlds are handled in one of two fundamentally different ways.

• Parallel worlds (instancing): run multiple simultaneous copies, or instances, of the same layout and content, and route players into one of them. Capping the population per instance keeps AOI computation and state-sync traffic within a predictable range, making horizontal scaling straightforward. Most MMORPG dungeons, and the "channel splitting" used in crowded areas, work this way. The drawback: players in different instances can never meet, which erodes the feeling of "everyone sharing one world."
• A single world (seamless world): no copies exist; every player physically shares the exact same space. The world is partitioned into cells, synchronized only with nearby nodes via the AOI approach covered above, but because there are no copies to spread load across, a "hotspot" where players cluster in one popular area can spike load on that single cell with no escape valve. Spatial-partitioning P2P sync schemes like VON and pSense exist precisely to make this single-world model work.

In practice the two aren't mutually exclusive: most implementations keep the wide open field as one seamless single world while turning only dungeons and raids into parallel-world instances.

Metaverse architecture: state replication vs. rendering streaming

Where world type decides who shares a space, architecture decides how that space's appearance reaches each client. Two broad approaches exist.

• State replication: the server or peers distribute only lightweight "state" (position, orientation, animation state, events), and each client renders the scene independently on its own machine using locally held 3D models and textures. Every technique covered on this page, including AOI-based sync, CRDTs, and dead reckoning, assumes this architecture. Bandwidth stays small and client hardware directly determines visual fidelity, but every client must already hold the same assets, and hiding state mismatches requires the interpolation and extrapolation techniques discussed next. Nearly every P2P metaverse implementation, mistlib included, uses this approach.
• Rendering streaming: a powerful server-side GPU actually renders the video frames and streams them to the client, the same idea as cloud gaming. The client is a "thin" device that just displays video and sends input back, letting even low-spec hardware experience high-fidelity graphics. But because every rendered frame requires a round trip, it is extremely latency-sensitive, pairs poorly with latency-critical uses like VR (discussed below), and drives up server-side GPU cost. Because it structurally depends on a single rendering server, it is a fundamentally centralized architecture that is largely incompatible with a P2P metaverse.

Because a P2P metaverse commits to state replication, it doesn't get to say "the server holds the truth and the client just displays it" the way rendering streaming does; each client is responsible for reconstructing a smooth picture on its own from the state it receives. That reconstruction is exactly what interpolation, extrapolation, and tick-rate design, covered next, are for.

Infrastructure components: CDN, signaling, and persistence

The infrastructure that actually runs a metaverse can't be reduced to a single "state replication vs. rendering streaming" axis. Regardless of topology, almost every implementation needs three components with fundamentally different characteristics.

• Asset delivery (CDN): heavy static assets (3D models, textures, audio) don't change per session, so they're typically kept off the real-time state-sync channel and delivered via a CDN (content delivery network) instead. Pre-caching them at geographically distributed edge servers lets each user pull from whichever location is physically closest, keeping latency low. Roblox delivers models, textures, and audio through what it calls "Asset Servers," a CDN that leans on edge data centers to shorten the physical distance to each player. Even decentralization-minded projects tend to land on the same split: hand "heavy" asset delivery off to a CDN or decentralized storage such as IPFS, and keep only "lightweight" state sync on P2P. The "the asset itself usually lives off-chain" problem covered below for NFTs is fundamentally a design question at exactly this asset-delivery layer.
• Signaling and matchmaking: even in a P2P system where peers exchange data directly, some rendezvous point that brokers "who connects to whom first" is unavoidable. As covered on the WebRTC and NAT traversal pages, relaying through STUN/TURN servers and exchanging connection info through a signaling server are practically required: one of the few genuinely central elements even systems that bill themselves as pure P2P still need.
• Persistence and account management: user accounts, friend lists, world metadata, and inventory records demand strong consistency more than real-time responsiveness, so most implementations persist them to a dedicated backend API (database). Most of the data that requires linearizability, covered below, ends up handled at exactly this persistence layer.

State-sync topology: a continuum from pure client-server to pure P2P

The sync topology, meaning who connects directly to whom and who holds the canonical state, is easiest to understand as a single spectrum. Put pure client-server and pure P2P (full mesh) at the two ends, and nearly every real implementation lands somewhere in between, as a client-server hybrid.

• Pure client-server: every client connects to a single authoritative server, which alone holds the canonical state. Clients can only send their own inputs; they can never self-report position or outcomes (the server-authority model). Roblox is the textbook example: by making the server the single source of truth, it structurally rules out entire classes of cheating, such as flyhacks or speedhacks. To hide perceived latency, clients pair this with client-side prediction, locally and instantly simulating the effect of their own inputs. The weakness is exactly the server cost and single point of failure discussed at the top of this page.
• Client-server hybrid (P2P-assisted): matchmaking, the canonical record of assets, and any judgment that needs cheat-proofing stay on the server, while high-frequency, low-stakes data, such as position sync, voice, and video, flows directly between nearby clients over WebRTC. This cuts server load and latency while keeping operations that must never succeed twice, such as asset transfers, on the central side, together with the mutual-exclusion machinery covered below, striking a balance between cost and safety. It's the practical landing spot most P2P metaverse implementations, mistlib included, actually adopt.
• A platform like VRChat, built on Photon Engine, is an interesting variation on this middle ground. All of its traffic actually flows through Photon's cloud servers, a genuine client-server architecture rather than direct peer-to-peer connections, but authority over syncing any given object is delegated to the master client: whichever player has been in that instance the longest. The server stays the relay point for all traffic while authority over state is distributed out to a peer, a good example of designing topology and authority as separate, independent decisions.
• Pure P2P (full mesh, DHT-based): no server at all: every participant connects directly to every other as an equal. DHTs handle peer discovery and gossip protocols propagate state to support this. In theory it drives both the single point of failure and operating cost to zero, but the practical walls are large. A full mesh where everyone connects directly to everyone else grows connection count as O(n²), running into the same shape of wall as PBFT's communication overhead. NAT-traversal success varies peer by peer, so maintaining connections to every peer is never guaranteed, and the question of who finally settles an operation requiring linearizability, such as an asset transfer, has no answer without the heavy machinery of a distributed consensus algorithm. For these reasons, essentially no "pure P2P" metaverse has shipped as a consumer service; it remains confined to academic research such as VON and pSense.

Most implementations aiming at a "decentralized metaverse" ultimately land on a client-server hybrid rather than pure P2P. This is less a technical compromise than the infrastructure-level expression of the design principle from the consistency-model section below: loose for position, strict for assets. Keep low-risk, high-frequency data light on P2P, and hand only the high-risk data that demands consistency over to a server or distributed consensus. That division of infrastructural labor matters more in practice than theoretical purity of P2P-ness.

Organizing by consistency model: loose for position, strict for assets

Not all information exchanged in a virtual world is equal. Some tolerates a little drift as long as the next update converges it, while other data causes real economic damage the moment a single instance goes wrong. Demanding the same strength of consistency for both wastes cost for no benefit. Deciding which consistency model applies to which data is the core of P2P metaverse design.

Positional consistency: why eventual consistency is enough

Avatar and object position sits at the loosest rung of the consistency ladder: eventual consistency, which promises only that all replicas will eventually converge to the same state once updates stop. Position tolerates this well: a little lag or a momentary mismatch does no harm to the experience as long as the next frame naturally corrects it.

• Instead of sending coordinates every frame, extrapolate position from the velocity vector and transmit corrections only when the error exceeds a threshold, a classic technique in the NPSNET tradition (dead reckoning).
• Interest-weighted fidelity: Donnybrook made large-scale P2P FPS feasible by updating the players you are looking at more frequently than the rest.
• Measured avatar mobility: measurement studies of Second Life and MMOGs revealed strong hotspot behavior, with avatars clustering at particular locations, informing load-balancing designs based on octrees and space-filling curves.

Real coordinate-sync implementations usually combine dead reckoning's forward-looking extrapolation with interpolation, which smoothly blends between two already-received past snapshots. Extrapolation predicts a future position from the latest data and adds no extra delay, but a wrong prediction produces a visible "snap" when it gets corrected. Interpolation goes the other way: it smoothly replays between two past snapshots, so it only ever displays values that were actually received, with no snapping, at the cost of deliberately replaying a few tens of milliseconds to 100ms in the past. Most game-engine netcode adopts a hybrid: extrapolate (client-side predict) your own input for instant response, and interpolate everyone else's avatar for smoothness. Your own controls demand zero perceived latency; a little added delay on everyone else usually goes unnoticed.

Extra considerations for VR: in VR, your own head and hand motion is never synchronized over the network at all: headset sensor values must reach the render pipeline locally and instantly. Even tens of milliseconds of added delay here creates a mismatch between what your eyes see and what your inner ear feels, causing VR sickness, so your own viewpoint must always be handled purely locally, with the network never in the loop. Other players' avatars are a different story: stereoscopic depth and wide peripheral vision make positional drift and snapping far more noticeable than on a flat screen, so implementations generally favor interpolation over extrapolation for remote avatars, trading a bit of added delay for smoothness. It is also common to sync only the three tracked points a headset and controllers actually report (head and both hands, or 3-point tracking) and reconstruct the rest of the body locally via inverse kinematics (IK), cutting the amount of state that needs to be synchronized in the first place.

Sync frequency (tick rate): position doesn't need to be sent every rendered frame (90–120Hz in VR, roughly 60Hz on a typical display); most implementations throttle network sends to around 10–30Hz and fill the gap with interpolation and extrapolation to save bandwidth. Donnybrook's interest-weighted quality adjustment, updating whoever you're looking at more often, is itself a way of making this tick rate vary with AOI. In VR especially, keeping the tick rate elevated for nearby nodes matters for the precision close-range interactions need, such as your hand grabbing or manipulating a nearby object.

Data consistency and CRDTs: how much temporary disagreement is acceptable

Unlike position, shared world state, such as a door's open/closed flag, a switch's setting, or the placement of non-combat objects, needs a somewhat stronger guarantee. That is where CRDTs (conflict-free replicated data types) come in: data types that automatically converge to the same state across all replicas, with no central arbiter, regardless of the order updates arrive. Simple data types, such as an LWW-Register (Last-Write-Wins) for "the latest write to an object wins" or an increment-only counter, are a natural fit; but continuous, physics-driven position updates and complex interactions involving several people acting at once are hard to reconcile into a natural-looking convergence with CRDTs alone, and remain an open research problem. All a CRDT guarantees is that everyone eventually settles on the same state, not when, or on which value, that convergence happens. That distinction is exactly what separates it from the asset-class data discussed next.

The item duplication problem: where weak consistency wrecks an economy

The clearest way eventual consistency's weakness bites is the item duplication ("dupe") problem, reported again and again across many MMOs. The typical cause: a single item's state transition (a completed trade, a drop-and-pickup, a transfer between servers) gets processed simultaneously and independently on more than one node or server, and both sides commit to "success." In a centralized system backed by a single database, row locks and transactions (ACID properties) make this kind of race structurally impossible. In a P2P or multi-server setting, though, nothing guarantees that every node returns the same answer to "who holds this item right now." This is fundamentally the same shape of problem as the double-spend problem covered in attacks & defenses: the question in both cases is whether you can make it technically impossible to use the same asset in two places at once.

Mutual exclusion: preventing the same thing from being processed twice at once

Preventing item duplication structurally requires controlling an asset's state transitions exclusively, ensuring only one such operation can be in flight at any given instant.

• Centralized locking: with a single database, row locks or transaction serialization (the Serializable isolation level) achieve mutual exclusion naturally. It is the simplest and most widely deployed solution.
• Distributed locking: across multiple servers, a practical middle ground is to let a single lock server, Redis, for instance, arbitrate "who may touch this item right now." The lock server becomes a single point of failure, but the implementation stays simple.
• Consensus-based exclusion: in a fully distributed setting that won't tolerate even a lock server as a single point of failure, a distributed consensus algorithm has every node vote on the global order of "who processed first." A blockchain's process of packing transactions into a block and finalizing it is, in effect, exactly this kind of consensus-based mutual exclusion.

Linearizability: the strictest consistency asset operations demand

Linearizability is the strongest guarantee on the consistency ladder. It requires that even concurrently issued operations appear, to every node, as if each executed sequentially at a single instant consistent with real-time order, producing the same observed result everywhere. Operations that must never succeed twice, such as crediting or debiting a currency balance or transferring ownership of a unique item, need exactly this strictest guarantee.

The consistency ladder loosens its guarantees the further you descend from linearizability at the top, trading strictness for scalability and performance.

In practice, P2P metaverse design comes down to not demanding the same strength of consistency for every piece of data. Handle position with lightweight eventual consistency, and reserve the "heavy" machinery that linearizability requires for currency and unique-item transfers alone. This division of labor confines costly mechanisms like distributed consensus and multisig to the moments that genuinely need them, keeping the system scalable overall.

Real attempts at a P2P and decentralized metaverse

A "fully P2P metaverse" remains, for now, largely a research proposition, but some services have adopted decentralized techniques in part. Decentraland manages ownership of land and wearables as NFTs on Ethereum (and Polygon), separating the record of who owns what from any single company's database. Real-time scene rendering and synchronization, however, handled by so-called catalyst nodes, still depends on servers run by the operating community, making the actual arrangement a hybrid: "decentralized ownership, semi-centralized execution."

Webaverse set out to be an open-source, web-based 3D engine that stores assets on decentralized storage such as IPFS, aiming to let anyone host their own world. What these efforts show is that "recording ownership" and "synchronizing a large, real-time world" are separate problems: the former suits a distributed ledger well, while the latter remains a demanding area that still needs mature DHTs, NAT traversal, and state-synchronization protocols.

NFTs and asset portability: the ideal and the reality

An NFT (non-fungible token) can move the record of "who owns this item" off a single company's database and onto a blockchain, a distributed ledger, offering one answer to the item-ownership problem. In principle, the ownership record persists on-chain even after a service shuts down. In practice, though, several walls remain.

• The asset itself usually lives off-chain: 3D models and textures are far too large to store directly on a blockchain, so an NFT is usually just a pointer to a URI on IPFS or on a centralized CDN. If the referenced storage service goes offline, the ownership record survives but the renderable asset it points to is gone: link rot, in effect.
• No cross-platform compatibility: using an NFT wearable bought in one game inside a different metaverse requires both platforms to share the same avatar skeleton, mesh format, and scale conventions. In practice every platform uses its own proprietary format, leaving a wide gap between the marketing promise of 'own it once, use it anywhere' and what actually works.
• Transaction costs and royalties: minting and trading NFTs incurs blockchain transaction fees (gas), and enforcement of creator royalties on resale varies by marketplace and chain implementation, with no universal guarantee.

Business model and sustainability: the "content first, or community first?" dilemma

What actually decides whether a metaverse takes off matters more than how well-engineered its sync layer is: the classic chicken-and-egg dilemma. Users show up because a world already has a lively community and content; creators pour time into building content because a world already has users. At launch, though, both are zero. This is the cold-start problem long studied in platform-business theory, and the metaverse is no exception.

Network effects: a wall specific to the metaverse

A metaverse's experiential value is dominated by network effects (Metcalfe's law), which hold that value grows roughly with the square of the participant count. No matter how smooth your sync or how well-tuned your AOI, a world with only a handful of people in it delivers close to zero experiential value. Put differently, great sync technology alone cannot pull in users; the non-technical design question of how to bootstrap an initial base of users and content is what actually decides a metaverse's fate.

Why decentralized systems start colder

Centralized platforms have overcome this by concentrating capital and decision-making. An operating company can commission flagship launch content itself, pay creators to show up, or focus tightly on one small, high-energy community before expanding, all made possible by concentrating money and authority in one place to build initial momentum. A decentralized or P2P metaverse, by contrast, has no such central actor to prime the pump (or deliberately refuses to have one), which tends to make its cold-start problem worse. The very design philosophy that treats every participant as equal ironically makes it harder to answer the question of who subsidizes the first step.

Speculation as a false start, and its limits

Many NFT-based metaverses tried to solve this with speculative excitement around land-NFT sales. The expectation of price appreciation pulls users in and can stage a temporary boom, but this doesn't actually solve the cold-start problem. What shows up is often not "participants who want to create and consume content" but "investors betting on appreciation," and concurrent user counts crater the moment speculative fever cools. A sustainable business model needs revenue generated from ongoing use and trade, such as marketplace fees, subscriptions, or a share of the creator economy, rather than one-time asset-price appreciation, a question that also connects to DAO treasury management.

The strangeness of "buying land" in the first place

Why do people buy metaverse "land" at all? The price of physical real estate is backed less by the scarcity of square footage itself than by actual, observable use: people gathering there, passing through, living there. A virtual "parcel," by contrast, is scarce only because an operating company's smart contract declares that a given set of coordinates has a fixed supply: scarcity by contractual rule, not by physical law. A case that crystallizes this difference: in November 2021, 116 parcels in Decentraland's Fashion Street district sold for roughly $2.4 million (618,000 MANA), bought by Metaverse Group, a subsidiary of the crypto firm Tokens.com, and widely reported at the time as a record for metaverse real estate. The buyer said it would host digital fashion events, but no prior visitor numbers or usage data existed to justify that price.

About a year later, in October 2022, CoinDesk reported, based on data from the analytics firm DappRadar, that the entire Decentraland ecosystem, then valued at roughly $1.3 billion, had just 38 "active users" in a 24-hour period. That figure came from DappRadar's narrow definition, unique wallets that directly interacted with a smart contract, and Decentraland disputed it, saying the platform actually averaged around 8,000 users per day. Whichever number you take, the question remains whether the foot traffic to justify a $2.4 million price tag genuinely existed at the time.

Prime physical real estate is priced against an observable demand signal: how many people actually pass through or use the space. A virtual parcel's value, by contrast, rests only on artificial scarcity manufactured by the operator's own code and on expectations of future user growth, arguably making it a category error to describe both under the same word, "real estate." Indeed, according to research from CoinGecko, land prices on The Sandbox and Decentraland fell roughly 90% and 88%, respectively, from their 2022-era peaks. That collapse is one piece of evidence that price had been driven by speculative expectation rather than actual usage demand.

What an NFT can and can't prove: the "authentic handbag" problem

What blockchain technology, NFTs included, reliably solves is proof of provenance: is this the real thing, or a fake? That a given parcel NFT is genuinely the one unforged token pointing to that coordinate is something you can verify cryptographically. That is fundamentally the same role played by a luxury brand's authentication process or serial number, confirming "this handbag is genuine, not counterfeit."

That is exactly where the core of the NFT critique lies. Proving a handbag is genuine and establishing that it is well made or worth its price are two entirely different questions. In the same way, proving a land NFT is the one unforgeable, genuine token is an entirely different question from whether that land is worth visiting or using. The Decentraland parcel above was, without question, genuine: nobody sold the buyer a forgery or a duplicate. But being genuine guaranteed nothing about whether visitors would show up or whether the asset's value would hold.

What's more, as covered earlier on this page, the actual "substance" a parcel NFT points to, a rendered, visitable 3D space, still depends on the operator's own server fleet (the catalyst nodes). All an NFT cryptographically guarantees is the chain of custody for the token itself; the continuity and quality of the experience the token points to remains entirely dependent on the same centralized server operation as before. Blockchain solved the narrow problem of ownership authenticity; it never answered the more important questions of whether the asset has value, or whether that value will last.

Realistic ways forward: staged decentralization and interoperability

• Progressive decentralization: the design pattern discussed on the DApps page, where a founding team makes decisions centrally at launch, then hands off authority in stages as a track record and community build up, works just as well as a cold-start remedy for the metaverse. Deliberately keep an actor who can supply initial momentum, then have that actor let go once the network has grown.
• Piggybacking on an existing community: rather than building a community from zero, offer a P2P space to an already-energetic community, a Discord server, say, after the fact, letting people bring their existing relationships with them.
• Drawing people in through asset interoperability: the cross-platform incompatibility of NFTs discussed above cuts both ways: if identities and items already established on another platform could be carried over as-is, a world could offer a "familiar" experience without waiting for content to be built from scratch. Achieving interoperability is as much a business move for solving cold start as it is a technical challenge.

Ultimately, a P2P or decentralized metaverse has to solve more than its sync algorithms and consistency models. The problem of how to gather the first hundred people and get them to stay, a question of community design entirely independent of the technology, has been the biggest wall most projects have run into.

Latency and cheat resistance: the technical walls of a P2P metaverse

AOI-based P2P distribution works well for syncing the wide background of a world, but it is risky to hand "outcome-critical" processing, such as hit detection between players or who picked up an item first, entirely over to P2P. Without a central authority, a system has little choice but to trust each node's self-reported position and state, which makes it hard to detect a malicious node cheating by sending itself favorable position data.

• Latency: P2P paths depend on hop count and the connection quality of individual peers, making it harder to guarantee the kind of consistent low latency a centralized server can. Mixing participants across continents makes fair simultaneity especially hard to design for.
• Cheat resistance: since a node cannot be trusted to verify its own claims about position or outcome, systems need majority voting across multiple nodes, or cryptographic proofs (such as commit-reveal schemes) to back up self-reported claims. This is fundamentally the same challenge as the Sybil-attack defenses covered in attacks & defenses and the ideas behind distributed consensus.
• Where things actually land: many implementations settle on a hybrid: lightweight P2P or edge synchronization for what things look like, with outcome-critical decisions routed through a trusted server or a multisig-like multi-signature check.

Centralized vs. P2P/decentralized: where things stand today

Pulling the threads above together, the trade-offs can be summarized as follows.

Try a P2P metaverse in your browser

Actually integrating the building blocks covered above (AOI, state synchronization, NAT traversal) into a working decentralized metaverse that doesn't depend on a central server is the goal of tik-choco-lab (GitHub), the project our site's team runs. Rather than stopping at explanation, we treat implementing and verifying these building blocks ourselves as the core of the activity.

At its core is mistlib (GitHub), the open-source P2P networking library that implements the techniques covered on this page. It has a Rust core with a transport layer combining WebRTC and WebSocket, supports NAT traversal, and includes a feature that optimizes spatial synchronization between nearby nodes based on the AOI (area of interest) concept discussed on this page. Beyond the browser, it can be used from Unity, Python, and JS, and also carries audio and video tracks. It is currently a test release.

A few browser apps built on mistlib are publicly available as examples. No installation is required; just open them in a browser to try P2P communication and spatial synchronization firsthand.

Ttik-choco-labgithub.comThe GitHub organization for the project building toward a decentralized metaverse. Related repositories are public here.Mmistlibgithub.com/tik-choco-labA P2P networking library with a Rust core. Source code and docs are public.TTC Spacetik-choco.github.ioA sample app where several people enter the same virtual space and experience avatar position sync over browser-based P2P communication.TTC Towntik-choco.github.ioAn app for creating and customizing the look of your avatar character.TTC Chattik-choco.github.ioA simple sample focused on the P2P text and voice communication layer.

All three are test builds under active development, published not as a performance or stability guarantee but as one concrete example of how the theory covered in this page behaves when it actually runs in a browser.

In short, most of what is called a "metaverse" today remains predominantly client-server, with P2P and decentralized approaches only partially solving problems such as item ownership so far. Research into next-generation architectures that combine P2P, edge, and cloud is ongoing, and the primary literature for this field is collected in depth on the references page.