---
# System prepended metadata

title: 'Emphasizing Innovation and Efficiency: Feedback on the Proposed DMs Feature PR'

---

# Emphasizing Innovation and Efficiency: Feedback on the Proposed DMs Feature PR

gm Push team 👋

We sincerely appreciate your hard work on the Direct Messages (DMs) feature PR that has been recently submitted for review. This detailed piece of code underlines the consistent effort and commitment demonstrated by the Push Protocol team. We truly understand that the team has poured countless hours into the conception, coding, and debugging of the proposed feature. It's this dedication that brings about the continuous evolution of our software ecosystem.

However, after a comprehensive review of the changes, it is with regret that we must turn down this Pull Request at the current time. There are several reasons behind this decision which I would like to articulate for the better understanding of everyone involved.

Firstly, the proposed feature seems to overlook the pre-existing feature architecture. As we all are aware, we have the XMTP already implemented and running smoothly and fastly in our codebase. This protocol handles the Direct Messages functionality efficiently, providing our users with a streamlined experience. The proposed PR, unfortunately, introduces an additional DMs feature, which conflicts with XMTP.

The presence of two separate DMs inboxes might create a disoriented user experience, which is certainly not our objective. **User Experience (UX)** is at the heart of everything we do, and we strive to maintain an intuitive, seamless user interface. The introduction of a second DMs system could complicate the interface, increasing cognitive load on the users and potentially leading to user dissatisfaction. We should aim to avoid such redundancies that might result in negative user feedback.

Secondly, the size of the PR is considerably large, consisting of **54k lines of code changes**. Such a substantial PR can be challenging to review effectively and poses risks concerning code stability and system performance. Also, given that this PR consists of half the lines of Lenster's entire codebase, integrating it would be a significant undertaking that may introduce unforeseen bugs and compatibility issues.

Indeed, maintaining two separate inboxes for Direct Messages in the long term is another key concern. Two inboxes would require double the resources, time, and effort in terms of maintenance, updates, bug fixes, and troubleshooting. Each time a change or update is made, it would need to be tested and deployed in five environments, doubling the work for our development team and increasing the chance of inconsistencies or errors. Furthermore, this could lead to a divergent codebase, where similar functionalities are developed and maintained differently. Over time, such divergence could exacerbate the complexity of the codebase, making it increasingly difficult to manage and understand. This wouldn't be in line with our goal of promoting simplicity and clarity in our codebase. Hence, it is important to maintain a streamlined user experience and codebase, not just for the present moment, but also with a vision towards the future.

As a general rule of thumb, PRs should be kept as concise as possible, addressing specific tasks or issues. This ensures that they can be effectively reviewed and tested. It allows for more predictable deployments and a lower risk of unexpected bugs or conflicts. While we understand the effort and commitment that goes into such a large PR, it is essential to maintain a level of simplicity and clarity in our codebase.

Moreover, as we continuously strive to improve Lenster, we eagerly seek fresh, innovative ideas that can truly make a difference and enhance our platform, something like **Lenster Spaces**. We are committed to pioneering new features, improving existing ones, and discovering innovative ways to delight our users and exceed their expectations.

In conclusion, while we deeply appreciate the Push Protocol team's effort and dedication in developing this feature, the current PR cannot be accepted due to the reasons mentioned above. We encourage the team to take these points into consideration for future developments and perhaps look into how these efforts can enhance our existing XMTP system, providing additional value to our users.

Again, our heartfelt thanks to the Push Protocol team for their valuable work, and we look forward to future collaborations that align with our architectural principles and UX philosophy.

Thanks

Team Lenster.