HackMDAragon UI Deprecation Proposal
Summary
Aragon UI, the Lido DAO's web interface, was originally designed as an accessible tool to discern the protocol's state. Over its operational lifespan, the complex nature of its development environment and maintenance have led us to reassess its value proposition. This proposal outlines these issues with an aim to deprecate Aragon UI in favor of a more simple and efficient solution.
Disclaimer. It's essential to clarify that our proposal pertains solely to the Aragon UI, the web dashboard interface including Aragon Client, standard Aragon apps and Lido Aragon apps. This proposal does not encompass or impact the Aragon contracts currently embedded within our protocol. Those remain integral to the protocol architecture and are not part of this re-evaluation.
About Aragon UI
Aragon UI has been our immediate touchpoint for decoding the state of the protocol. Previously, it was also used as a DAO voting interface. Since then, we have developed our custom DAO Voting UI which offer a much smoother user experience, rendering the Aragon Voting app inferior and redundant. Additionally, in its earlier versions, Aragon UI also incorporated state-changing levers but these were used only occasionally for testnet purposes. For mainnet operations, state changes are handled through omnibus voting scripts, eliminating the need for these management functions in the Aragon UI.
Issues with Aragon UI
1. Intricate Development Environment Setup
- Deploying Protocol: The process demands an elaborate deployment of the entire protocol to a local node.
- Uploading Frontend Assets: This involves building and subsequently uploading frontend assets to a local IPFS node.
- Configuring Aragon Client: The culmination of this process requires configuring the Aragon client to recognize local deployment parameters.
- Frequent Breakdowns: The environment setup is fragile, and it's commonplace for components to malfunction, leading to an unreliable development experience.
- Protracted Development Cycle: Even after successful setup, the development process is far from efficient. Refresh times for the Aragon client are slow, resulting in significant delays in reflecting changes.
2. Manual IPFS Deployment
- Manual Upload and Pinning: Initially, any update mandates a manual upload of the updated frontend to IPFS, followed by pinning via third-party providers like Infura.
- Hash Propagation Delays: Once uploaded, the IPFS hash can take up to 24 hours to propagate. Our IPFS node then has to detect and pin this hash, a mechanism fraught with inconsistencies.
- Reliability Issues: We've encountered numerous issues during this process, making it unreliable and cumbersome.
3. Update Overhead
- Even for small tweaks, like text modifications, the entire deployment journey from IPFS upload to acquiring DAO approval through voting is necessary. This exhaustive method for minor adjustments is markedly inefficient.
4. Bugs and Usability Concerns
- Aragon UI, by virtue of its design, is susceptible to bugs which hamper the user experience. The inherent complexity of its maintenance escalates the resolution time for these issues.
5. External Software Dependency
- Employing Aragon Client, an external software, introduces potential risks. This includes unexpected changes or vulnerabilities that might endanger the DAO operations.
Proposed Solution
Recognizing these challenges, our recommendation is to deprecate Aragon UI in favor of a more developer-friendly and efficient tool. The action plan includes:
- Design an Alternative UI Solution: The chosen solution should offer a less complex maintenance workflow, decoupled from the DAO voting, and integrate effortlessly within our technical infrastructure.
- Identify and list the essential functionalities for the new interface.
- Establish the delivery timeline for the new interface.
- Allocate resources for the development, testing and documentation.
- Transfer ownership to Governance: Organize sessions to introduce stakeholders, primarily Governance team, to the new UI, emphasizing its advantages and features, and transfer ownership to the Governance team.
- Feedback Mechanism: Establish a real-time feedback loop during the transition to swiftly address any emerging issues.
- Final Decommission: After rigorous validation, deprecate Aragon UI, meaning shut down Aragon Client and move Aragon apps (Lido, LidoOracle, StakingRouter frontends) codebase to a separate repository and archive it.
Conclusion
Given the multiple challenges associated with Aragon UI, from its development setup to its deployment process, transitioning to a more efficient solution is imperative. Such a tool, ensuring a simple update mechanism and providing a smoother developer experience, will unequivocally improve protocol transparency and user experience for Lido contributors, stakers and partners. The issues tethered to Aragon UI, juxtaposed with the promise of a modern, streamlined solution, render this transition both strategic and timely.
