From d7270edb71aa26201e0b6707605163cdb29892cb Mon Sep 17 00:00:00 2001 From: Berend Sliedrecht <61358536+blu3beri@users.noreply.github.com> Date: Wed, 5 Apr 2023 13:16:07 +0200 Subject: [PATCH] docs: spellling and reference to order of migration (#111) Signed-off-by: blu3beri --- guides/updating/update-indy-sdk-to-askar.md | 82 ++++++--------------- guides/updating/versions/0.3-to-0.4.md | 52 ++++++------- 2 files changed, 49 insertions(+), 85 deletions(-) diff --git a/guides/updating/update-indy-sdk-to-askar.md b/guides/updating/update-indy-sdk-to-askar.md index 19cf1254..c0b161fe 100644 --- a/guides/updating/update-indy-sdk-to-askar.md +++ b/guides/updating/update-indy-sdk-to-askar.md @@ -1,14 +1,10 @@ # Migrating from an Indy SDK Wallet to Aries Askar -This documentation explains the process of migrating your Indy-sdk wallet to -[Aries Askar](https://github.com/hyperledger/aries-askar). +This documentation explains the process of migrating your Indy-sdk wallet to [Aries Askar](https://github.com/hyperledger/aries-askar). :::danger -While the migration script techinically works on node.js, it is strongly -advised not to use it, yet. The mean reason for this is that the Credential -Definition migration is not done yet. When a credential definition is detected -it will revert the migration process and no harm is done. +While the migration script techinically works on node.js, it is strongly advised not to use it, yet. The mean reason for this is that the Credential Definition migration is not done yet. When a credential definition is detected it will revert the migration process and no harm is done. ::: @@ -20,49 +16,37 @@ Postgres is not supported, yet. :::caution -The migration script is supported for 0.4.x (or moving from 0.3.x to 0.4.x). -Please refer to [Migrating from AFJ 0.3.x to 0.4.x](./versions/0.3-to-0.4.md) -to get to 0.4.x. +The migration script is supported to run on 0.3.x before migrating from 0.3.x to 0.4.x. Please refer to [Migrating from AFJ 0.3.x to 0.4.x](./versions/0.3-to-0.4.md) to get to 0.4.x afterwards. + +It is important to note that this script must be ran before you update from 0.3.x to 0.4.x. ::: ## What does the migration do internally? -The migration script does the following to make sure everything is migrated -properly, and if anything goes wrong, it will revert back to a working state. +The migration script does the following to make sure everything is migrated properly, and if anything goes wrong, it will revert back to a working state. ### Create a backup -Because undefined behaviour might occur, we create a backup in the new `tmp` -directory from Aries Framework JavaScript. if some error occurs, it will be -reverted back to the backed-up state and if no error occurs, it will delete the -backup from the temporary directory. +Because undefined behaviour might occur, we create a backup in the new `tmp` directory from Aries Framework JavaScript. if some error occurs, it will be reverted back to the backed-up state and if no error occurs, it will delete the backup from the temporary directory. ### Migrate the database to an Aries Askar structure -The Indy-sdk and Aries Askar have different database structures. So first of -all we need to change some table names, decrypt all the items with the old Indy -keys, encrypt the items with the new Aries Askar keys and store them inside the -new structure. +The Indy-sdk and Aries Askar have different database structures. So first of all we need to change some table names, decrypt all the items with the old Indy keys, encrypt the items with the new Aries Askar keys and store them inside the new structure. ### Try to open the wallet in the new Aries Askar structure -When the wallet is correctly transformed, the wallet will be attempted to be -openend. +When the wallet is correctly transformed, the wallet will be attempted to be openend. ### Update the keys -Aries Askar has a specific way to store keys and every key, defined by the -category of `Indy::Key` will be migrated. +Aries Askar has a specific way to store keys and every key, defined by the category of `Indy::Key` will be migrated. ### Update the Dids :::caution -This update script does not transform did records. This is fine for something -like `did:peer`, but will cause issues with `indy` and `sov` dids. For more -information, please check out the [Migrating from AFJ 0.3.x to -0.4.x](./versions/0.3-to-0.4.md#removal-of-publicdidseed-and-publicdid) +This update script does not transform did records. This is fine for something like `did:peer`, but will cause issues with `indy` and `sov` dids. For more information, please check out the [Migrating from AFJ 0.3.x to 0.4.x](./versions/0.3-to-0.4.md#removal-of-publicdidseed-and-publicdid) ::: @@ -70,51 +54,35 @@ information, please check out the [Migrating from AFJ 0.3.x to :::danger -Updating of credential definitions is not yet supported. This is why it is -strongly advised not to run this script in a node.js environment. +Updating of credential definitions is not yet supported. This is why it is strongly advised not to run this script in a node.js environment. ::: ### Update the link secret(s) (master secret) -The link sercets, identified by the category `Indy::MasterSecret`, are updated -next. They are stored inside a new `AnonCredsLinkSecretRecord`. +The link sercets, identified by the category `Indy::MasterSecret`, are updated next. They are stored inside a new `AnonCredsLinkSecretRecord`. :::caution -Since we have to set a default link secret, some additional logic is added to -detect this. You can either supply a `defaultLinkSercetId` as a constructor -parameter or it will be based on your `walletId`. +Since we have to set a default link secret, some additional logic is added to detect this. You can either supply a `defaultLinkSercetId` as a constructor parameter or it will be based on your `walletId`. -If there is no Indy record with the `defaultLinkSecretId` or the `walletId`, an -error will be thrown and the migration will be restored. +If there is no Indy record with the `defaultLinkSecretId` or the `walletId`, an error will be thrown and the migration will be restored. ::: ### Update the credentials -The credentials, identified by the category `Indy::Credential` are updated -last. They are stored in the new `AnonCredsCredentialRecord` as a one-to-one -copy. This means that they now support more tags and will make querying a lot -easier. +The credentials, identified by the category `Indy::Credential` are updated last. They are stored in the new `AnonCredsCredentialRecord` as a one-to-one copy. This means that they now support more tags and will make querying a lot easier. ### All the other records -All the other records will be transferred without any updates as they are not -Indy specific. +All the other records will be transferred without any updates as they are not Indy specific. ## How to update Updating does not require a lot of code, but must be done with caution. -It is very important to note that the migration script only has to be run once. -If it runs for a second time, it will error saying that the database is already -migrated. Also, when the migration is finished, it is common practise to store -this state in your persistent app storage. This script does not provide a way -to detect if an update has happened, so storing this value will prevent the -script from running every time. For more information regarding this topic, -please check out [Update -Assistant](./update-assistant.md#storing-the-agent-storage-version-outside-of-the-agent-storage). +It is very important to note that the migration script only has to be run once. If it runs for a second time, it will error saying that the database is already migrated. Also, when the migration is finished, it is common practise to store this state in your persistent app storage. This script does not provide a way to detect if an update has happened, so storing this value will prevent the script from running every time. For more information regarding this topic, please check out [Update Assistant](./update-assistant.md#storing-the-agent-storage-version-outside-of-the-agent-storage). ### add the required dependencies: @@ -122,13 +90,11 @@ Assistant](./update-assistant.md#storing-the-agent-storage-version-outside-of-th yarn add @hyperledger/aries-askar-react-native @aries-framework/indy-sdk-to-askar-migration react-native-fs ``` -Below is the minimal code required for the migration to work. It is recommended -to turn the logger on as it gives a lot of information regarding the migration. +Below is the minimal code required for the migration to work. It is recommended to turn the logger on as it gives a lot of information regarding the migration. :::caution -The agent is not allowed to be initialized to run this script. This makes sure -nothing else happens during the migration. +The agent is not allowed to be initialized to run this script. This makes sure nothing else happens during the migration. ::: @@ -159,9 +125,7 @@ await updater.update() On android, the database is commonly located under the `ExternalDirectoryPath`. -If you did not follow the default indy-sdk for React Native setup, your path -might differ. Check out [step 5 of the Android setup for Indy SDK React Native](https://github.com/hyperledger/indy-sdk-react-native#5-load-indy-library) -for the default behaviour. +If you did not follow the default indy-sdk for React Native setup, your path might differ. Check out [step 5 of the Android setup for Indy SDK React Native](https://github.com/hyperledger/indy-sdk-react-native#5-load-indy-library) for the default behaviour. ```typescript import fs from 'react-native-fs' @@ -179,9 +143,7 @@ const dbPath = `${base}/${indyClient}/${wallet}/${walletId}/${file}` On iOS, the database is commonly located under the `DocumentDirectoryPath`. -For iOS this can only change if your phone does not have the `HOME` environment -variable set. This is not usual behaviour, and if `HOME` is not set, the `base` -in the code section below will be `/home/indy/Documents`. +For iOS this can only change if your phone does not have the `HOME` environment variable set. This is not usual behaviour, and if `HOME` is not set, the `base` in the code section below will be `/home/indy/Documents`. ```typescript import fs from 'react-native-fs' diff --git a/guides/updating/versions/0.3-to-0.4.md b/guides/updating/versions/0.3-to-0.4.md index e0927a2c..7ec1e7d8 100644 --- a/guides/updating/versions/0.3-to-0.4.md +++ b/guides/updating/versions/0.3-to-0.4.md @@ -2,7 +2,7 @@ This document describes everything you need to know for updating AFJ 0.3.x to 0.4.x. If you're not aware of how updating in AFJ works make sure to first read the guide on [Updating AFJ](/guides/updating/index.md). -First of all, update you dependencies to the 0.4.x versions. This will also update the needed peer depedencnies. **Extension packages are not updated with this command**. You need to update these manually, and make sure they're up to date with the latest version of AFJ. +First of all, update you dependencies to the 0.4.x versions. This will also update the needed peer dependencies. **Extension packages are not updated with this command**. You need to update these manually, and make sure they're up to date with the latest version of AFJ. Aries Framework JavaScript 0.4.0 is a major release that introduces a lot of new features and changes to the public API. Specifically, this release removed the dependency on the Indy SDK from the `@aries-framework/core` package. Agent setup is more flexible, but it also means the setup is more complex. Follow the mentioned steps in this document carefully to make the upgrade as smooth as possible. @@ -10,7 +10,9 @@ Aries Framework JavaScript 0.4.0 is a major release that introduces a lot of new The migration guide only covers how to migrate from 0.3.x to 0.4.x while keeping the same behaviour and dependencies. AFJ 0.4.0 introduced a lot of new features and adds support for [Aries Askar](https://github.com/hyperledger/aries-askar), [Indy VDR](https://github.com/hyperledger/indy-vdr) and [AnonCreds RS](https://github.com/hyperledger/anoncreds-rs) as a replacement for the Indy SDK. -Migrating to these new components requires additional migration steps, which need to be cloesly followed to prevent loss of data. Separate documentation will be made avaialable for migration to these new components. +Migrating to these new components requires additional migration steps, which need to be closely followed to prevent loss of data. These can be found at the [Update Indy SDK to Askar guide](../update-indy-sdk-to-askar.md). + +As noted in the [Update Indy SDK to Askar guide](../update-indy-sdk-to-askar.md), it is very important that the 0.3.x to 0.4.x is started after migrating from the Indy SDK to Aries Askar. ::: @@ -64,7 +66,7 @@ This section will list all breaking changes made to the public API of AFJ betwee :::info -If you have custom modules take into account there could be a lot more breaking changes that aren't documented here. We try to make sure that the biggest breaking changes to the internal API are also documented here, but it is possible some breaking changes are not documented here (feel free to open PRs). +If you have custom modules take into account there could be a lot more breaking changes that aren't documented here. We try to make sure that the biggest breaking changes to the internal API are also documented here, but it is possible some breaking changes are not documented here (feel free to open a pull request). ::: @@ -120,7 +122,7 @@ const agent = new Agent({ ### Indy Network Configuration -With the Indy SDK being extracted out of core, the `indyLedger` config option is no longer available on the `AgentConfig` interface. Instead, the `networks` config option is now available on the `IndySdkModule` config. +With the Indy SDK being extracted out of core, the `indyLedger` configuration option is no longer available on the `AgentConfig` interface. Instead, the `networks` configuration option is now available on the `IndySdkModule` configuration. In addition the `connectToIndyLedgersOnStartup` property has been removed in favour of a per-network `connectOnStartup` property that allows more fine-grained control over which networks to connect to on startup. @@ -202,9 +204,9 @@ The type of the `seed` property has also been changed to `Buffer` to make it mor The `did:sov` resolver and registrar were registered by default in 0.3.x of the agent. In 0.4.0 they've been moved to the `@aries-framework/indy-sdk` package and are thus not registered by default on the dids module anymore. In addition, the `IndySdkSovDidRegistrar` has been replaced in favour of the `IndySdkIndyDidRegistrar` which provides similar behaviour, but leverages the new [`did:indy` method](https://hyperledger.github.io/indy-did-method/#indy-did-method-identifiers), which removes ambiguity about which network to use. You can still use the `IndySdkSovDidResolver` to resolve `did:sov` dids. -Note that the `IndySdkModule` MUST be registered when using the indy sdk did resolvers and registrars (see [Agent Creation](#agent-creation)). The networks supported by the resolvers and registrar is determined by the `networks` registered on the `IndySdkModule` (see [Indy Network Configuration](#indy-network-configuration)). +Note that the `IndySdkModule` MUST be registered when using the Indy SDK did resolvers and registrars (see [Agent Creation](#agent-creation)). The networks supported by the resolvers and registrar is determined by the `networks` registered on the `IndySdkModule` (see [Indy Network Configuration](#indy-network-configuration)). -Also note that by default the `WebDidResolver`, `KeyDidResolver` and `PeerDidResolver` are registered, and setting the `resolvers` property on the `DidsModule` config will override the default resolvers (an exception is the `PeerDidResolver` as it is required for creating connections, and thus will always be registered). +Also note that by default the `WebDidResolver`, `KeyDidResolver` and `PeerDidResolver` are registered, and setting the `resolvers` property on the `DidsModule` configuration will override the default resolvers (an exception is the `PeerDidResolver` as it is required for creating connections, and thus will always be registered). The same thing is true for the `registrars`, for which the `KeyDidRegistrar` and `PeerDidRegistrar` are registered by default. If defining the `resolvers` and `registrars`, make sure to include the default registrars if you want to keep the previous behaviour. @@ -255,7 +257,7 @@ const agent = new Agent({ ### Removal of `publicDidSeed` and `publicDid` -To make AFJ more generic, and less focused on Hyperledger Indy, and indy dids, the `publicDidSeed` and `publicDid` properties have been removed from the agent configuration, the agent class, and the `Wallet` interface. +To make AFJ more generic, and less focused on Hyperledger Indy, and Indy dids, the `publicDidSeed` and `publicDid` properties have been removed from the agent configuration, the agent class, and the `Wallet` interface. The `publicDid` property was used as the did to register items in the ledger module. The approach had some limitations: @@ -264,11 +266,11 @@ The `publicDid` property was used as the did to register items in the ledger mod AFJ now provides generic APIs that can work with any ledger, and thus the `publicDid` property is no longer needed. Different sections of this migration guide will explain the different parts of how to use the new APIs, this section just focuses on how to replace the `publicDid` property. -The most common use case for the `publicDid` property was for registering an endorser did that can endorse (read: pay for) transactions on the ledger. This can now be done by importing the did into agent, after which it can be used by the anoncreds module to register schemas and credential definitions, and the did registrar to register dids. +The most common use case for the `publicDid` property was for registering an endorser did that can endorse (read: pay for) transactions on the ledger. This can now be done by importing the did into agent, after which it can be used by the AnonCreds module to register schemas and credential definitions, and the did registrar to register dids. -There's a **one-time import** that needs to be done to import the did into the agent using the `DidsApi.import` method. If you've previously used the `publicDidSeed` property, providing the private key is optional, as it is already stored in the wallet. Note that the `privateKey` is the same as the `publicDidSeed`, see [Changes to Wallet](#changes-to-wallet) for context). The `import` method will resolve the did passed to the `import` method (so make sure to regiser the `IndySdkIndyDidResolver`). It is recommended to import the endorser did as an `did:indy` did rather than a `did:sov` did, as the `did:sov` method is deprecated for creation. The `did:indy` did can be constructed by replacing `sov` with `indy:`, where `` should be replaced with a namespace as registered in the `networks` property of the `IndySdkModule` (see [Indy Network Configuration](#indy-network-configuration)). +There's a **one-time import** that needs to be done to import the did into the agent using the `DidsApi.import` method. If you've previously used the `publicDidSeed` property, providing the private key is optional, as it is already stored in the wallet. Note that the `privateKey` is the same as the `publicDidSeed`, see [Changes to Wallet](#changes-to-wallet) for context). The `import` method will resolve the did passed to the `import` method (so make sure to register the `IndySdkIndyDidResolver`). It is recommended to import the endorser did as an `did:indy` did rather than a `did:sov` did, as the `did:sov` method is deprecated for creation. The `did:indy` did can be constructed by replacing `sov` with `indy:`, where `` should be replaced with a namespace as registered in the `networks` property of the `IndySdkModule` (see [Indy Network Configuration](#indy-network-configuration)). -An inital list of namespace identifiers can be found in an [issue in the Indy Did Networks Repository](https://github.com/hyperledger/indy-did-networks/issues/3). In the future this list will be maintained in the [Indy DID Networks repository](https://github.com/hyperledger/indy-did-networks) itself. +An initial list of namespace identifiers can be found in an [issue in the Indy Did Networks Repository](https://github.com/hyperledger/indy-did-networks/issues/3). In the future this list will be maintained in the [Indy DID Networks repository](https://github.com/hyperledger/indy-did-networks) itself. @@ -346,7 +348,7 @@ await agent.dids.import({ AFJ 0.3.0 used the `useLegacyDidSovPrefix` to use the legacy `did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/` as the prefix in the `@type` of DIDComm message instead of the new `https://didcomm.org` prefix. Over time it has proven that this approach leads to undersired behaviour as all messages (even protocols that were defined after the new prefix was the default) would use the legacy prefix. However, due to not all implementations having support for new prefix, disabling the legacy prefixes proved to be a problem. -Therefore, in AFJ 0.4.0 the `useLegacyDidSovPrefix` property has been replaced with the `useDidSovPrefixWhereAllowed` property. This property will only use the legacy prefix for protocols that were defined before the new prefix was the default. This means that protocols that were defined after the new prefix was the default will use the new prefix independant of the value of the `useDidSovPrefixWhereAllowed` property. We hope this will allow us to slowly migrate away from the legacy prefix as new protocols are defined without breaking backwards compatibility. +Therefore, in AFJ 0.4.0 the `useLegacyDidSovPrefix` property has been replaced with the `useDidSovPrefixWhereAllowed` property. This property will only use the legacy prefix for protocols that were defined before the new prefix was the default. This means that protocols that were defined after the new prefix was the default will use the new prefix independent of the value of the `useDidSovPrefixWhereAllowed` property. We hope this will allow us to slowly migrate away from the legacy prefix as new protocols are defined without breaking backwards compatibility. @@ -388,7 +390,7 @@ const agent = new Agent({ The `injectionContainer` property on the `Agent` has been replaced by the `dependencyManager` property. The `dependencyManager` property is an instance of the `DependencyManager` class and wraps the injection container from `tsyringe`. -The `DependencyManager` _should_ provide all functionality that is needed, and it is recommended to not use the injection direclty. If you need to use the injection container directly, you can access it via the `container` property on the `DependencyManager` instance, but please raise an issue to discuss if the functionality you need should be added to the `DependencyManager` class. +The `DependencyManager` _should_ provide all functionality that is needed, and it is recommended to not use the injection directly. If you need to use the injection container directly, you can access it via the `container` property on the `DependencyManager` instance, but please raise an issue to discuss if the functionality you need should be added to the `DependencyManager` class. ### `connection` has been updated to `connectionId` in `TransportSession` @@ -396,20 +398,20 @@ The `connection` property on the `TransportSession` has been changed to `connect Accessing the connection on a transport session is an advanced case that is mostly only relevant when implementing a custom transport. If you are using the default transports, you should not be affected by this change. -### Replacment of Ledger Module with new AnonCreds Module +### Replacement of Ledger Module with new AnonCreds Module -The ledger module has been availalbe in AFJ since the very beginning, and was due for a big overhaul. With the addition of the dids module a while ago we already had a replacement for the `registerPublicDid` and `getPublicDid` methods on the ledger module. The other methods of the ledger module have been replaced by the AnonCreds module. +The ledger module has been available in AFJ since the very beginning, and was due for a big overhaul. With the addition of the dids module a while ago we already had a replacement for the `registerPublicDid` and `getPublicDid` methods on the ledger module. The other methods of the ledger module have been replaced by the AnonCreds module. -In AFJ 0.4.0 AnonCreds credential support is not part of the core framework anymore, and needs to be manually registerd on the agent. The first part is enabling the AnonCreds module, which allows to manage anoncreds objects, interact with the ledger, and issuer, hold and verify AnonCreds credentials and is explained in this section. The second part is actually allowing AnonCreds credentials to be exchanged in the Issue Credential and Present Proof protocols, which is explained in the [Manually Register AnonCreds Support in Credentials and Proofs Modules](#manually-register-anoncreds-support-in-credentials-and-proofs-modules) section. +In AFJ 0.4.0 AnonCreds credential support is not part of the core framework anymore, and needs to be manually registered on the agent. The first part is enabling the AnonCreds module, which allows to manage AnonCreds objects, interact with the ledger, and issuer, hold and verify AnonCreds credentials and is explained in this section. The second part is actually allowing AnonCreds credentials to be exchanged in the Issue Credential and Present Proof protocols, which is explained in the [Manually Register AnonCreds Support in Credentials and Proofs Modules](#manually-register-anoncreds-support-in-credentials-and-proofs-modules) section. -There's a few important take-aways based on the code example below: +There's a few important takeaways based on the code example below: - The `anoncreds` module can be accessed under the `agent.modules.anoncreds` property. - The interfaces are set up as generically as possible based on the [DID Registration](https://identity.foundation/did-registration/) and [DID Resolution](https://w3c-ccg.github.io/did-resolution/) specifications. - AnonCreds registries need to be manually registered so it's important to register the `IndySdkAnonCredsRegistry` on the `AnonCredsModule`. - It is now required to pass an `issuerId` when registering AnonCreds objects, according to the [AnonCreds Specification](https://hyperledger.github.io/anoncreds-spec/). Only `did:indy` issuer identifiers are allowed (based on the [`did:indy` AnonCreds Method](https://hyperledger.github.io/anoncreds-methods-registry/#didindy-anoncreds-method)), so the network can be inferred from the issuer identifier. -As will be explained in the [Manually Register AnonCreds Support in Credentials and Proofs Modules](#manually-register-anoncreds-support-in-credentials-and-proofs-modules), you can still use the unqualified issuer identifiers (best known as the [Hyperleger Indy Legacy AnonCreds Method](https://hyperledger.github.io/anoncreds-methods-registry/#hyperledger-indy-legacy-anoncreds-method)) in credential and proof exchanges. +As will be explained in the [Manually Register AnonCreds Support in Credentials and Proofs Modules](#manually-register-anoncreds-support-in-credentials-and-proofs-modules), you can still use the unqualified issuer identifiers (best known as the [Hyperledger Indy Legacy AnonCreds Method](https://hyperledger.github.io/anoncreds-methods-registry/#hyperledger-indy-legacy-anoncreds-method)) in credential and proof exchanges. @@ -534,8 +536,8 @@ Changes to the Proofs module include: - `getRequestedCredentialsForProofRequest` has been renamed to `getCredentialsForRequest` - `autoSelectCredentialsForProofRequest` has been renamed to `selectCredentialsForRequest` -- The `config` parameter for both methods has been removed and those have been replaced by proof format specific configuration options. In this case, the `config.filterByNonRevocationRequirements` has been added as `proofFormats.indy.filterByNonRevocationRequirements` (if the `indy` format is registerd as explained in the next section). The `config.filterByPresentationPreview` has been removed as the presentation preview was only present in the present proof V1 protocol, and due to it's limited applicability (the holder starts with a proposal) we've decided to remove this method for now. You can still filter the credentials yourself by using the `getCredentialsForRequest` method. -- Interfaces have been renamed to be more consistent with the method names. Please refere to the [`CredentialsApiOptions`](https://github.com/hyperledger/aries-framework-javascript/blob/v0.4.0/packages/core/src/modules/credentials/CredentialsApiOptions.ts) and [`ProofsApiOptions`](https://github.com/hyperledger/aries-framework-javascript/blob/v0.4.0/packages/core/src/modules/proofs/ProofsApiOptions.ts) for the interface names that can be imported. +- The `config` parameter for both methods has been removed and those have been replaced by proof format specific configuration options. In this case, the `config.filterByNonRevocationRequirements` has been added as `proofFormats.indy.filterByNonRevocationRequirements` (if the `indy` format is registered as explained in the next section). The `config.filterByPresentationPreview` has been removed as the presentation preview was only present in the present proof V1 protocol, and due to it's limited applicability (the holder starts with a proposal) we've decided to remove this method for now. You can still filter the credentials yourself by using the `getCredentialsForRequest` method. +- Interfaces have been renamed to be more consistent with the method names. Please refer to the [`CredentialsApiOptions`](https://github.com/hyperledger/aries-framework-javascript/blob/v0.4.0/packages/core/src/modules/credentials/CredentialsApiOptions.ts) and [`ProofsApiOptions`](https://github.com/hyperledger/aries-framework-javascript/blob/v0.4.0/packages/core/src/modules/proofs/ProofsApiOptions.ts) for the interface names that can be imported. If you encounter any other breaking changes in the Proofs and Credentials modules, please open an issue in the [Aries JavaScript Docs](https://github.com/hyperledger/aries-javascript-docs) repository. @@ -710,9 +712,9 @@ await agent.modules.anoncreds.createLinkSecret({ ### Default Outbound DIDComm Content Type now `application/didcomm-envelope-enc` -The default outbound DIDComm content type has been changed from `DidCommMimeType.V0` (`application/ssi-agent-wire`) to `DidCommMimeType.V1` (`application/didcomm-envelope-enc`). V1 is the default for DIDComm v1 (as [defined in Aries RFC 0044](https://github.com/hyperledger/aries-rfcs/blob/main/features/0044-didcomm-file-and-mime-types/README.md#detecting-didcomm-versions)). In the past, V0 resulted in better interoperability, but since it has been the default for so long it makes sense to change the default behaviour. +The default outbound DIDComm content type has been changed from `DidCommMimeType.V0` (`application/ssi-agent-wire`) to `DidCommMimeType.V1` (`application/didcomm-envelope-enc`). V1 is the default for DIDComm V1 (as [defined in Aries RFC 0044](https://github.com/hyperledger/aries-rfcs/blob/main/features/0044-didcomm-file-and-mime-types/README.md#detecting-didcomm-versions)). In the past, V0 resulted in better interoperability, but since it has been the default for so long it makes sense to change the default behaviour. -It is advised to use the default value as configured by the agent (V1). If you want to keep the old behaviour, you can [configure the `didCommMimeType` property in the agent config](/guides/tutorials/agent-config#didcommmimetype). +It is advised to use the default value as configured by the agent (V1). If you want to keep the old behaviour, you can [configure the `didCommMimeType` property in the agent configuration](/guides/tutorials/agent-config#didcommmimetype). @@ -752,7 +754,7 @@ const agent = new Agent({ ### Generalizing Indy properties in `CredentialExchangeRecord` -With AnonCreds credentials now being generalized to support multiple ledgers, the properties specific to Hyperledger Indy have now been generalized into a generic anoncreds properties. +With AnonCreds credentials now being generalized to support multiple ledgers, the properties specific to Hyperledger Indy have now been generalized into a generic AnonCreds properties. #### `credentialRecordType` @@ -790,7 +792,7 @@ First off, the `credentialRecordType` that was used to reference stored AnonCred #### Metadata -Second, the metadata keys and values have been renamed to be anoncreds specific rather than indy specific. The `CredentialMetadataKeys` have been replaced by the `AnonCredsCredentialMetadataKey` and `AnonCredsCredentialRequestMetadataKey` constants which can be imported from the `@aries-framework/anoncreds` package. +Second, the metadata keys and values have been renamed to be AnonCreds specific rather than Indy specific. The `CredentialMetadataKeys` have been replaced by the `AnonCredsCredentialMetadataKey` and `AnonCredsCredentialRequestMetadataKey` constants which can be imported from the `@aries-framework/anoncreds` package. @@ -852,7 +854,7 @@ With the different lifetimes of different objects, the `FileSystem` interface ha - `dataPath` - files that are used for long-term reliable storage purposes. These files will never be cleared. - `tempPath` - files that are used for temporary storage purposes. It's okay if the files are cleared from time to time. -If you're using the framework, you don't need to worry about this change. The agent may need to download some objects again after the update. If you've made a custom imlpementation of the `FileSystem`, make sure to support all three base paths, and make sure to correclty handle the lifecycle of the files. ITems stored under the `dataPath` **should never be cleared**. +If you're using the framework, you don't need to worry about this change. The agent may need to download some objects again after the update. If you've made a custom implementation of the `FileSystem`, make sure to support all three base paths, and make sure to correctly handle the life-cycle of the files. Items stored under the `dataPath` **should never be cleared**. :::caution @@ -868,6 +870,6 @@ Below all breaking storage changes are explained in as much detail as possible. See the [Update Assistant](/guides/updating/update-assistant.md) documentation for a guide on how to use the update assistant. -There are no config parameters to be provided to the update assistant to migrate from 0.3.x to 0.4.x. +There are no configuration parameters to be provided to the update assistant to migrate from 0.3.x to 0.4.x. > TODO