# Entities and the EntitiyResolver

Entities are hashed objects whose id is their hash. They comply with the Entity interface.

export interface Entity<T = any> {
  hash: string;
  object: T;
  remote: string;
}

The object property is a canonical JSON object (stored as a JS object) whose properties are ordered alphabetically and which is then serialized using cbor (opens new window).

Once serialized, the hash of the bytes is obtained using a hashing algorithm and the hash property is set as the CID of the hash. Any valid CID is a valid Entity hash.

Entities are used by clients to store the head of each perspective, as a Commit object.

A commit has the hash of the parent commit and that of the actual data object, both of type Entity. This means that the head commit of a perspective has, encoded on its hash, an immutable summary of the entire history of the perspective (all its commits) and all the associated data objects of each commit.

In _Prtcl, a global EntityResolver class is created to resolve any entity required by any function in the application. This reduces the complexity when exploring perspectives but forces us to manually prepare the entities that need to be persisted together each Client.

# Entity availability strategy

Everytime a new entity is created (say a new commit is computed), this entity is included in the EntityResolver using the putEntity() function.

Putting an entity on the EntityResovler will not persisted it any EntityRemote. It will simply be stored in case another portion of the app needs it.

Entities are persisted into an EntityRemote, only when an EveesMutation (with new perspectives or updates) is sent to a ClientRemote. In that case, the Entities associated to the EveesMutation are identified and persisted in the EntityRemote associated with that EveesRemote.