feat(devx): Edit Developer > Stardust docs (#2063)

* feat(devx): edit stardust docs * feat(devx): archive stardust doc stubs * feat(devx): archive stardust doc stubs * feat(devx): add warning * fix(devx): fix sidebar after merge * feat(devx): change tabs groupId from code-language to language * Update docs/content/developer/stardust/claiming/self-sponsor.mdx Co-authored-by: Dr-Electron <[email protected]> --------- Co-authored-by: Dr-Electron <[email protected]>
iotaledger · Sep 3, 2024 · a9e2da8 · a9e2da8
1 parent 71713cb
commit a9e2da8
Show file tree

Hide file tree

Showing 22 changed files with 426 additions and 264 deletions.
diff --git a/docs/content/_snippets/migration-warning.mdx b/docs/content/_snippets/migration-warning.mdx
@@ -0,0 +1,5 @@
+:::warning Exchanges and dApp Devs Only
+
+The migration documentation describes the processes needed to claim and migrate output types manually; However, for the average user, this knowledge is not needed and is abstracted in the wallet web application (dashboard). The specific migration knowledge described here is unnecessary for people using a regular wallet.
+
+:::
diff --git a/docs/content/developer/iota-101/objects/transfers/transfer-to-object.mdx b/docs/content/developer/iota-101/objects/transfers/transfer-to-object.mdx
@@ -147,7 +147,7 @@ You can combine these restrictions to create complex rules, such as implementing
 
 When creating transactions, you interact with `Receiving` transaction inputs in a similar way to other object arguments in the IOTA TypeScript SDK. For example, if you want to receive a coin object with ID `0xc0ffee` that was sent to your account at `0xcafe`, you can do the following:
 
-<Tabs groupId="code-language">
+<Tabs groupId="language">
 
 <TabItem label="TypeScript" value="typescript">
 

diff --git a/docs/content/developer/iota-101/transactions/sign-and-send-txn.mdx b/docs/content/developer/iota-101/transactions/sign-and-send-txn.mdx
@@ -36,9 +36,9 @@ If you want to use a specific gas coin, first find the gas coin object ID to be
 
 The following examples demonstrate how to sign and execute transactions using Rust, TypeScript, or the IOTA CLI.
 
-<Tabs groupId="code-language">
+<Tabs groupId="language">
 
-<TabItem value="ts-sdk" label="TypeScript">
+<TabItem value="typescript"  label="TypeScript">
 
 There are various ways to instantiate a key pair and to derive its public key and IOTA address using the [IOTA TypeScript SDK](../../../references/ts-sdk/typescript/index.mdx#iota-typescript-sdk).
 

diff --git a/docs/content/developer/stardust/advanced.mdx → .../content/developer/stardust/_advanced.mdx b/docs/content/developer/stardust/advanced.mdx → .../content/developer/stardust/_advanced.mdx
diff --git a/docs/content/developer/stardust/faq.mdx → docs/content/developer/stardust/_faq.mdx b/docs/content/developer/stardust/faq.mdx → docs/content/developer/stardust/_faq.mdx
diff --git a/docs/content/developer/stardust/if-tools.mdx → .../content/developer/stardust/_if-tools.mdx b/docs/content/developer/stardust/if-tools.mdx → .../content/developer/stardust/_if-tools.mdx
diff --git a/docs/content/developer/stardust/testing.mdx → docs/content/developer/stardust/_testing.mdx b/docs/content/developer/stardust/testing.mdx → docs/content/developer/stardust/_testing.mdx
diff --git a/docs/content/developer/stardust/vested.mdx → docs/content/developer/stardust/_vested.mdx b/docs/content/developer/stardust/vested.mdx → docs/content/developer/stardust/_vested.mdx
diff --git a/docs/content/developer/stardust/addresses.mdx b/docs/content/developer/stardust/addresses.mdx
@@ -2,6 +2,9 @@
 title: Addresses and Keys
 description: Explains how "previous" addresses are treated in the new ledger
 ---
+import MigrationWarning from '../../_snippets/migration-warning.mdx';
+
+<MigrationWarning/ >
 
 ## Addresses
 

diff --git a/docs/content/developer/stardust/claiming.mdx b/docs/content/developer/stardust/claiming.mdx
@@ -1,21 +1,28 @@
 ---
-title: Claiming Stardust Assets
-description: Describes how to access the migrated assets and tokens
+description: How to access the migrated Stardust assets and tokens 
 ---
+import MigrationWarning from '../../_snippets/migration-warning.mdx';
 
-As detailed in the [Stardust Move Models](move-models.mdx), Stardust assets are represented as Move objects within the ledger. Claiming these assets involves enabling original owners to utilize a [Programmable Transaction Block](../iota-101/transactions/ptb/prog-txn-blocks.mdx) to "unlock" assets such as IOTA, Shimmer, custom [`Coin`](../../references/framework/iota-framework/coin.mdx#resource-coin)s, or even `Alias` and `Nft` objects. 
+# Claiming Stardust Assets
 
-This process takes advantage of Move's unique features to ensure that assets are transferred and unlocked securely and efficiently to their rightful owners.
+<MigrationWarning/ >
 
+As detailed in the [Stardust Move Models](move-models.mdx), Stardust assets are represented as Move objects within the ledger. Claiming these assets involves enabling original owners to utilize a [Programmable Transaction Block](../iota-101/transactions/ptb/prog-txn-blocks.mdx) to "unlock" assets such as IOTA, Shimmer, custom [`Coin`](../../references/framework/iota-framework/coin.mdx#resource-coin)s, or even `Alias` and `Nft` objects.
 
-## Output types to Move Objects
+This process takes advantage of Move's unique features to ensure that assets are transferred and unlocked securely and efficiently to their rightful owners.
 
-Stardust assets come in the form of Outputs and each Output can be of a different type. For understanding how Outputs have been transformed into Move Objects based on their types, please refer to the [Stardust Move Models](move-models.mdx#summary) page. In here, one or more claiming examples for each Output type will be shown.
+## Output Types to Move Objects
 
+Stardust assets come in the form of Outputs, and each Output can be of a different type. 
+To understand how Outputs have been transformed into Move Objects based on their types,
+please refer to the [Stardust Move Models](move-models.mdx#summary) page.
+Below, you will find one or more examples of claiming each Output type.
 
-## Examples of Stardust asset claim transactions
+## Examples of Stardust Asset Claim Transactions
 
-In the following, some examples of transactions for claiming the Stardust assets will be presented. Different commands in a [PTB](../iota-101/transactions/ptb/prog-txn-blocks.mdx) are used depending on the claiming scenario, that varies depending on the Stardust Output type and composition.
+Here are some examples of transactions for claiming Stardust assets.
+Different commands in a [PTB](../iota-101/transactions/ptb/prog-txn-blocks.mdx) are used depending on the claiming scenario,
+which varies based on the Stardust Output type and composition.
 
 ### Basic Output
 
@@ -33,12 +40,14 @@ Go to [Alias Output](claiming/alias.mdx).
 
 Go to [Foundry Output](claiming/foundry.mdx).
 
-### Output unlockable by an Alias/Nft Address
+### Output Unlockable by an Alias/Nft Address
 
-Go to [Output unlockable by an Alias/Nft Address](claiming/address-unlock-condition.mdx).
+Go to [Output Unlockable by an Alias/Nft Address](claiming/address-unlock-condition.mdx).
 
-## Sponsoring your Shimmer claiming
+## Sponsoring Your Shimmer Claiming
 
-In the case in which some assets are owned by a Shimmer address that helds no IOTA tokens (needed to pay for gas), then a claiming can benefit by the process of self-sponsoring. This means that an address owning IOTA tokens can be used by the same user to sponsor a transaction claiming Shimmer assets. 
+If some assets are owned by a Shimmer address that holds no IOTA tokens (needed to pay for gas),
+the claiming process can benefit from self-sponsorship.
+This means that an address owning IOTA tokens can be used by the same user to sponsor a transaction claiming Shimmer assets.
 
-Go to [Self-sponsor Shimmer Claimings](claiming/self-sponsor.mdx).
+Go to [Self-sponsor Shimmer Claims](claiming/self-sponsor.mdx).
diff --git a/docs/content/developer/stardust/claiming/address-unlock-condition.mdx b/docs/content/developer/stardust/claiming/address-unlock-condition.mdx
@@ -1,66 +1,76 @@
 ---
- title: Claiming an Output unlockable by an Alias/Nft Address
+description: A guide on how to claim Outputs Unlockable by an Alias/NFT Address in the Move-based IOTA ledger.
 ---
+import MigrationWarning from '../../../_snippets/migration-warning.mdx';
 
-In Stardust outputs presented an Address Unlock Condition or similarly, in the case of the Alias Output, a [Governor Address Unlock Condition](https://github.com/iotaledger/tips/blob/main/tips/TIP-0018/tip-0018.md#governor-address-unlock-condition). In the new ledger, this mechanism is represented as an address owning the associated Output object. Most of the times the address is directly managed through a keypair by a user, but sometimes this address could represent another object. In this case, that object owns the interested Output object. Coming from the [Stardust migration](../migration-process.mdx#stardust-migration), only `Alias` and `Nft` objects can own other Output objects.       
+# Claiming an Output Unlockable by an Alias/NFT Address
 
-## Claim of an Output owned by another Alias/Nft object
+<MigrationWarning/ >
 
-For this example, we're using an `AliasOutput` to extract an `Alias` object that owns an `NftOutput`.
+In Stardust, outputs had an Address Unlock Condition or, in the case of Alias Outputs, 
+a [Governor Address Unlock Condition](https://github.com/iotaledger/tips/blob/main/tips/TIP-0018/tip-0018.md#governor-address-unlock-condition). 
+In the new ledger, this mechanism is represented by an address owning the associated Output object.
+Most of the time, the address is directly managed by a user through a keypair.
+However, sometimes the address could represent another object. 
+In this case, that object owns the associated Output object.
+After the [Stardust migration](../migration-process.mdx), only `Alias` and `Nft` objects can own other Output objects.
 
-1. The first step is to fetch the `AliasOutput` object that is needed for claiming the `NftOutput`.
+## Claiming an Output Owned by Another Alias/NFT Object
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+For this example, we use an `AliasOutput` to extract an `Alias` object that owns an `NftOutput`.
+
+1. The first step is to fetch the `AliasOutput` object that is needed to claim the `NftOutput`.
+
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/address-unlock-condition.rs#L70-L88
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript"  label="TypeScript">
 
 </TabItem>
 </Tabs>
 
-2. By using the dynamic field function with the "alias" dynamic field key filter, we gather the `Alias` object itself.
+2. Use the dynamic field function with the "alias" dynamic field key filter to gather the `Alias` object itself.
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/address-unlock-condition.rs#L90-L103
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript"  label="TypeScript">
 
 </TabItem>
 </Tabs>
 
-3. Some objects are owned by the `Alias` object. In this case we filter them by type using the `NftOutput` type tag.
-Applying the filter to get `NftOutput`s owned by the `Alias`.
+3. Some objects are owned by the `Alias` object. In this case, filter them by type using the `NftOutput` type tag. Apply the filter to get `NftOutput`s owned by the `Alias`.
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/address-unlock-condition.rs#L105-L128
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript"  label="TypeScript">
 
 </TabItem>
 </Tabs>
 
-4. Create PTB that firstly extracts the assets from the `AliasOutput` and then it uses the extracted `Alias` to "address unlock" the `NftOutput` using the funсtion `unlock_alias_address_owned_nft`.
+4. Create a PTB that first extracts the assets from the `AliasOutput`, and then uses the extracted `Alias` to "address unlock" the `NftOutput` using the function `unlock_alias_address_owned_nft`.
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/address-unlock-condition.rs#L130-L239
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript"  label="TypeScript">
 
 </TabItem>
-</Tabs>
+</Tabs>
diff --git a/docs/content/developer/stardust/claiming/alias.mdx b/docs/content/developer/stardust/claiming/alias.mdx
@@ -1,75 +1,93 @@
 ---
- title: Claiming Alias Outputs
+description: A guide on how to claim Alias Outputs in the Move-based IOTA ledger.
 ---
 
-An address can own `AliasOutput` objects only if before the migration it was set as the Alias Governor Address. 
-In this case, the `AliasOutput` object is an owned object in the ledger and its owner is the Governor address.
-Such address can be directly controlled by a user or by another object (either an `Alias` or `Nft` object). For the latter use case, check the [`Claiming an Output unlockable by an Alias/Nft Address`](address-unlock-condition.mdx) example.
+import MigrationWarning from '../../../_snippets/migration-warning.mdx';
 
-## Claim of an Alias Output
+# Claiming Alias Outputs
+
+<MigrationWarning/ >
+
+An address can own `AliasOutput` objects only if it was set as the Alias Governor Address before the migration. 
+In this case, the `AliasOutput` object is an owned object in the ledger, and its owner is the Governor address.
+This address can be directly controlled by a user or by another object (either an `Alias` or `Nft` object).
+For the latter use case,
+check the [`Claiming an Output Unlockable by an Alias/Nft Address`](address-unlock-condition.mdx) example.
+
+## Claim an Alias Output
 
 A Governor address can claim the `AliasOutput` assets at any time:
 
-1. The first step is to fetch an `AliasOutput` object needed to be claimed.
+### 1. Fetch the `AliasOutput`
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+The first step is to fetch the `AliasOutput` object that needs to be claimed.
+
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/alias-output-claim.rs#L56-L81
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript" label="TypeScript">
+
+Coming soon
 
 </TabItem>
 </Tabs>
 
+### 2. Check the Native Token Balance
 
-2. Then we check the native tokens that were possibly held by this output.
-A [`Bag`](../../../references/framework/iota-framework/bag) is used for holding these tokens, so in this step we are interested in obtaining the dynamic field keys that are bag indexes.
-In the case of the native tokens, the keys are strings representing the [`OTW`](../../iota-101/move-overview/one-time-witness.mdx) used for the native token declaration.
+Next, check the native tokens that might be held by this output. A [`Bag`](../../../references/framework/iota-framework/bag.mdx) is used for holding these tokens. In this step, we are interested in obtaining the dynamic field keys that are bag indexes. For native tokens, the keys are strings representing the [`OTW`](../../iota-101/iota-move-concepts/one-time-witness.mdx) used for the native token declaration.
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/alias-output-claim.rs#L83-L110
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript" label="TypeScript">
+
+Coming soon
 
 </TabItem>
 </Tabs>
 
-3. Finally, a PTB can be created using the `alias_output_object_ref` as input and the native token keys.
-An `AliasOutput` is different from an `NftOutput` or a `BasicOutput` as it contains the `Alias` object.
-In fact, the main purpose of claiming is extracting the `Alias` object from the `AliasOutput`.
+### 3. Create the PTB
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+Finally, create a [Programmable Transaction Block (PTB)](../../iota-101/transactions/ptb/building-ptb.mdx) 
+using the `alias_output_object_ref` as input along with the native token keys. 
+An `AliasOutput` differs from an `NftOutput` or a `BasicOutput` because it contains the `Alias` object.
+The main purpose of claiming is to extract the `Alias` object from the `AliasOutput`.
+
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/alias-output-claim.rs#L112-L180
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript" label="TypeScript">
 
 </TabItem>
 </Tabs>
 
-## Conversion of an Alias Output into a custom Object
+## Convert an Alias Output into a Custom Object
 
-We need to have a custom package prepared that contains a logic for converting an `Alias` into a new entity usable for your project. 
+To convert an `Alias` into a new entity usable for your project, 
+you need to have a custom package prepared with the necessary logic.
 
-In Stardust, an alias can be used for different purposes. One of them is acting as an NFT collection controller.
-In the following, an example of the process of converting a Stardust `Alias` into a `CollectionControllerCap` is outlined.
+In Stardust, an alias can serve various purposes, such as acting as an NFT collection controller.
+The following example outlines the process of converting a Stardust `Alias` into a `CollectionControllerCap`.
 
-The following example extends the one described in the [Conversion of an Nft Output into a custom Nft](nft.mdx#conversion-of-an-nft-output-into-a-custom-nft) documentation:
+This example extends the one described in the [Conversion of an Nft Output into a Custom Nft](nft.mdx#converting-an-nft-output-into-a-custom-nft) documentation:
 
-<Tabs>
+<Tabs groupId="language">
 <TabItem value="move" label="Move">
 
-The `collection.move` module extends the `custom_nft` package to make it possible to work with NFT collections:
+The `collection.move` module extends the `custom_nft` package to enable working with NFT collections:
 
 ```move file=<rootDir>/docs/examples/move/custom_nft/sources/collection.move
 ```
@@ -83,18 +101,16 @@ Also, the `nft.move` module was extended with the following function:
 
 </Tabs>
 
-Once the package is prepared, we can extract and use a Stardust `Alias` in a single transaction to create a `CollectionControllerCap`.
-This capability is then used in later transactions for managing new collections.
+Once the package is prepared, you can extract and use a Stardust `Alias` in a single transaction to create a `CollectionControllerCap`. This capability is then used in later transactions to manage new collections.
 
-<Tabs>
-<TabItem value="rs" label="Rust">
+<Tabs groupId="language">
+<TabItem value="rust" label="Rust">
 
 ```rust file=<rootDir>/docs/examples/rust/stardust/alias-migration.rs#L119-L244
 ```
 
 </TabItem>
-<TabItem value="ts" label="TypeScript">
+<TabItem value="typescript" label="TypeScript">
 
 </TabItem>
 </Tabs>
-