Report on Recent Changes in the New Foundation Client and Their Impact

Implementation Journal
1

Overview

This report outlines the recent release by the Decentraland Foundation of its new client, which introduced significant changes affecting interoperability between the Foundation’s new client and old client and alternative clients funded by the DAO. Key aspects of the rollout lacked communication and pre-release documentation, impacting the coordination across clients. We detail the impact, specific issues identified, and propose areas for improvement to foster a more transparent, inclusive approach in future developments.

1. Impact Analysis

1.1. Cross-Client Interoperability

With the launch of the new Decentraland client, compatibility between users on the Foundation’s client and those on older and DAO alternative clients was disrupted. This change, which directly impacts the ability of users across different clients to interact, was not publicly disclosed ahead of time nor communicated in a format that allowed for peer review or community input. This has led to a fragmented user experience, where users on different clients cannot engage with one another as expected in Decentraland’s open environment.

1.2. Communication and Documentation

Documentation regarding the protocol changes critical to client interoperability was notably delayed. An Architecture Decision Record (ADR) was published in PR-draft form only a day before the client launch, lacking key details about protocol updates related to movement synchronization. The lack of advance notice and complete documentation impacted the ability of DAO-funded alternatives client developers to prepare or adapt.

1.3 Additional Issues noted

Two other changes introduced in the new client have implications for DAO-deployed content and old&alternative clients:

  • Terrain Generation on Empty Parcels: The new client generates terrain height maps on empty parcels, a feature undocumented for cross-client adaptation. This results in misaligned visuals, where users on the older or alternative clients may see users floating or submerged, depending on the client’s terrain rendering.
  • Road Replacement: Some roads, as deployed scenes by the DAO, were replaced for optimization and aesthetics. While the motivation may align with broader improvements, this action disregards DAO property rights over such scenes.

2. Areas for Improvement

2.1. Transparent Change Management

Introducing significant interoperability changes without open communication limits the ability of DAO-supported and alternative client developers to adapt and ensure continuity in user experience. A structured, transparent change management process that includes early-stage information sharing and community consultation could help mitigate these disruptions. A clear pre-announcement timeline should be implemented for changes that affect core client compatibility.

2.2. Complete and Timely Documentation before rolling out

Ensuring complete, accurate documentation well ahead of a rollout is essential for coordination across the ecosystem. Providing comprehensive documentation before the release of significant features would align with best practices, supporting both the Foundation’s and DAO’s commitment to an open, community-driven platform.

Request for Consideration

To strengthen collaboration and interoperability across Decentraland clients, we kindly request the Foundation to consider:

  • Establishing and adhering to a change management framework that supports early notification, peer review, and communication of changes that may impact the wider ecosystem.
  • Committing to providing full documentation, finalized and accessible to developers, before major releases.
  • Recognizing the DAO’s stewardship over deployed scenes and adjusting processes to respect DAO-owned properties, such as roads, in future optimizations.

We appreciate the Foundation’s ongoing efforts to enhance Decentraland and look forward to working together towards solutions that serve all participants in the Decentraland ecosystem.

Relevant repos:

7 Likes
2

This is a long-standing issue. One which community developers and scene builders have repeatedly voiced through various channels, AMAs, and town halls. It is discouraging to see that as we push some of the biggest updates in DCL history, developers outside the foundation remain in the dark. This is not reflective of the messaging highlighting transparency and creator/community focused innovation that Decentraland foundation promotes publicly. As a social media content creator, it is disappointing to see that the tools we have repeatedly voiced would facilitate our productivity have not been implemented, some that were available disappeared with the new client, and pushed back, in favor of features that are nice, but the creators and builders never asked for.
I am pleased with not having green walls anymore, but is also important to not live in a bubble of toxic positivity. In the “year of the creator” the lifeblood of our community continues to feel neglected. I hope the new DAO can change this and give builders an environment, tools and collaboration that are reflective of a platform built, owned and managed by its community.

7 Likes
3

Thank you for the thorough report. I appreciate the external audit and the constructive conversation it fosters.

During the development of the new client, we identified several limitations in the previous architecture and protocol. In response, we chose to take a different approach, always aiming to enhance Decentraland’s capabilities, performance, and immersion. The major changes focus on the communication system and environmental rendering.

The previous design, which relied on islands in Genesis City, constrained our ability to support user streaming into scenes and did not scale effectively for scene state synchronization. We’ve proposed a new model featuring a dedicated networking room for each active scene, complemented by islands for nearby communications. Additionally, we found that the messages sent through the cable were too large and lacked essential data for accurate player position synchronization. As a result, we’ve reworked the format of several messages.

These changes to the communication channel were deployed in an alternative realm to prevent disruption to existing clients, which unfortunately resulted in breaking compatibility with previous clients. Updating other clients with this new architecture is time-consuming, and we are still refining the proposed solution. With real users now interacting with the system, we can gather data to assess performance and continue making improvements.

Regarding environmental rendering, we have replaced the default empty parcels with a deterministic algorithm for terrain generation. Using a known seed, all clients can now generate a height map for terrain elevation and place assets (trees, bushes, rocks, etc.), allowing alternative clients to recreate the same terrain. While we currently do not have a finalized ADR for this, our team is available to guide you through the code to review the implementation details.

For roads, we took a similar approach as with the empty parcels, rendering them directly from Unity instead of running an SDK scene for each one. This allows us to optimize performance since roads are simple and repetitive scenes with unusual proportions. We recognize that the roads belong to the DAO, and the Foundation currently has operational permissions to deploy content there. We can render an SDK7 scene that is deployed on road land; we just need to identify which one or establish a standard way to indicate whether a scene should be rendered by Unity as a standard road/empty parcel or as an SDK7 scene.

We acknowledge that the ADRs are not ready; one initial draft is available here, with another coming in the next couple of weeks. We are committed to documenting how the new client works and engaging in productive discussions to finalize the ADR. Now that we have a working implementation, it’s the right time to evaluate it openly. Conversations during development were challenging; we needed to test and experiment with various approaches to reach this point, and as I mentioned earlier, more work is still needed before finalizing the ADR.

We still face challenges in the communication architecture, particularly with the robustness of scene state synchronization for multiplayer environments. We’re also looking at how to enable players to stream content (like screen sharing and voice) while allowing scene owners/operators to moderate these capabilities in real-time.

Let’s engage in discussions on how to move forward. Our technical team is ready to answer any questions about the implementation. As for timing, please trust that we are doing our best to prepare the ADRs while also gearing up for the Music Festival.

1 Like
4

That’s great that the team can help guide through the code, but 1-on-1 calls are not how the Decentraland protocol will prosper. Couldn’t a very very rough draft ADR be made instead of spending time individually guiding teams that might need that implementation details?

Discussions are supposed to be done BEFORE the implementation is implemented, now it’s too late to discuss it. About the challenging conversations, I don’t think there was any calls to get input from the community about it.

That ADR is still as an unmerged PR, requiring people to go dig into PRs to find it, if only we had a Draft tag for merged draft ADRs… Oh wait, we do. Could you merge that PR so it appear as a draft in adr.decentraland.org?

Screenshot_2024-10-30_18-05-27
Screenshot_2024-10-30_18-05-27664×548 22.6 KB

ADR documents specification & process

ADR Work Flow

Shepherding an ADR

Before you begin writing a formal ADR, you should vet your idea. Ask the Decentraland community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on the ADR discussions to do this.

Yes, let’s do it, we are ready, only waiting for the Foundation to do its part, we cannot engage in discussions we are not aware are happening.

1 Like
5

As a user of Decentraland primarily here for the Social Experience, this release is a catastrophe.

The page on Places no longer shows the live performances which are taking place LIVE.

The friend’s list is not there, it is impossible to see who is online that way.

The use of the chat box is a horrible experience, there are far too many messages getting lost.

And a number of scenes are simply no longer starting.

There is an inordinate focus on game playing experience. Which is bad enough in as of itself, as DCL will simply not outcompete other web3 game platforms.

BUT IT IS EVEN THE CASE THAT THE NEW MINI-GAMES ARE ACTUALLY STILL RIDDLED WITH BUGS

1 Like
6

Most software company whose new product release faces unexpected problems choose to rollback to a version which will not scare the public.

At this point, with the track record of the Foundation team’s resolution of issues (versus regressions introduced in the process), and with the amount of time left before the festival, the truly safest option is to rollback to the 1.0 environment.

The 1.0 has its issues, but at least the public is already aware of them, is already used to them (there is a love-hate relationship with Rave Mode), and is still hopeful that their resolution will eventually arrive.
Some of these issues are actually quite easy to resolve, with a very good chance to be done on time for the festival (I will seek to elaborate on that shortly).

If the 2.0 is still a half-finished product when used to host the upcoming Music Festival, IT WILL BE A DISASTER.
It isn’t even clear that it will actually be able to handle the large number of users that should be expected from such a high-profile event.
If these users go back to their friends saying “DCL is even more broken than before, lolz”…

then the price of MANA will just tank.

1 Like
7

Work on the 2.0 should proceed, of course. The new experience can even continue to exist, in its current release, having been mutated back to a “permanently running” Alpha testing session.

But not even moving to a Beta phase before moving on to production, is a decision which the DAO should purely and simply have been given a chance to Veto.

1 Like
9

On macOS with M-series chips, RAM is unified with VRAM, meaning the GPU uses RAM as VRAM.
For users with 8GB RAM - the largest group - it would make sense to reduce the default Scene Distance from 20 to 10 and Environment Distance from 1000 to 100.

I suspect that objects like trees :deciduous_tree: consume significant VRAM (which, on these systems, is the same as RAM), leaving less memory available for essential functions like loading backpack wearables or builds sometimes