# RSM Migration Guide
###### tags: `holochain` `RSM` `usability` `comms`

## Data structures

| Holochain-Redux | Holochain-RSM | Comment |
| --- | --- | --- |
| Headers contain the signature of the entry | Agents now sign the header and the (Header, Signature) pair is what gets distributed to the DHT | |
| There is only one Header structure, link and CRUD entry go in a dedicated entry type | There are multiple Headers structures, in which link and CRUD information are stored | |
| Entries and headers don't have a joint struct since they are not used together very often | An `Element` is defined as a `Header` alongside its `Entry` | The majority of HDK calls return `Elements` |

## Design

| Holochain-Redux | Holochain-RSM | Comment |
| --- | --- | --- |
| Link definitions are static, can only contain type and tag string | Link definitions are dynamic, can contain any arbitrary structure ||
| You can only validate an agent with their public key and nickname | There is a new JoinProof entry that you can pass when installing a DNA to prove that you have permissions to join it | |
| You have no way to retrieve all the headers committed by an agent | There will be a way to get all the activity for one agent (all their headers) | |

### CRUD

| Holochain-Redux | Holochain-RSM | Comment |
| --- | --- | --- |
| An entry can be only updated once | An entry can be updated multiple times | In the future, redirect callbacks and update back-propagation may be introduced |
| Update and delete receive an entry hash | Update and delete receive the hash of the header | This avoids update loops completely! |
| If you delete an entry, that entry is dead forever (tombstone set) | If any header of an entry is not deleted, the entry is still alive | |
| An agent can query their source chain by entry type names and give a start/end range | An agent can query their source chain by header types (system types or CRUD actions), app vs system entry types, give a start/end range, and include/exclude entry content | While a query can filter app entries from system entries, it can't currently filter on specific app entry types |

## Development

| Holochain-Redux | Holochain-RSM | Comment |
| --- | --- | --- |
|`send/receive` JsonString messages | `call_remote` specifies which function you want to call ||
| Capabilities are statically defined besides the zome function | Capabilities can be dynamically granted or revoked for any function to any agent | |
| Anchors are defined in a separate crate | Paths are a generalization of anchors pre-defined in core ||
| Validation callbacks are defined alongside the entries and links definitions | Validation callbacks are defined like any other zome function, with various degree of specificity | |
| JsonString is used for input/output parameters, and entry content. Structs used in all these cases must implement `DefaultJson` | SerializedBytes is used for input/output parameters, and entry content. Structs used in all these cases must implement `SerializedBytes`. There can only be one input and one output parameter for zome functions | |
| Instances are identified by an arbitrary string `instance_id` | Cells (instances) are identified by the pair [DNA_HASH, AGENT_PUB_KEY] ||
| All hashes and public keys are identified by the `Address` type | Each type of hash has a dedicated rust type (`EntryHash`, `HeaderHash`) | [holo_hash crate](https://github.com/holochain/holochain/tree/develop/crates/holo_hash) |
| The only callbacks available are `ìnit`, `validate_agent` and the validation callbacks | There will be a lot of useful "hooks": `app_install`, `app_uninstall`, `post_commit`... | |
| The instances running in the conductor are defined and maintained in the `conductor-config.toml` | The `conductor-config.toml` only contains initial environment settings, the cells are stored in a dynamic database ||
| Zome functions are not transactional: an initial commit can succeed and stay committed even if a following commit fails | All zome functions are transactional, the call fails and rolls back all state changes if anything fails inside that call | |
| If `get_entry` fails in a validation rule, the validation rule fails altogether | If a `get` fails or returns `None`, holochain will pause the validation and retry again in the future | You can specify yourself that a dependency is missing in order to validate this entry in the validation callback |

### HDK calls

| Holochain-Redux | Holochain-RSM | Comment |
| --- | --- | --- |
| `commit_entry` returns the entry hash | `create_entry` returns the header hash | |
| `get_entry` returns only the Entry | `get` returns the latest `Element` (`Header` + `Entry`) ||
| `hdk::AGENT_ADDRESS` gets you the initial public key of the agent | `agent_info()` gets you both the initial and the latest public key for the agent ||
| `hdk::DNA_ADDRESS` gets you the hash of the DNA | `zome_info` gets you the DNA name and hash, and the zome name ||
| Update and get entry update and get the latest version of the entry | Update and get entry deal with the entry corresponding to the given hash | |
| There are multiple variations of some zome calls: `get_entry`, `get_entry_result`, `get_entry_as_type`... | There are two variations of `get` (`get` and `get_details`) and `get_links` (`get_links` and `get_links_details`) | In RSM, the details calls retrieve all the information about the entry/link that is available in the DHT (for example, all its headers, CRUD status, etc.) while simple ones get you the latest header and the entry |