diff --git a/guides/concepts/agents.md b/guides/concepts/agents.md index 35b57a67..870a0dce 100644 --- a/guides/concepts/agents.md +++ b/guides/concepts/agents.md @@ -1,13 +1,13 @@ # Agents -When working with any Aries implementation, you will interact with an Aries -agent. This will be either directly or via a REST API, like [the Aries +When working with any Credo implementation, you will interact with an Credo +agent. This will be either directly or via a REST API, like [the Credo framework REST API](https://github.com/hyperledger/aries-framework-javascript-ext/tree/main/packages/rest). ### Characteristics -An Aries agent has three essential characteristics: +An Credo agent has three essential characteristics: 1. It acts as a fiduciary on behalf of a single identity owner (or, for agents of things like IoT devices, pets, and similar things, a single controller). @@ -15,27 +15,27 @@ An Aries agent has three essential characteristics: authorization. 1. It interacts using interoperable DIDComm protocols, more on that later. -What this means is that an Aries agent will act your behalf to issue create +What this means is that an Credo agent will act your behalf to issue create connections, issue credentials, send messages etc. It also have a cryptographic toolkit with which it can uniquely, securely and verifiably operate. And lastly it interacts with other entities, this could be another agent, via [DIDComm protocols](https://identity.foundation/didcomm-messaging/spec/) later on. The -Aries agent in the context of the Credo ecosystem is your entry-point +Credo agent in the context of the Credo ecosystem is your entry-point to all of the functionality. ### Categories -There are many categories of Aries agents and we will group them into two +There are many categories of Credo agents and we will group them into two categories; a mobile agent and a cloud agent. These agents are grouped based on their "location", e.g. a mobile wallet or server. Some other categories are a -static, thin, thick and rich Aries agents. These agents are grouped based on +static, thin, thick and rich Credo agents. These agents are grouped based on their complexity instead of their "location". The Credo ecosystem allows you to create a mobile agent and a cloud agent. It also allows any of the complexity categorized agents. ### Examples -Some examples of things that are Aries agent-like (since the definition can be +Some examples of things that are Credo agent-like (since the definition can be bit loose, these examples might help to get a clearer picture): **A mobile wallet** diff --git a/guides/ecosystem/index.md b/guides/ecosystem/index.md index b7038231..962c5a20 100644 --- a/guides/ecosystem/index.md +++ b/guides/ecosystem/index.md @@ -20,7 +20,7 @@ You can find their documentation here: ### Credo -Credo (core) is at the core of the Credo ecosystem. AFJ provides all the functionality related to cryptography, storage, messaging and more that is required +Credo (core) is at the core of the Credo ecosystem. Credo provides all the functionality related to cryptography, storage, messaging and more that is required ## Contributing in the Credo Ecosystem diff --git a/guides/extensions/index.md b/guides/extensions/index.md index 2a7fba83..addf2831 100644 --- a/guides/extensions/index.md +++ b/guides/extensions/index.md @@ -4,7 +4,7 @@ import DocCardList from '@theme/DocCardList'; Credo Extensions is an extensions repository to Credo. It hosts libraries built on top of Credo that don't necessarily belong to the core of the project. -Currently, there are four packages in the extension repository. Example extension libraries include React Hooks for AFJ and a REST API wrapper. +Currently, there are four packages in the extension repository. Example extension libraries include React Hooks for Credo and a REST API wrapper. | Package | Version | Description | | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | diff --git a/guides/extensions/push-notifications.md b/guides/extensions/push-notifications.md index abf736e3..ffb99f82 100644 --- a/guides/extensions/push-notifications.md +++ b/guides/extensions/push-notifications.md @@ -1,6 +1,6 @@ # Push Notifications -The Push Notifications plugin package provides a way for you to register your APNs and Firebase push notification token at an agent, allowing you to use push notifications directly from AFJ. +The Push Notifications plugin package provides a way for you to register your APNs and Firebase push notification token at an agent, allowing you to use push notifications directly from Credo. :::note diff --git a/guides/extensions/react-hooks.md b/guides/extensions/react-hooks.md index c0592047..f8e16a0d 100644 --- a/guides/extensions/react-hooks.md +++ b/guides/extensions/react-hooks.md @@ -1,6 +1,6 @@ # React Hooks -The React Hooks package exposes useful React hooks that allow you to easily interact with AFJ from a React client application. +The React Hooks package exposes useful React hooks that allow you to easily interact with Credo from a React client application. These hooks provide a simple way to query agent data in a client application, allowing you to focus on the user interface. @@ -32,7 +32,7 @@ yarn add @aries-framework/react-hooks@^0.5 ## Usage -This package exposes useful React hooks that allow you to easily interact with AFJ. +This package exposes useful React hooks that allow you to easily interact with Credo. Everything exported from Hooks: diff --git a/guides/extensions/redux-store.md b/guides/extensions/redux-store.md index c0c42475..70ad2b11 100644 --- a/guides/extensions/redux-store.md +++ b/guides/extensions/redux-store.md @@ -1,8 +1,8 @@ # Redux Store -The Redux Store is an implementation of state management that can be used to build React & React Native SSI clients using AFJ. +The Redux Store is an implementation of state management that can be used to build React & React Native SSI clients using Credo. -The Redux Store allows you to integrate state management for the most important parts of using AFJ in a client application (mediation, connections, credentials and proofs), allowing you to sync UI state with the state of the agent as it interacts with other agents through the framework. +The Redux Store allows you to integrate state management for the most important parts of using Credo in a client application (mediation, connections, credentials and proofs), allowing you to sync UI state with the state of the agent as it interacts with other agents through the framework. :::note diff --git a/guides/extensions/rest.md b/guides/extensions/rest.md index 8be12fb3..fb7b31a4 100644 --- a/guides/extensions/rest.md +++ b/guides/extensions/rest.md @@ -1,8 +1,8 @@ # REST API -The Credo REST API provides simple RESTful endpoints for AFJ methods, to allow you stand up an agent for communication over the internet instantly. You simply provide your agent configuration. The REST endpoints allow you to interact with your agent over HTTP and WebSockets. +The Credo REST API provides simple RESTful endpoints for Credo methods, to allow you stand up an agent for communication over the internet instantly. You simply provide your agent configuration. The REST endpoints allow you to interact with your agent over HTTP and WebSockets. -The AFJ REST API is the most convenient way for self-sovereign identity (SSI) developers to interact with SSI agents. +The Credo REST API is the most convenient way for self-sovereign identity (SSI) developers to interact with SSI agents. - ⭐ **Endpoints** to create connections, issue credentials, and request proofs. - 💻 **CLI** that makes it super easy to start an instance of the REST API. @@ -32,7 +32,7 @@ After installing and confirming that Libindy is installed, simply run: ```sh npx -p @aries-framework/rest afj-rest start \ - --label "AFJ Rest" \ + --label "Credo Rest" \ --wallet-id "walletId" \ --wallet-key "walletKey" \ --endpoint http://localhost:5000 \ diff --git a/guides/getting-started/set-up/index.md b/guides/getting-started/set-up/index.md index 899936dd..f880360c 100644 --- a/guides/getting-started/set-up/index.md +++ b/guides/getting-started/set-up/index.md @@ -13,7 +13,7 @@ This guide assumes you have followed the [Prerequisites](./prerequisites), and y Credo is still in **active development**, and as such some APIs are still experimental. **When using any experimental features, make sure to use an exact version of Credo** (`0.4.0`) instead of a range (`^0.4.0`), to prevent accidental breaking changes. If you're not leveraging any experimental features, you can use a range (`^0.4.0`) to get the latest bugfixes and features. -For AFJ `0.4.x`, **the following features are experimental**: +For Credo `0.4.x`, **the following features are experimental**: - Implementing your own `AnonCredsRegistry` and AnonCreds service implementation. - Using the shared component libraries from `@aries-framework/aries-askar`, `@aries-framework/indy-vdr` and `@aries-framework/anoncreds-rs` @@ -67,7 +67,7 @@ of your application. + import 'react-native-get-random-values' ``` -In addition you need add support for resolving modules with the `.cjs` extension, as this is used by some of AFJ's dependencies and not automatically supported by React Native. +In addition you need add support for resolving modules with the `.cjs` extension, as this is used by some of Credo's dependencies and not automatically supported by React Native. ```js title="metro.config.js" showLineNumbers module.exports = { @@ -130,7 +130,7 @@ enough for your specific use cases. Please refer to the ### Adding a wallet and storage implementation -After creating the `Agent` instance, we need to provide the agent with a wallet and storage implementation. AFJ provides a few implementations out of the box, but you can also implement your own. Currently the following Wallet and Storage implementations are supported out of the box. Follow the specific guides to set up the wallet and storage implementation of your choice. +After creating the `Agent` instance, we need to provide the agent with a wallet and storage implementation. Credo provides a few implementations out of the box, but you can also implement your own. Currently the following Wallet and Storage implementations are supported out of the box. Follow the specific guides to set up the wallet and storage implementation of your choice. - [Aries Askar](./set-up/aries-askar) - Recommended. - [Indy SDK](./set-up/indy-sdk) - Legacy. Will be deprecated in the future. diff --git a/guides/tutorials/agent-config/logging.md b/guides/tutorials/agent-config/logging.md index f0df31e0..5bdc762d 100644 --- a/guides/tutorials/agent-config/logging.md +++ b/guides/tutorials/agent-config/logging.md @@ -68,7 +68,7 @@ The `setLogger` and `setDefaultLogger` methods have only been implemented in the ::: -The easiest way to do this from AFJ is through the `indy` property of `agentDependencies`. +The easiest way to do this from Credo is through the `indy` property of `agentDependencies`. ```ts import { agentDependencies } from '@aries-framework/node' @@ -84,4 +84,4 @@ agentDependencies.indy.setLogger((level, target, message, modulePath, file, line > WARNING: You can only set the logger once. Call indy_set_default_logger, indy_set_logger, not both. Once it's been set, libindy won't let you change it. You can also set the environment variable `RUST_LOG` to log at specified log levels. -See https://crates.io/crates/env_logger for more information. +See for more information. diff --git a/guides/tutorials/indy-sdk-postgres-database-nodejs/index.md b/guides/tutorials/indy-sdk-postgres-database-nodejs/index.md index 99cf0e9e..b640bff4 100644 --- a/guides/tutorials/indy-sdk-postgres-database-nodejs/index.md +++ b/guides/tutorials/indy-sdk-postgres-database-nodejs/index.md @@ -2,7 +2,7 @@ By default the Indy SDK will use an SQLite database for storage. In mobile environments this is sufficient and allows us to keep storage local to the device, but in server environments we oftentimes want a more scalable storage solution. By leveraging the PostgreSQL plugin for Indy SDK we can use PostgreSQL as a storage solution instead of SQLite. -This document describes the installation process of the Postgres plugin for IndySDK and how you need to configure AFJ to use it. +This document describes the installation process of the Postgres plugin for IndySDK and how you need to configure Credo to use it. ## Installation of the Postgres Plugin @@ -12,7 +12,7 @@ For installation of the Postgres plugin, please refer to the platform specific g - [Linux](./linux.md) - [Windows](./windows.md) -## Using the Postgres Plugin in AFJ +## Using the Postgres Plugin in Credo ```typescript showLineNumbers set-up-indy-sdk-postgres.ts section-1 diff --git a/guides/updating/index.md b/guides/updating/index.md index 833a9e76..728d5796 100644 --- a/guides/updating/index.md +++ b/guides/updating/index.md @@ -1,6 +1,6 @@ import DocCardList from '@theme/DocCardList'; -# Updating AFJ +# Updating Credo This section will cover everything you need to know about updating Credo to a newer version. @@ -10,20 +10,20 @@ This section will cover everything you need to know about updating Credo to a ne Credo follows [semantic versioning](https://semver.org/). This means that major version changes (**1**.0.0) are considered breaking changes. When features are added this is a minor version change (0.**1**.0). For bug fixes the patch version change is used (0.0.**1**). -While AFJ is still in pre-1.0.0 version, the version change types are shifted to the right. This means a major version change is now a minor change (0.**1**.0) and a minor change is now a patch change (0.0.**1**). This is done to keep the version below 1.0.0, indicating the framework is still in early development and users can expect more breaking changes that when the version has already reached 1.0.0. +While Credo is still in pre-1.0.0 version, the version change types are shifted to the right. This means a major version change is now a minor change (0.**1**.0) and a minor change is now a patch change (0.0.**1**). This is done to keep the version below 1.0.0, indicating the framework is still in early development and users can expect more breaking changes that when the version has already reached 1.0.0. This means if the second number in the version (0.**1**.0) changes, you need to be careful with updating and always consult this page for update instructions. If only the third number changes (0.0.**1**), you can update without any issues. ## Types of breaking changes -Updates to AFJ bring new features and improvements to the framework. To better adapt the framework to new features we sometimes make breaking changes that will improve how AFJ works. There's two parts to updates with breaking changes: +Updates to Credo bring new features and improvements to the framework. To better adapt the framework to new features we sometimes make breaking changes that will improve how Credo works. There's two parts to updates with breaking changes: 1. Breaking code changes 2. Breaking storage changes ### Breaking Code Changes -Breaking changes to code means changes to how you interact with AFJ. This includes methods being renamed, moved to another module or extended to better integrate with new features. We'll try to cover all breaking changes in migration guides, so you know exactly what is needed to update to a new version and keep the same functionality. +Breaking changes to code means changes to how you interact with Credo. This includes methods being renamed, moved to another module or extended to better integrate with new features. We'll try to cover all breaking changes in migration guides, so you know exactly what is needed to update to a new version and keep the same functionality. :::info @@ -39,7 +39,7 @@ Breaking changes to storage are a bit more complex to deal with. While breaking Currently the following migration guides are available: -- [Migrating from AFJ 0.1.0 to 0.2.x](./versions/0.1-to-0.2.md) -- [Migrating from AFJ 0.2.x to 0.3.x](./versions/0.2-to-0.3.md) -- [Migrating from AFJ 0.3.x to 0.4.x](./versions/0.3-to-0.4.md) +- [Migrating from Credo 0.1.0 to 0.2.x](./versions/0.1-to-0.2.md) +- [Migrating from Credo 0.2.x to 0.3.x](./versions/0.2-to-0.3.md) +- [Migrating from Credo 0.3.x to 0.4.x](./versions/0.3-to-0.4.md) - [Migrating from an Indy SDK Wallet to Aries Askar](./update-indy-sdk-to-askar.md) diff --git a/guides/updating/update-assistant.md b/guides/updating/update-assistant.md index 33fb3ab6..81b98c59 100644 --- a/guides/updating/update-assistant.md +++ b/guides/updating/update-assistant.md @@ -1,6 +1,6 @@ # Update Assistant -The Update Assistant helps you update the storage objects from AFJ to newer versions. This documents describes the different ways you can leverage the Update Assistant from fully managed to more manual approaches. +The Update Assistant helps you update the storage objects from Credo to newer versions. This documents describes the different ways you can leverage the Update Assistant from fully managed to more manual approaches. - [Update Strategies](#update-strategies) - [Manually instantiating the update assistant on agent startup](#manually-instantiating-the-update-assistant-on-agent-startup) diff --git a/guides/updating/update-indy-sdk-to-askar.md b/guides/updating/update-indy-sdk-to-askar.md index aee0d120..a28fc613 100644 --- a/guides/updating/update-indy-sdk-to-askar.md +++ b/guides/updating/update-indy-sdk-to-askar.md @@ -16,7 +16,7 @@ Postgres is not supported. If you are using postgres with Indy SDK and need to u :::caution -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. +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 Credo 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. @@ -46,7 +46,7 @@ Aries Askar has a specific way to store keys and every key, defined by the categ :::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 Credo 0.3.x to 0.4.x](./versions/0.3-to-0.4.md#removal-of-publicdidseed-and-publicdid) ::: @@ -84,7 +84,7 @@ 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 practice 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: +### add the required dependencies ```sh yarn add @hyperledger/aries-askar-react-native @aries-framework/indy-sdk-to-askar-migration react-native-fs diff --git a/guides/updating/versions/0.1-to-0.2.md b/guides/updating/versions/0.1-to-0.2.md index 6e2f7fad..342b0a05 100644 --- a/guides/updating/versions/0.1-to-0.2.md +++ b/guides/updating/versions/0.1-to-0.2.md @@ -1,8 +1,8 @@ -# Migrating from AFJ 0.1.0 to 0.2.x +# Migrating from Credo 0.1.0 to 0.2.x -This document describes everything you need to know for updating AFJ 0.1.0 to 0.2.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). +This document describes everything you need to know for updating Credo 0.1.0 to 0.2.x. If you're not aware of how updating in Credo works make sure to first read the guide on [Updating Credo](/guides/updating/index.md). -First of all, update you dependencies to the 0.2.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.2.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 Credo. @@ -28,7 +28,7 @@ npm install @aries-framework/node@^0.2.0 @aries-framework/core@^0.2.0 ## Breaking Code Changes -This section will list all breaking changes made to the public API of AFJ between version 0.1.0 and 0.2.0. +This section will list all breaking changes made to the public API of Credo between version 0.1.0 and 0.2.0. :::info @@ -90,7 +90,7 @@ await agent.credentials.offerCredential({ Previously when we received a message from another connection we would store the relevant data from the exchange in the credential record. The values we would store were the `credentialDefinitionId` and `schemaId` in the credential metadata, and the `credentialAttributes` field. -Starting with AFJ 0.2.0 the values are not stored in the credential record until after the message content has been accepted (in the case of an offer this means after sending the request message). This is to avoid ambiguity of the values in the credential record. If I have sent a proposal and then receive an offer, should the credential record contain the values from the proposal or the values from the offer? The first one reflects our view on what the data should be, the second one reflects the latest data. +Starting with Credo 0.2.0 the values are not stored in the credential record until after the message content has been accepted (in the case of an offer this means after sending the request message). This is to avoid ambiguity of the values in the credential record. If I have sent a proposal and then receive an offer, should the credential record contain the values from the proposal or the values from the offer? The first one reflects our view on what the data should be, the second one reflects the latest data. We decided to make the record properties always hold our view of what the data should be, and only update it after accepting the contents of a received message (either using auto accept, or by calling the `acceptXXX` methods on the credential module). @@ -183,7 +183,7 @@ const requestMessage = await agent.credentials.findRequestMessage('credentialRec const credentialMessage = await agent.credentials.findCredentialMessage('credentialRecordId') ``` -Because AFJ now also supports the issue credential v2 protocol, the return type of this protocol has been changed to `V1XXXMessage | V2XXXMessage | null`. Take this into account when working with the messages. +Because Credo now also supports the issue credential v2 protocol, the return type of this protocol has been changed to `V1XXXMessage | V2XXXMessage | null`. Take this into account when working with the messages. You can check if a message is a specific version by using the `instanceof` operator: @@ -199,11 +199,11 @@ Shared properties (e.g. the proposal messages for v1 and v2 both have the `crede ### Connections Module -Version 0.2.0 added support for the [Out of Band protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0434-outofband/README.md) with support for the [DID Exchange protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0023-did-exchange). Internally AFJ now uses out of band invitations for all connections, even if you're connecting using the old invitations from the [Connection protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0160-connection-protocol). +Version 0.2.0 added support for the [Out of Band protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0434-outofband/README.md) with support for the [DID Exchange protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0023-did-exchange). Internally Credo now uses out of band invitations for all connections, even if you're connecting using the old invitations from the [Connection protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0160-connection-protocol). #### Creating a Legacy Invitation -The `createInvitation` method on the connections module has been moved to the out of band module and renamed to `createLegacyInvitation`. The method is not planned to be removed in the near future, the legacy merely indicates this will create an RFC 0160 connection invitation. Internally AFJ creates an out of band invitation and transforms it into a legacy invitation. If you want to create an out of band invitation instead, you should use `oob.createInvitation`. +The `createInvitation` method on the connections module has been moved to the out of band module and renamed to `createLegacyInvitation`. The method is not planned to be removed in the near future, the legacy merely indicates this will create an RFC 0160 connection invitation. Internally Credo creates an out of band invitation and transforms it into a legacy invitation. If you want to create an out of band invitation instead, you should use `oob.createInvitation`. @@ -251,7 +251,7 @@ const connections = await agent.connections.findAllByOutOfBandId(outOfBandRecord #### Receiving a Legacy Invitation -The `receiveInvitation` and `receiveInvitationFromUrl` methods on the connections module have also been moved to the out of band module. Both methods support the new out of band invitations and the legacy RFC 0160 connection invitations. Internally AFJ converts the old invitations to out of band invitations. +The `receiveInvitation` and `receiveInvitationFromUrl` methods on the connections module have also been moved to the out of band module. Both methods support the new out of band invitations and the legacy RFC 0160 connection invitations. Internally Credo converts the old invitations to out of band invitations. @@ -313,7 +313,7 @@ If you still need to access the old `ConnectionState` you can do so by accessing ### Updating Custom Messages to the New Message Type Objects -Although this isn't a breaking change to the public API of the framework, it is something that you will need to take into account when creating custom modules. Starting from AFJ 0.2.0 we now support handling messages with different minor versions (e.g. receive a message with `@type` version 1.1 while we only support 1.0). With this change messages must now declare the message type as an `ParsedMessageType` object. We've added an `parseMessageType` util method that can help with this. +Although this isn't a breaking change to the public API of the framework, it is something that you will need to take into account when creating custom modules. Starting from Credo 0.2.0 we now support handling messages with different minor versions (e.g. receive a message with `@type` version 1.1 while we only support 1.0). With this change messages must now declare the message type as an `ParsedMessageType` object. We've added an `parseMessageType` util method that can help with this. diff --git a/guides/updating/versions/0.2-to-0.3.md b/guides/updating/versions/0.2-to-0.3.md index d231bb4f..f1a47066 100644 --- a/guides/updating/versions/0.2-to-0.3.md +++ b/guides/updating/versions/0.2-to-0.3.md @@ -1,8 +1,8 @@ -# Migrating from AFJ 0.2.x to 0.3.x +# Migrating from Credo 0.2.x to 0.3.x -This document describes everything you need to know for updating AFJ 0.2.x to 0.3.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). +This document describes everything you need to know for updating Credo 0.2.x to 0.3.x. If you're not aware of how updating in Credo works make sure to first read the guide on [Updating Credo](/guides/updating/index.md). -First of all, update you dependencies to the 0.3.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.3.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 Credo. @@ -28,11 +28,11 @@ npm install @aries-framework/node@^0.3.0 @aries-framework/core@^0.3.0 ## Breaking Code Changes -This section will list all breaking changes made to the public API of AFJ between version 0.2.x and 0.3.0. +This section will list all breaking changes made to the public API of Credo between version 0.2.x and 0.3.0. :::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 (e.g. see [Updating Custom Modules to the Plugin API](#Updating-Custom-Modules-to-the-new-Plugin-API)), 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 (e.g. see [Updating Custom Modules to the Plugin API](#updating-custom-modules-to-the-new-plugin-api)), but it is possible some breaking changes are not documented here (feel free to open PRs). ::: @@ -70,7 +70,7 @@ Note that, if you are defining `indyLedgers` configuration, you should set the i In accordance with [Aries RFC 0360](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0360-use-did-key), since 0.2.5 there is a configuration parameter called `useDidKeyInProtocols` which, when enabled, will encode keys in did:key instead of previous base58 format, unless the other party has started a protocol and is using base58. -This parameter was previously disabled by default and now it is enabled. If your agent only interacts with modern agents (e.g. AFJ 0.2.5 and newer) this will not represent any issue. Otherwise it is safer to explicitly set it to `false`. However, keep in mind that we expect this setting to be deprecated in the future, so we encourage you to update all your agents to use did:key. +This parameter was previously disabled by default and now it is enabled. If your agent only interacts with modern agents (e.g. Credo 0.2.5 and newer) this will not represent any issue. Otherwise it is safer to explicitly set it to `false`. However, keep in mind that we expect this setting to be deprecated in the future, so we encourage you to update all your agents to use did:key. ### Modules extracted from the core @@ -272,7 +272,7 @@ const requestMessage = await agent.proofs.findRequestMessage('proofRecordId') const presentationMessage = await agent.proofs.findPresentationMessage('proofRecordId') ``` -Because AFJ now also supports the present proof v2 protocol, the return type of this protocol has been changed to `V1XXXMessage | V2XXXMessage | null`. Take this into account when working with the messages. +Because Credo now also supports the present proof v2 protocol, the return type of this protocol has been changed to `V1XXXMessage | V2XXXMessage | null`. Take this into account when working with the messages. You can check if a message is a specific version by using the `instanceof` operator: @@ -344,7 +344,7 @@ const outOfBandRecord = await agent.oob.createInvitation({ }) const invitationUrl = outOfBandRecord.outOfBandInvitation.toUrl({ - domain: 'https://afj.com', + domain: 'https://Credo.com', }) ``` @@ -352,7 +352,7 @@ As you can see, there's now a lot more ways to use a message not tied to a conne ### Updating Custom Modules to the new Plugin API -Although this isn't a breaking change to the public API of the framework, it is something that you will need to take into account if you have custom modules and want to upgrade them to make compatible with AFJ 0.3.0. +Although this isn't a breaking change to the public API of the framework, it is something that you will need to take into account if you have custom modules and want to upgrade them to make compatible with Credo 0.3.0. #### Renaming handler classes diff --git a/guides/updating/versions/0.3-to-0.4.md b/guides/updating/versions/0.3-to-0.4.md index fecdb9ce..1df3e10c 100644 --- a/guides/updating/versions/0.3-to-0.4.md +++ b/guides/updating/versions/0.3-to-0.4.md @@ -1,14 +1,14 @@ -# Migrating from AFJ 0.3.x to 0.4.x +# Migrating from Credo 0.3.x to 0.4.x -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). +This document describes everything you need to know for updating Credo 0.3.x to 0.4.x. If you're not aware of how updating in Credo works make sure to first read the guide on [Updating Credo](/guides/updating/index.md). -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. +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 Credo. Credo 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. :::caution -The migration guide only covers how to migrate from 0.3.x to 0.4.x while keeping the same behavior 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. +The migration guide only covers how to migrate from 0.3.x to 0.4.x while keeping the same behavior and dependencies. Credo 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 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). @@ -24,7 +24,7 @@ Multi-tenancy is not covered in the 0.3.x to 0.4.x migration guide. If you're us :::caution -The following APIs, modules and features are experimental and therefore not covered by the semver versioning in Credo. If you're using any of these features, make sure to use an exact version of AFJ (`0.4.0`) instead of a range (`^0.4.0`): +The following APIs, modules and features are experimental and therefore not covered by the semver versioning in Credo. If you're using any of these features, make sure to use an exact version of Credo (`0.4.0`) instead of a range (`^0.4.0`): - Implementing your own `AnonCredsRegistry` and AnonCreds service implementation. Using the default implementations (Indy SDK, AnonCreds RS) is fine. - Using the shared component libraries from `@aries-framework/aries-askar`, `@aries-framework/indy-vdr` and `@aries-framework/anoncreds-rs` @@ -80,7 +80,7 @@ npm install --save-dev @types/indy-sdk ## Breaking Code Changes -This section will list all breaking changes made to the public API of AFJ between version 0.3.x and 0.4.0. +This section will list all breaking changes made to the public API of Credo between version 0.3.x and 0.4.0. :::info @@ -275,14 +275,14 @@ 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 Credo 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: - An agent could only have a single `publicDid` property. This means that if you wanted to write to multiple ledgers you would have to create multiple agents - The property assumed only Indy ledgers would be used, and didn't take into account the possibility of other ledgers. -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. +Credo 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. @@ -364,9 +364,9 @@ await agent.dids.import({ ### More Granular Usage of Legacy `did:sov` Prefix in DIDComm Messages -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 undesired behavior 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. +Credo 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 undesired behavior 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 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. +Therefore, in Credo 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. @@ -418,9 +418,9 @@ Accessing the connection on a transport session is an advanced case that is most ### Replacement of Ledger Module with new 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. +The ledger module has been available in Credo 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 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. +In Credo 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 takeaways based on the code example below: @@ -561,7 +561,7 @@ If you encounter any other breaking changes in the Proofs and Credentials module ### Changes to the AnonCreds Credential and Proof Format -With the 0.4.0 release, AFJ now provides a pluggable AnonCreds interface, and requires support AnonCreds credentials to be explicitly registered on the agent. This is also the case for registering the credential and proof formats. +With the 0.4.0 release, Credo now provides a pluggable AnonCreds interface, and requires support AnonCreds credentials to be explicitly registered on the agent. This is also the case for registering the credential and proof formats. In 0.3.x, the `IndyProofFormatService` and `IndyCredentialFormatService` were registered by default. In 0.4.x, these services are no longer registered by default and they should be imported from the `@aries-framework/anoncreds` package as `LegacyIndyProofFormatService` and `LegacyIndyCredentialFormatService` and are based on [Aries RFC 0592](https://github.com/hyperledger/aries-rfcs/blob/main/features/0592-indy-attachments/README.md). In a future version the new `AnonCredsCredentialFormatService` and `AnonCredsProofFormatService` will be added to the AnonCreds package, which are based on [Aries RFC 0771](https://github.com/hyperledger/aries-rfcs/pull/771) and allow for AnonCreds credentials to be exchanged based on the new ledger agnostic [AnonCreds Specification](https://hyperledger.github.io/anoncreds-spec/).