chore: initial cleanup and scripts for 0.5.0

.github/workflows/continuous-integration.yml

@@ -13,7 +13,7 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v3
         with:
-          node-version: 16.x
+          node-version: 18.x
           cache: yarn
 
       # ignore scripts as indy-sdk will try to build and we don't have libindy

.github/workflows/deploy.yml

@@ -15,7 +15,7 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v3
         with:
-          node-version: 16.x
+          node-version: 18.x
           cache: yarn
 
       # ignore scripts as indy-sdk will try to build and we don't have libindy

guides/extensions/push-notifications.md

@@ -4,7 +4,7 @@ The Push Notifications plugin package provides a way for you to register your AP
 
 :::note
 
-This document is for version **`0.5.x`** of the `@aries-framework/push-notifications` package, that works with `@aries-framework/core` version **`0.4.x`**. Extension packages (such as Push Notifications) are versioned separately from the core packages.
+This document is for version **`0.5.x`** of the `@credo-ts/push-notifications` package, that works with `@credo-ts/core` version **`0.4.x`**. Extension packages (such as Push Notifications) are versioned separately from the core packages.
 
 :::
 
@@ -17,22 +17,22 @@ To add the Push Notifications plugin package to your existing project simply run
 ## npm
 
 ```sh
-npm i @aries-framework/push-notifications
+npm i @credo-ts/push-notifications
 ```
 
 ## Yarn
 
 ```sh
-yarn add @aries-framework/push-notifications
+yarn add @credo-ts/push-notifications
 ```
 
 <!--tabs-->
 
 ## Usage
 
 ```ts
-import { PushNotificationsApnsModule, PushNotificationsFcmModule } from '@aries-framework/push-notifications'
-import {  } from '@aries-framework/core'
+import { PushNotificationsApnsModule, PushNotificationsFcmModule } from '@credo-ts/push-notifications'
+import {  } from '@credo-ts/core'
 
 const agent = new Agent({
     /** agent config... */,

guides/extensions/react-hooks.md

@@ -6,7 +6,7 @@ These hooks provide a simple way to query agent data in a client application, al
 
 :::note
 
-This document is for version **`0.5.x`** of the `@aries-framework/react-hooks` package, that works with `@aries-framework/core` version **`0.4.x`**. Extension packages (such as React Hooks) are versioned separately from the core packages.
+This document is for version **`0.5.x`** of the `@credo-ts/react-hooks` package, that works with `@credo-ts/core` version **`0.4.x`**. Extension packages (such as React Hooks) are versioned separately from the core packages.
 
 :::
 
@@ -19,13 +19,13 @@ To add the React Hooks package to your existing project simply run:
 ## npm
 
 ```sh
-npm i @aries-framework/react-hooks@^0.5
+npm i @credo-ts/react-hooks@^0.5
 ```
 
 ## Yarn
 
 ```sh
-yarn add @aries-framework/react-hooks@^0.5
+yarn add @credo-ts/react-hooks@^0.5
 ```
 
 <!--/tabs-->
@@ -47,13 +47,13 @@ import AgentProvider, {
   useProofs,
   useProofById,
   useProofByState,
-} from '@aries-framework/react-hooks'
+} from '@credo-ts/react-hooks'
 ```
 
 First step is to wrap your entire app in our `<AgentProvider/>`. The provider takes an initialized agent. The base of your app should look something like this:
 
 ```tsx
-import AgentProvider from '@aries-framework/react-hooks'
+import AgentProvider from '@credo-ts/react-hooks'
 
 const App = () => {
   const [agent, setAgent] = useState(undefined)
@@ -83,7 +83,7 @@ The `useAgent` hook returns `{ agent, loading }` so anytime you need access to a
 The following is an example of how you could use the `useConnections` hook to render a full list of all a user's connections.
 
 ```ts
-import { useConnections } from '@aries-framework/react-hooks'
+import { useConnections } from '@credo-ts/react-hooks'
 
 const MyConnectionsComponent = () => {
   // all base hooks return an array of objects and a loading boolean

guides/extensions/redux-store.md

@@ -6,7 +6,7 @@ The Redux Store allows you to integrate state management for the most important
 
 :::note
 
-This document is for version **`0.4.x`** of the `@aries-framework/redux-store` package, that works with `@aries-framework/core` version **`0.4.x`**. Extension packages (such as Redux Store) are versioned separately from the core packages.
+This document is for version **`0.4.x`** of the `@credo-ts/redux-store` package, that works with `@credo-ts/core` version **`0.4.x`**. Extension packages (such as Redux Store) are versioned separately from the core packages.
 
 :::
 
@@ -19,13 +19,13 @@ To add the Redux Store package to your existing project simply run:
 ## npm
 
 ```sh
-npm i @aries-framework/redux-store
+npm i @credo-ts/redux-store
 ```
 
 ## Yarn
 
 ```sh
-yarn add @aries-framework/redux-store
+yarn add @credo-ts/redux-store
 ```
 
 <!--tabs-->

guides/extensions/rest.md

@@ -10,7 +10,7 @@ The Credo REST API is the most convenient way for self-sovereign identity (SSI)
 
 :::danger
 
-The `@aries-framework/rest` package has not been updated to work with the latest version (**`0.4.x`**) of `@aries-framework/core`. The documentation in this section is for version **`0.9.x`** of the `@aries-framework/rest` package, that works with `@aries-framework/core` version **`0.2.x`**. Extension packages (such as REST API) are versioned separately from the core packages.
+The `@credo-ts/rest` package has not been updated to work with the latest version (**`0.4.x`**) of `@credo-ts/core`. The documentation in this section is for version **`0.9.x`** of the `@credo-ts/rest` package, that works with `@credo-ts/core` version **`0.2.x`**. Extension packages (such as REST API) are versioned separately from the core packages.
 
 :::
 
@@ -31,7 +31,7 @@ You can do this directly on your machine.
 After installing and confirming that Libindy is installed, simply run:
 
 ```sh
-npx -p @aries-framework/rest afj-rest start \
+npx -p @credo-ts/rest credo-rest start \
   --label "Credo Rest" \
   --wallet-id "walletId" \
   --wallet-key "walletKey" \
@@ -48,5 +48,5 @@ The REST API provides an OpenAPI schema that can easily be viewed using the Swag
 To find out all available configuration options from the CLI, you can run the CLI command with `--help`. This will print a full list of all available options.
 
 ```sh
-npx -p @aries-framework/rest afj-rest start --help
+npx -p @credo-ts/rest afj-rest start --help
 ```

guides/features/aries.md

@@ -0,0 +1,42 @@
+# Hyperledger Aries and Aries Interop Profile
+
+Initially, Credo was built as an Hyperledger Aries framework, focusing on implementing the [Aries RFCs](https://github.com/hyperledger/aries-rfcs) and supporting the [Aries Interop Profile](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile).
+
+Support for Hyperledger Aries, DIDComm and AnonCreds is at the core of Credo, and thus if you're building an identity solution supporting these standards, Credo is a great fit.
+
+## Aries Interop Profile
+
+Credo currently has **full support for [Aries Interop Profile 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#aries-interop-profile-version-10) (AIP 1)** as well as **most of the features from [Aries Interop Profile 2.0](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#aries-interop-profile-version-20) (AIP 2)**
+
+The following table lists which parts of AIP 2 are supported by Credo:
+
+| Feature                                                                                                                                           | Support | Notes                                                                                                                                                             |
+| ------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Base Requirements](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#base-requirements)                    | ✅      |                                                                                                                                                                   |
+| [Mediator Coordination](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#mediate-mediator-coordination)    | ✅      |                                                                                                                                                                   |
+| [Indy Based Credentials](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#indycred-indy-based-credentials) | ✅      | Also support for the newer ledger-agnostic [AnonCreds attachment format](https://github.com/hyperledger/aries-rfcs/tree/main/features/0771-anoncreds-attachments) |
+| [JSON-LD Based Credentials](https://github.com/hyperledger/aries-rfcs/tree/main/features/0771-anoncreds-attachments)                              | ✅      |                                                                                                                                                                   |
+| [BBS+ Based Credentials](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#bbscred-bbs-based-credentials)   | ✅      |                                                                                                                                                                   |
+| [Chat related features](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#chat-chat-related-features)       | ✅      |                                                                                                                                                                   |
+| [DIDCommm v2 Prep](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#didcommv2prep-didcomm-v2-prep)         | ❌      |                                                                                                                                                                   |
+
+## Additional Aries RFCs
+
+In addition to the Aries RFCs listed by the Aries Interop Profile, Credo also supports the following Aries RFCs:
+
+| Aries RFC                                                                                                                                                                     | Support | Notes |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----- |
+| [Aries RFC 0212 Pickup V1](https://github.com/hyperledger/aries-rfcs/tree/main/features/0212-pickup)                                                                          | ✅      |       |
+| [Aries RFC 0685 Pickup V2](https://github.com/hyperledger/aries-rfcs/tree/main/features/0685-pickup-v2)                                                                       | ✅      |       |
+| [Aries RFC 0721 Revocation Notification V2](https://github.com/hyperledger/aries-rfcs/tree/be8c7bf856577745e0165e9cda0918fa554d120e/features/0721-revocation-notification-v2) | ✅      |       |
+| [Aries RFC 0771: AnonCreds Attachment Format](https://github.com/hyperledger/aries-rfcs/tree/be8c7bf856577745e0165e9cda0918fa554d120e/features/0771-anoncreds-attachments)    | ✅      |       |
+| [Aries RFC 0794: DID Rotate V1](https://github.com/hyperledger/aries-rfcs/blob/main/features/0794-did-rotate/README.md)                                                       | ✅      |       |
+
+## Divergence from Aries RFCs
+
+Although Credo tries to follow the standards as described in the Aries RFCs as much as possible, some features in Credo slightly diverge from the written spec. Below is an overview of the features that diverge from the spec, their impact and the reasons for diverging.
+
+| Feature                                                                                                                                                        | Impact                                                                                                                                                                                                                                                                                                                                                                                                     | Reason                                                                                                                                                                    |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Support for `imageUrl` attribute in connection invitation and connection request                                                                               | Properties that are not recognized should be ignored, meaning this shouldn't limit interoperability between agents. As the image url is self-attested it could give a false sense of trust. Better, credential based, method for visually identifying an entity are not present yet.                                                                                                                       | Even though not documented, almost all agents support this feature. Not including this feature means Credo is lacking in features in comparison to other implementations. |
+| Revocation Notification v1 uses a different `thread_id` format ( `indy::<revocation_registry_id>::<credential_revocation_id>`) than specified in the Aries RFC | Any agents adhering to the [revocation notification v1 RFC](https://github.com/hyperledger/aries-rfcs/tree/main/features/0183-revocation-notification) will not be interoperable with Credo. However, revocation notification is considered an optional portion of revocation, therefore this will not break core revocation behavior. Ideally agents should use and implement revocation notification v2. | Actual implementations (ACA-Py) of revocation notification v1 so far have implemented this different format, so this format change was made to remain interoperable.      |

guides/features/credentials.md

@@ -0,0 +1,25 @@
+# Verifiable Credentials
+
+One of the main features of Credo is the issuance and verification of Verifiable Credentials.
+
+## W3C Verifiable Credentials
+
+[W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) are probably the most widely known credential format, and defined the World Wide Web Consortium (W3C).
+
+Credo currently supports the issuance and verification of W3C Verifiable Credentials according to the **Data Model v1.1**, and support both the **Linked Data Proof** and **Json Web Token (JWT)** proof formats.
+
+**Issuance of W3C JWT credentials is not supported over DIDComm**, while verification **is supported**
+
+## SD-JWT VC
+
+Selective Disclosure JWT Verifiable Credentials are a special type of JWT Verifiable Credentials, that allow for selective disclosure of the claims in the credential.
+
+Credo currently supports [SD-JWT-based Verifiable Credentials (SD-JWT VC) - Draft 01](https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html).
+
+**Issuance of SD-JWT credentials is not supported over DIDComm**, while verification **is supported**.
+
+## AnonCreds
+
+Credo supports the issuance and verification of [AnonCreds](https://hyperledger.github.io/anoncreds-spec/) credentials. AnonCreds credentials are a bit 'heavier' to implement and support than other credential formats, but allow for the best unlinkability.
+
+Issuance and verification of AnonCreds credentials is **only available over DIDComm**.

guides/features/dids.md

@@ -0,0 +1,21 @@
+# Decentralized Identifiers
+
+[Decentralized identifiers](https://www.w3.org/TR/did-core/) are a core components of Credo, and used everywhere in the framework.
+
+The base DID implementation allows all components within the framework (whether it be credential signing, sending messages over DIDComm, or verifying a SIOPv2 ID Token) to leverage DIDs. The pluggable DID Resolver and DID Registrar interfaces allow for easy extension of the supported DID methods.
+
+In addition, any DID can be imported into the framework, meaning it can be used for signing of credentials and DIDComm, without needing a DID Registrar to register the DID.
+
+## Supported DID Methods
+
+Currently the following DID methods are supported by Credo:
+
+| Method      | Note                                                                                                         |
+| ----------- | ------------------------------------------------------------------------------------------------------------ |
+| `did:key`   |                                                                                                              |
+| `did:jwk`   |                                                                                                              |
+| `did:peer`  | Not supported for OpenID4VC                                                                                  |
+| `did:web`   | No registrar available, but you can use the `DidDocumentBuilder` to build and later import the DID Document. |
+| `did:cheqd` | Available through the `@credo-ts/cheqd` package.                                                             |
+| `did:indy`  | Available through the `@credo-ts/indy-vdr` package.                                                          |
+| `did:sov`   | Available through the `@credo-ts/indy-vdr` package.                                                          |

guides/features/index.md

@@ -0,0 +1,7 @@
+import DocCardList from '@theme/DocCardList';
+
+# Supported Features
+
+This section tries to list all the standards and features that are supported by Credo.
+
+<DocCardList />