Skip to content

fix: pipeline #334

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.

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

Merged
merged 1 commit into from
Dec 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
14 changes: 7 additions & 7 deletions docs/concepts/01_what_is_kilt.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,10 +7,10 @@ KILT is a protocol for self-sovereign data and interoperability built on top of

The core component of KILT is a digital identity protocol for:

1. Generating and managing [**decentralized identifiers (DIDs)**](./10_glossary.md#Decentralized-Identifiers-(DID))
2. Issuing and presenting digital [**verifiable credentials (VCs)**](./10_glossary.md#verifiable-credentials).
1. Generating and managing [**decentralized identifiers (DIDs)**](./10_glossary.md)
2. Issuing and presenting digital [**verifiable credentials (VCs)**](./10_glossary.md).

In contrast to other centralized alternatives, KILT features self-sovereign data and revocable [credentials](./10_glossary.md#credential) anchored to the KILT blockchain.
In contrast to other centralized alternatives, KILT features self-sovereign data and revocable [credentials](./10_glossary.md) anchored to the KILT blockchain.

KILT was built to be a business enabler, not only for the software industry but also for any entity.
Such entities can establish a business model based on the trust infrastructure KILT provides, which is an essential building block of Web 3.0.
Expand All @@ -19,9 +19,9 @@ Such entities can establish a business model based on the trust infrastructure K

In particular, KILT provides:

* A **universal identity protocol** for individuals, organizations, objects, and intelligent agents to obtain credentials for arbitrary attributes about themselves issued by trusted [Attesters](./10_glossary.md#attester).
* A **universal identity protocol** for individuals, organizations, objects, and intelligent agents to obtain credentials for arbitrary attributes about themselves issued by trusted [Attesters](./10_glossary.md).
* A **self-sovereign mechanism** for putting credential holders in control of their own data, allowing them to choose if and where they make their credentials public and how much information from those credentials they wish to share.
* A **[Trust Market](./10_glossary.md#trust-market) for [Attesters](./10_glossary.md#attester)** of such credentials, allowing widely trusted entities to be compensated for their valuable attestation work.
* A **[Trust Market](./10_glossary.md) for [Attesters](./10_glossary.md)** of such credentials, allowing widely trusted entities to be compensated for their valuable attestation work.

KILT's main goal is to generate a level playing field for companies to explore new business models related to trust relationships and data sovereignty.
KILT enables businesses and governments to rely on a common standard owned by everyone participating and not by a single company or set thereof.
Expand Down Expand Up @@ -56,13 +56,13 @@ KILT Protocol aims to change that and give users back control over their data.

## The solution

KILT provides a protocol and the tools for people to manage their own data, and to build a [digital identity](./10_glossary.md#digital-identity) by collecting credentials issued by trusted entities.
KILT provides a protocol and the tools for people to manage their own data, and to build a [digital identity](./10_glossary.md) by collecting credentials issued by trusted entities.
Such credentials aren't publicly available but stay within the user's control.
This is similar to the approach used for centuries before big corporations monetized our data.

The core ideas are:

* Managing user identities in the form of [decentralized identifiers (DIDs)](https://w3c-ccg.github.io/did-spec/), with the support of the KILT blockchain
* Obtaining digital [verifiable credentials](./10_glossary.md#verifiable-credentials) for user-specified claims
* Obtaining digital [verifiable credentials](./10_glossary.md) for user-specified claims
* Supporting revocation of verifiable credentials by their Attesters
* Presenting and verifying verifiable credentials in a privacy-preserving and user-controlled way
4 changes: 2 additions & 2 deletions docs/concepts/07_dip/05_dapp_developer.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,7 @@ 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.
- `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 @@ -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
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@ Verifying a public credential is shown in the following snippet:
What the `verifyCredential` function does internally is the following:

1. Derive the credential identifier from the provided content and attester information.
2. Fetch the actual credential from the blockchain, as shown in the [section above](#retrieve-a-credential-by-id), failing if the credential does not exist.
2. Fetch the actual credential from the blockchain, as shown in the [section above](#retrieve-a-credential-by-its-identifier), failing if the credential does not exist.
3. [OPTIONAL] Verify that the credential structure matches what the optionally-provided CType defines.
4. Verify that the rest of the fields in the provided credential (i.e., revocation status, identifier, creation block number) match the retrieved credential.

Expand All @@ -65,4 +65,4 @@ Rather, the block number in which the extrinsic is submitted is stored inside th
This represents a very good tradeoff between **security** - because the blockchain itself dictates what the creation block number is for any given public credential - and **storage efficiency** - since the full credential is stored off-chain, accessible via any KILT archive node or indexing service.
:::

[asset-did-concept]: ../../../../concepts/04_asset_dids.md
[asset-did-concept]: ../../../../concepts/04_asset_dids.md
4 changes: 2 additions & 2 deletions docs/develop/01_sdk/03_chain_setup/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,12 +13,12 @@ This gives developers like you the chance to test your software with any new fea
Nevertheless, there are a scenarios where a public network (that everyone else is also using) is not ideal.
For instance, if you need more funds than the faucet can provide, or if you need to reset the state of the blockchain at any time, you will need to setup your own little KILT blockchain.

In this section, we will guide you through the process of
In this section, we will guide you through the process of
1. [Running your own KILT blockchain](./01_standalone_setup.md)
2. [Connecting to the Peregrine test network](./02_peregrine_setup.md)
3. [Connecting to the Spiritnet production network](./03_prod_chain_setup.md)

## Set up your Project

We expect you to already have a small project which can connect and potentially interact with a KILT blockchain given the WebSocket address of a KILT node.
If that is not the case, please take a look at our [Quickstart section](../01_quickstart.md#connecting-to-kilt-blockchain) which will provide you with all necessary means to create and run a basic script.
If that is not the case, please take a look at our [Quickstart section](../01_quickstart.md) which will provide you with all necessary means to create and run a basic script.
2 changes: 1 addition & 1 deletion docs/participate/01_staking/03_delegate/02_become.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ If the delegation pool of your chosen collator candidate is full, you may still
When that happens,

- The kicked delegator will be replaced by the delegator with a higher delegation (you) immediately
- The kicked delegator's stake is prepared for unstaking as if they revoked the delegation (*see [revoking](#Revoking)*)
- The kicked delegator's stake is prepared for unstaking as if they revoked the delegation
- A delegator needs to wait 7 days (in block time) to be able to unlock the stake.
Please note that it can take longer in real time as the block times assumes a constant block time of 12s, which is not guaranteed.

Expand Down
29 changes: 0 additions & 29 deletions docusaurus.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -287,34 +287,5 @@ module.exports = {
},
},
],
[
'docusaurus-plugin-remote-content',
{
// Pulls external files and adds them as files in the Docusaurus folder, rewriting the title and the file name
name: 'switch-pallet',
sourceBaseUrl:
'https://raw.githubusercontent.com/KILTprotocol/kilt-node/refs/heads/master/pallets/pallet-asset-switch/',
outDir: 'docs/develop/09_polarpath',
documents: ['README.md'],
modifyContent(filename, content) {
if (filename.includes('README')) {
const regex = /\.\/[^\/]+\/[^\/]+\/([^\/]+\/mod\.rs)/g
var trimContent = content.replaceAll(
regex,
'https://raw.githubusercontent.com/KILTprotocol/kilt-node/refs/heads/master/pallets/pallet-asset-switch/src/xcm/$1'
)
var trimContent2 = trimContent.replace(
'../../runtime-api/asset-switch/',
'https://github.com/KILTprotocol/kilt-node/tree/master/runtime-api/asset-switch'
)
return {
filename: '02_switch_pallet.md',
content: trimContent2,
}
}
return undefined
},
},
],
],
}
Loading