Skip to content

SDK v1 #342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

SDK v1 #342

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8b6f940
feat: new version
Dudleyneedham May 13, 2025
267504e
feat: updating the docs structure (#343)
Dudleyneedham May 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/concepts/02_did.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ KILT thus rejects light DID signatures even if the original claim in the credent

:::tip

For a detailed developer-oriented guide to KILT DIDs, read the [DID Cookbook section](../develop/01_sdk/02_cookbook/01_dids/01_light_did_creation.md).
<!-- For a detailed developer-oriented guide to KILT DIDs, read the [DID Cookbook section](../develop/01_sdk/02_cookbook/01_dids/01_light_did_creation.md). -->

:::

Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/03_web3names.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ For example, showing the web3name of a collator's account on the [KILT Stakeboar
}}
/>

For a detailed developer-oriented guide to web3names and account linking, read the [web3name Cookbook section](../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) and the [account linking Cookbook section](../develop/01_sdk/02_cookbook/03_account_linking/01_link.md).
<!-- For a detailed developer-oriented guide to web3names and account linking, read the [web3name Cookbook section](../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) and the [account linking Cookbook section](../develop/01_sdk/02_cookbook/03_account_linking/01_link.md). -->

## KILT DIDs vs. KILT accounts

Expand Down
4 changes: 2 additions & 2 deletions docs/concepts/05_credentials/02_ctypes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ Currently, it costs 0.001 KILT to create a CType on the KILT blockchain.

:::

For a detailed developer-oriented guide to KILT CTypes, read the [CType Cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/01_ctype_creation.md).
<!-- For a detailed developer-oriented guide to KILT CTypes, read the [CType Cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/01_ctype_creation.md). -->

[kilt-runtime-1.9.0]: https://github.com/KILTprotocol/kilt-node/releases/tag/1.9.0

Expand Down Expand Up @@ -124,7 +124,7 @@ const newCType = CType.fromProperties(oldCType.title, oldCType.properties, 'V1')
```

The new CType has the same title and properties as the existing one, but be based on the new metaschema, resulting in a different hash and id.
After [registering the new CType on the KILT blockchain](../../develop/01_sdk/02_cookbook/04_claiming/01_ctype_creation.md), you can use the new CType as a drop-in replacement in issuing credentials.
<!-- After [registering the new CType on the KILT blockchain](../../develop/01_sdk/02_cookbook/04_claiming/01_ctype_creation.md), you can use the new CType as a drop-in replacement in issuing credentials. -->

Verifiers depending on these CTypes should accept both the old and new CType during a transition period.
Test thoroughly to ensure the correct behavior and functionality of the new CTypes in your application.
Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/05_credentials/03_claiming.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,6 @@ The to-be-attested `Credential` contains the original claim, data needed for fut

:::info

For a detailed developer-oriented guide to KILT claims, read the [Claim Cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/02_attestation_request.md).
<!-- For a detailed developer-oriented guide to KILT claims, read the [Claim Cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/02_attestation_request.md). -->

:::
4 changes: 2 additions & 2 deletions docs/concepts/05_credentials/04_attestation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ After the credential has been attested, the Claimer can store it in their wallet

:::info

For a detailed developer-oriented guide to KILT attestations, read the [Attestation cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/03_attestation_creation.md).
<!-- For a detailed developer-oriented guide to KILT attestations, read the [Attestation cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/03_attestation_creation.md). -->

:::

Expand All @@ -25,4 +25,4 @@ Storing a attestation in the blockchain requires providing a constant deposit, w
The deposit serves as a security measure to ensure the integrity of the blockchain and incentivize users to manage their attestation responsibly.
By requiring a deposit, it discourages spamming or unnecessary creation of attestation.
The attester can reclaim the deposit by deleting their attestation.
Revoking them isn't sufficient as the deposit still shows in chain storage, but marked as invalid.
Revoking them isn't sufficient as the deposit still shows in chain storage, but marked as invalid.
4 changes: 2 additions & 2 deletions docs/concepts/05_credentials/05_verification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,7 +74,7 @@ This increases the privacy of the Claimer since they only need to show attribute

:::info

For a detailed developer-oriented guide to KILT presentation creation, read the [presentation creation cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/04_presentation_creation.md).
<!-- For a detailed developer-oriented guide to KILT presentation creation, read the [presentation creation cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/04_presentation_creation.md). -->

:::

Expand Down Expand Up @@ -107,7 +107,7 @@ Therefore, the Verifier has to check if the CType matches one of the requested C

:::info

For a detailed developer-oriented guide to KILT credential verification, read the [verification cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/05_presentation_verification.md).
<!-- For a detailed developer-oriented guide to KILT credential verification, read the [verification cookbook section](../../develop/01_sdk/02_cookbook/04_claiming/05_presentation_verification.md). -->

:::

8 changes: 4 additions & 4 deletions docs/concepts/07_dip/05_dapp_developer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,8 +51,8 @@ For example, `did:kilt:4q4QzFTs9hKh4QizLB3B7zuGYCG3QPamiBFEgwM6gTM7gK3g`
Currently only supports version 1.
- `blockNumber`: The block number of the relay chain to use for the generation of the DIP proof.
If not provided, uses the last finalized block.
- `linkedAccounts`: An array of [account addresses linked to the DID](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md#linking-an-account-to-a-did) to reveal in the generated proof.
- `web3Name`: Whether to reveal [the web3name of the DID subject](../../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) in the generated proof.
<!-- - `linkedAccounts`: An array of [account addresses linked to the DID](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md#linking-an-account-to-a-did) to reveal in the generated proof. -->
<!-- - `web3Name`: Whether to reveal [the web3name of the DID subject](../../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) in the generated proof. -->

In the example code, the configuration also has extra parameters for the time-bound DID signature extension [mentioned below](#creating-extensions-for-specific-proofs).

Expand Down Expand Up @@ -96,7 +96,7 @@ The method returns the different components of the proof, [which you can see in
- The commitment proof, which proves the DIP commitment for the subject of the action, which is the DID URI.
- The DID proof, which reveals parts of the DID document as specified by key IDs, proof version, and whether to include the web3name and any of its linked accounts.

Behind the scenes, the method uses the `dispatchAs` method ([and corresponding chain method](https://github.com/KILTprotocol/kilt-node/blob/4ddb8a0ef6258873458f19d3ee9dcb6d7c24e645/pallets/did/src/lib.rs#L1152)) to pass the extrinsic following the consumer's type registry.
<!-- Behind the scenes, the method uses the `dispatchAs` method ([and corresponding chain method](https://github.com/KILTprotocol/kilt-node/blob/4ddb8a0ef6258873458f19d3ee9dcb6d7c24e645/pallets/did/src/lib.rs#L1152)) to pass the extrinsic following the consumer's type registry. -->
You can now sign and submit to the consumer chain.

```typescript
Expand All @@ -108,7 +108,7 @@ await signAndSubmitTx(consumerApi, dipSubmittable, submitterKeypair)
Linked accounts let you specify which accounts you want to prove that you control when you make the cross-chain proof.
As part of the proof provided, you can also include other values, such as the web3name.

For all the accounts you want to link, use the `associateAccountToChainArgs` method, [as detailed in this guide](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md#linking-an-account-to-a-did).
<!-- For all the accounts you want to link, use the `associateAccountToChainArgs` method, [as detailed in this guide](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md#linking-an-account-to-a-did). -->

You can then batch all the linked account transactions and authorize them using the `authorizeTx` method.

Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/08_messaging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,5 +40,5 @@ Therefore, this scheme still works if a DID should expose multiple encryption ke

:::caution
While no one can read or change what's inside an encrypted message even if they intercept it while traveling on the network, a sophisticated attacker may try to guess what's inside and trick either side of the channel by resubmitting a copy of that message later.
For a detailed developer-oriented guide about how to protect against *replay attacks*, read the [Replay Protection Cookbook section](../develop/01_sdk/02_cookbook/06_messaging/02_replay_protection.md).
<!-- For a detailed developer-oriented guide about how to protect against *replay attacks*, read the [Replay Protection Cookbook section](../develop/01_sdk/02_cookbook/06_messaging/02_replay_protection.md). -->
:::
227 changes: 0 additions & 227 deletions docs/develop/01_sdk/01_quickstart.md
View file
Open in desktop

This file was deleted.

Loading
Loading