Catalysts receive entity deployments that will be stored and distributed among them. Some validations are executed for each entity deployment, depending on the context and entity type.
Most validations need information about the Catalyst content state and external dependencies like The Graph, which makes them very hard to predict, i.e. we can't ensure an entity deployment will be correct without validating it in a given context.
On the other hand, we have some stateless validations that may be useful to run before actually doing a deployment, like metadata schema and hashes validations.
Adding an entity type to a Catalyst requires a tedious effort which envolves defining schemas, relations and validations in different repositories.
For instance, adding a validation to the Catalyst can be overwhelming for a developer from outside the Platform team.
Validations will be moved to a library that will not depend on any other than definitions like schemas and types.
The library will require a set of functions, defined in an interface, to perform validations of the entities. Such functions will be needed to interact with the outside world i.e. The Graph.
Needless to say, the content servers and potentially other tools (like the builder or the cli) will provide these functions to run validations anywhere.
All validations will know this context and will decide if must do something different, but no validation list per context will exist, i.e. all validations will run on each deployment.
Also, the concept of "entity version" will be removed, instead, timestamps will be used to perform protocol change validations. That is so, to avoid duplicated/deprecation logic. An example of this timestamp mechanism is defined in (ADR-45)1.
The following (named) validations MUST be executed in every entity:
PROFILE entities will have following validations:
SCENE entities will have following validations:
STORE entities will have following validations:
WEARABLE entities will have following validations:
EMOTE entities will have following validations:
OUTFITS entities will have following validations:
Accepted.
Will create a starting point to track entities changes.
An ADR will be created to change any of these statements or add a new entity type, describing which validations will run.
Adding validations will be easier any developer.
Catalysts will need to provide external calls that may introduce some complexity.