Default REALM and SOLO Mode Implementation

by 0xb8782cf628357ce2751a4ea3007934048fbaa672

Linked Draft Proposal

Default REALM and SOLO Mode Implementation

Summary

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

Abstract

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.

Motivation

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.

Specification

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.

Impacts

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:

/comms/islands /comms/islands/{islandId} /comms/peers /explore/hot-scenes

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.

Conclusion

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.

This proposal is summarized due to technical limitations. To view it complete and vote on it, visit the DCL DAO Governance dApp