[DAO:847ca96] Default REALM and SOLO Mode Implementation

by 0xb8782cf628357ce2751a4ea3007934048fbaa672

Linked Draft Proposal

Default REALM and SOLO Mode Implementation


Proposal with implementation details for how the default realm and solo mode will be implemented.


The social engagement of the platform is hindered by the complexity of navigating realms, coordinating locations, and connecting with friends. This has led to the suggestion of implementing a default realm to better connect users, while also offering the option for a solo mode to explore the world individually. As a result, this enhancement will simplify the process of connecting with others in Genesis City, while also providing individuals the option to enjoy scenes without being overwhelmed by a flood of users or chat messages.


Through several user interviews, a common sentiment expressed was that the metaverse tends to feel lonely and isolated, with users experiencing difficulties in meeting communities or friends. Furthermore, press releases from high-profile events have brought to attention some situations where they found themselves in realms with a low user base and reported low participation in their news when, in fact, they just ended up in a realm with a low user count. These situations highlight the impact of users being dispersed among separated realms by default. On the other hand, there are some experienced platform users that like the fact of having realms to jump to an empty server and be able to explore a scene by themselves without being flooded by avatars or chat messages and this could be easily managed from the UI without needing to jump to a different realm.

This fueled the idea of having a default realm, when users enter the platform, they will be directed to a default realm where all users are initially placed together. Once a user is in the default realm, they will have the flexibility to choose between either moving to a different realm or activating the solo mode to explore the world in isolation. These actions could be initiated at any time.


The upcoming section discusses the technical details of the necessary changes. Let’s start with an overview of the current design. Each Catalyst node includes a comms service that enables real-time messaging between players. However, this design has drawbacks:

  • Users can only interact with others using the same comms service instance. Even if two users are in the same scene, but connected to different comms services, they cannot see or interact with each other.
  • Scalability is limited because a Catalyst node runs all services on the same computer. These services compete for hardware resources, imposing a constraint on the number of open connections a comms service can handle. As a result, there is a maximum limit on the number of users a realm can effectively manage. If the limit is reached, new users cannot join until more resources are available.

The proposed solution involves each Catalyst node registering an external comms service to replace the internal one. By doing this, the hardware resources initially allocated to the internal comms service can be freed up and used by other services. This allows different node operators to share a comms service but it should be noted that the service won’t be composed of a single computer or process and it will be a set of scalable microservices, ensuring efficient resource utilization and accommodating the growing user load.

Setting up a custom comms service will be as straightforward as running a Catalyst bundle of services. This will empower anyone to easily spin up their own comms without complexity or technical hurdles.

Users will establish a connection to the default comms service when logging into Decentraland, similar to how they connect to a Matrix server for chat. The purpose of this comms service is to facilitate user interaction and handle their positions, regardless of which Catalyst node they use to download scenes.

Catalyst owners have the flexibility to configure their nodes to utilize either the default comms service or deploy their own using the provided bundle. This choice can be modified as needed, granting them control over the comms service employed. As a consequence, the existing mechanism for changing realms will remain intact, although the number of realms may decrease due to multiple nodes sharing the same comms service. Nevertheless, users will still enjoy the freedom to switch between realms, ensuring that no one is limited to the default realm.

In solo mode, users can disconnect from the comms service, disabling interactions with others. They won’t have access to voice chat or nearby chat channels. Solo mode allows users to explore the virtual world without engaging with others.


The new model is expected to have a significant impact on platform engagement and scalability.
The scalability of the system will improve as hardware resources can be allocated horizontally as needed to accommodate the growing user load. The flexibility given to Catalyst owners to choose between the default comms service and their own deployment empowers them to tailor their nodes to specific needs and preferences. Overall, these changes will enhance user experiences, promote social connections, provide greater control over interactions, and ensure that the default realm is not limiting.

Catalyst endpoints update:

By moving the comms service from the Catalyst node to a new service, the endpoints responsible for reporting islands and users will also be moved accordingly. Catalyst nodes will expose the URL of the comms service they are utilizing, which will, in turn, provide the same endpoints and functionalities as they currently do. This ensures continuity in the availability and accessibility of information. Below you can see a high-level description of the changes needed:
/about: comms object will change to expose the comms service registered by the Catalyst node
/explore/realms: will change its content, showing the list of Catalysts and their names but the comms information will be moved to the new service

The following endpoints will be exposed by the new comms service:


The Catalyst monitor will feature new representations for registered comms services, with the user count and comms date moved to these boxes.

Implementation Pathways

Create the Comms Service Bundle: Develop and package the necessary components for the realm, including:

  • A microservice for handling WebSocket connections.
  • A stats service for exposing comms metrics.
  • An archipelago service for calculating the islands.
  • Utilize NATS as the communication system between services.

Document the ADR and API Specification: outlining the design and rationale of the Comms service bundle in an architecture decision record and document/publish the API specifications.

Add a Feature Flag in the client to target the Default Realm:

  • Implement a feature flag mechanism in the client application to gradually roll out the Default Realm functionality.
  • Enable disaster recovery capabilities in case of failures to switch back to the previous model.

Create a new Catalyst owner bundle version:

  • Remove the existing comms service.
  • Add the ability to register an external comms through an environment variable.
  • Update the affected API endpoints and API specification
  • Implement solo mode in the client, allowing users to appear offline and disconnect from the rest of the users.

Run stress tests with users in a staging environment:

  • Evaluate functionality, performance, scalability, and identify potential bottlenecks.
  • Conduct tests with real users

Add the new comms service to the Catalyst monitor and update the comms information display.

Gradual rollout:

  • Enable the external comms service bundle in a subset of Catalysts nodes
  • Monitor the system closely during the rollout to identify and address any issues or performance concerns.
  • Collect feedback from users and iterate as necessary.

Make the stable comms bundle available for use:

  • Ensure the stable version of the comms bundle is accessible and documented for anyone to utilize. Send the communications to the different community channels.

Make the Default comms service available to be registered by any DAO-approved Catalyst node:

  • DAO-approved Catalyst nodes will have the option to use the provided infrastructure or run and use their own instance of the comms service bundle.


The implementation of the default realm and solo mode has a significant impact on the platform and its users. Here are the key outcomes:

  • Enhanced Social Engagement: By introducing a default realm where users are initially placed together, the platform promotes a stronger sense of community and facilitates easier connections among users.
  • Flexibility for Personal Exploration: The addition of the solo mode provides users with the freedom to explore the world by themselves.
  • Enhanced User Experience: With a default realm, users no longer have to navigate multiple realms to meet with friends, reducing confusion and complexity.
  • Maintains the platform’s decentralization by allowing any node operator to run their own comms service.
  • Simpler and More Accurate Hot-Scenes Calculation: Currently each Catalyst node must gather communication information from all nodes in the network and perform its own hot-scenes calculations, resulting in potential delays and slight variations in the data across realms. The default-realm model reduces the number of necessary requests and increases the accuracy and consistency of real-time data.
  • More scalable solution: current implementation hosts all services on a single computer, the Catalyst node, imposing a physical constraint on the number of open connections that a single comms service can handle. By adopting this approach, it becomes feasible to scale the communication service by adding additional computers to support more users under the same realm.

Vote on this proposal on the Decentraland DAO

View this proposal on Snapshot

1 Like

Default realm = centralization :slight_smile:

Voting NO on this piece of ****

Default doesn’t mean centralization, please read the full proposal and the white paper and then respectfully comment if you have a concern.

Please, use the word “server” next time.

With this idea you can only overload the “default” realm at some point.

Saw nothing about latency and regions on this proposal. You know what network latency is, and why there are few realms?

Newbs posting proposals?

Congratulations! Looks like someone has finished the python scripting course! :clap:

“Realm” doesn’t necessarily refer to just one server; it might be implemented with one or more servers. As stated in the proposal, it’s a bundle of services that can be scalable in case of overload, and it could also consist of multiple servers in different regions.

The main focus of this proposal should be on decoupling the Content service from the Comms service and facilitating people connecting with each other.

The code is open source, allowing anyone to start a new Comms service. Furthermore, anyone can run a Comms service without the need to host a Content service, utilizing the current Catalyst network. In case of failure, there will be multiple Comms services available, giving users the freedom to switch between them.

I see someone who is genuinely interested in the progress of the platform and not their own interest posting a proposal.
I see someone doing something to get people to connect with each other, which is the final goal, posting a proposal.

Ignorants & arrogants commenting on proposals?

1 Like

Hello, @mazafaka,

It is nice to see you involved on this discussion :slight_smile:. Initially, I shared the same concern as you, but I have since come to understand the importance of this change for Decentraland. I would like to add my 2 cents here, which may prove valuable to others as well. Here is my perspective on the proposal (please note that these opinions are my own):

  • One of Decentraland’s primary objectives is to attract new users and increase the Monthly Active Users (MAU) count. I believe we can all agree on the significance of this goal.
  • Within the DAO, we often discuss realms, servers, and nodes. However, for “regular” users who are not involved in the DAO or interested in the technical aspects of Decentraland’s infrastructure, we need to shift our perspective and consider them as newcomers. Building an open metaverse should not be limited to technical individuals. It appears that this might be the current situation, where users need to learn several things before fully enjoying Decentraland.
  • Given the above, should users really need to be concerned about realms, nodes, and servers when accessing play.decentraland.org? Or should we strive to make these technical details transparent, allowing users to focus solely on connecting with their friends in the metaverse? We should minimize cognitive complexity, such as questions like “where are you?” or “why can’t I see you?” Our aim is to facilitate connections among people: “Come to coordinates X, Y, and you will find all of us.”

I understand that this might seem like a significant change, but once I framed it in these terms, it became clear to me. We must prioritize the user experience to attract a larger user base.

Regarding the main concern about decentralization, it won’t be a single node going forward. All existing nodes will remain in place and continue to be essential for the proposed changes to function effectively. The following assumptions outline how this proposal maintains decentralization (again, this is my point of view):

  1. User data will continue to be replicated: By replicating user data across multiple nodes, we ensure redundancy and prevent single points of failure. This approach aligns with the decentralized nature of the network.
  2. User data will still be validated by all the nodes: In a decentralized system, it is crucial to have multiple nodes validate user data. This validation process helps achieve consensus and enhances the integrity of the data.
  3. Decentraland will still rely on all nodes for smooth operation: Each node plays a crucial role in processing and delivering content to users. The continued involvement of all nodes is vital for the system to function seamlessly, highlighting the decentralized nature of Decentraland.
  4. The change: User communications will no longer be reliant on the specific node they are connected to: With this proposed change, the responsibility of determining user interactions will no longer rest with individual nodes. Instead, the focus will shift towards content delivery (niceeee). Users will have the freedom to connect with others without being constrained by a specific node, enhancing the decentralized nature of the platform.

I strongly think that by shifting the responsibility of user interactions away from individual nodes, we further promote decentralization and empower users to connect with others freely within the metaverse. (Off-note: even when the nodes are not currently handling these user communications they act as a boundary, this is what I mean)

Thanks for reading!

1 Like

Default REALM and SOLO Mode Implementation

This proposal is now in status: PASSED.

Voting Results:

  • Yes 81% 7,758,097 VP (168 votes)
  • No 14% 1,437,464 VP (7 votes)
  • Abstain 5% 504,177 VP (7 votes)