Infrastructure and Tooling
Last updated
Last updated
As we review the detailed vision of some platform services, it becomes clear that the amount of technology involved in achieving a realistic result for the development and integration of communities with the game is a significant effort and needs to be well-structured.
To navigate this path in the best possible way, we must emphasize some key points for development.
One of the aspects we've been concerned about from the project's inception is the modularity of our infrastructure. This step was crucial for us to progress, considering the numerous functionalities that are still being developed and are not currently present in the Cardano ecosystem, which we are now contributing to in an open-source manner.
Currently, our platform consists of over 22 high-performance microservices, with more than 50,000 lines of code across various repositories. This flexibility achieved through modularization allows the platform to grow adequately, taking advantage of community-developed technologies at the right time.
For non-technical individuals, modularization is crucial in dealing with technological innovation, especially in the current situation where specific parts of the ecosystem like Hydra and Mithril are yet to be developed, technologies that significantly impact the roadmap.
Modularization allows working on other parts of the platform until a certain point is ready to expand and receive the technologies arriving in the community. For the more technically inclined, we're referring to a hexagonal architecture, where one of the positive aspects is the ability to postpone some technical decisions, proving extremely relevant in the context of Cardano.
However, the advantages of this architecture go beyond, currently allowing us to take advantage of advancements in edge computing, better known as Serverless. The main advantage here is the potential for reducing fixed costs and operational scalability.
One of the key components of our ecosystem and responsible for the main interactions with our network is the user's wallet. Simultaneously, it's a significant entry barrier for experiencing a platform, considering that one of our objectives is to bring users who have never interacted with blockchain. It's crucial to reduce this learning impact right from the start.
However, we're aware that this is an educational project, understanding the importance of self-custody for these new users and the community. Hence, to enable a smooth experience, we need to create a way to assist these users initially.
At this precise moment, the platform becomes analogous to a centralized exchange, where we handle the assets of these accounts just starting to use blockchain. Over time and with the development of a mobile application, transitioning custody will be possible. Native web3 users will have custody at all times.
As you can see, wallet abstraction is a crucial element to enable this transition and must be carefully planned to integrate correctly with our functionalities. If successful, we understand that there is demand from other projects to use this tool to support their games. Within our capacity, we'll look at the open-source solutions catering to the gaming segment of our community. Initially, we'll start with a more centralized solution and later something more aligned with the ecosystem, which is still being discussed through CIP-38.
Aligning to enable quick onboarding is crucial, and a mobile application gives us many opportunities that will simplify the lives of platform users. Thinking about the experience, we'd like the visitor's first contact to lead directly to the game, after some progress, a temporary identifier for that account would be generated.
The mobile application aims to serve as a facilitator for platform authentication, acting as a mini-hub for the player, and providing access to notifications and other information. The session initiated by the visitor can be synchronized through a camera positioning on a QR code, as we know today on Discord, or by entering a specific numerical token for the session.
With the application configured, this user has easier access to synchronize their other accounts and set up more advanced security options on our platform. Our ultimate goal is for this app to become the custodian of these users' keys in the future, allowing transaction signing generated via the platform with just one touch.
This initiative is also being discussed with other projects, and our goal is for it to become an open-source project.
We understand that in the path of innovation and development of a project like this, moving towards a 100% on-chain approach due to technological pedantry can mean constant challenges in technology and usability. At the same time, in a hybrid scenario, we need maximum transparency, enabling constant monitoring by the community.
To achieve this, we're preparing an event logging system that will provide real-time logs for the community to follow and develop their metrics and statistics.