A Catalyst is a server that runs different services. These services currently work as the backbone for Decentraland.
If you just want to run a Catalyst server, please check the Catalyst Owner repository. This repository is mostly used for developing.
The architecture of the server is as follows:
-
Comms: The Communication Service, also known as Lighthouse, is in charge of orchestrating the P2P networks between users connected to Decentraland. It needs to determine which are the candidates for a P2P connection and do the WebRTC signaling to establish the connection. Most of this logic is done through 2 external components: the PeerJS Server (connects WebRTC peers) and Archipelago (receives users positions and groups them in islands)
-
Lambdas: This service provides a set of utilities required by the Catalyst Server Clients/Consumers in order to retrieve or validate data. Some of the validations run in these functions are ownership related and for that it uses The Graph to query the blockchain.
-
Content Server: The Content Server currently stores many of the Entities used in Decentraland. For example scenes, wearables and profiles. Content Servers will automatically sync with each other, as long as they were all approved by the DAO. If you set up a local content server, it will receive all updates by those other DAO Catalysts. However, new deployments that happen on your local server will not be sent to other servers.
-
Nginx is the reverse proxy used to route traffic to the Catalysts Services.
The Catalyst Client library can be used to interact with the Catalyst servers. You can both fetch data, or deploy new entities to the server you specify.
Check full architecture here
This Server implements the v1 of the API Specification detailed here
For monitoring see the following doc
yarn build
yarn test
Please read the full text so that you can understand what actions will and will not be tolerated.
Read our contributing guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes.
- Create a tag release in Git
- It will trigger the CI job which publishes a new docker image version under
@latesttag