by 0xb8782cf628357ce2751a4ea3007934048fbaa672
Linked Pre-Proposal
Should Decentraland have a default realm and solo mode?
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 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.
Regarding Catalyst endpoints, moving the comms service also involves relocating the endpoints responsible for reporting islands and users. Catalyst nodes will expose the URL of the comms service they use, providing the same functionality. The following changes are needed:
- /about: The comms object will expose the registered comms service of the Catalyst node.
- /explore/realms: The content will change to show the list of Catalysts and their names, but the comms information will be moved to the new service.
The new comms service will expose the following endpoints:
- /comms/islands
- /comms/islands/{islandId}
- /comms/peers
- /explore/hot-scenes
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.
