From ff3a2a566236e1fef57e09d28db0c8e888f7ac0d Mon Sep 17 00:00:00 2001 From: Anton Astafiev Date: Thu, 30 Jan 2025 17:27:15 +0100 Subject: [PATCH] Fix documentation for Chain Signatures (#2451) * Fix broken anchor link * Fix the tip to correctly reflect the content * Add links to the deployed contracts * Remove duplicate "public" * Remove broken link (deleted in PR #2416) * Fix a few broken anchors and links * Fix broken anchors in NFT tutorials * Fix more broken anchors * More broken links * Fix broken links to old indexer framework * Update index.js * Update 2024-07-01.md --- blog/2024-04-24.md | 2 +- blog/2024-07-01.md | 2 +- blog/2024-08-13.md | 2 +- .../abstraction/chain-signatures.md | 2 +- docs/1.concepts/abstraction/meta-tx.md | 4 ++-- .../chain-signatures/chain-signatures.md | 8 ++++--- .../5.primitives/ft/bos/check-balance.md | 4 ++-- .../5.primitives/ft/web-app/check-balance.md | 4 ++-- docs/2.build/5.primitives/oracles.md | 4 ++-- .../building-indexers/nft-indexer.md | 4 ++-- .../building-indexers/python-nft-indexer.md | 4 ++-- .../migrating-to-near-lake-framework.md | 12 +++++----- .../near-lake-state-changes-indexer.md | 4 ++-- .../lake-framework/near-lake.md | 4 ++-- .../running-near-lake/lake-start-options.md | 6 ++--- docs/3.tutorials/examples/advanced-xcc.md | 2 +- docs/3.tutorials/fts/1-skeleton.md | 2 +- docs/3.tutorials/fts/5.transfers.md | 2 +- docs/3.tutorials/nfts/1-skeleton.md | 2 +- docs/3.tutorials/nfts/2-minting.md | 2 +- docs/3.tutorials/nfts/5-approval.md | 12 +++++----- docs/3.tutorials/nfts/7-events.md | 2 +- docs/3.tutorials/nfts/js/5-approval.md | 8 +++---- docs/4.tools/indexing-tools.md | 4 ++-- docs/4.tools/near-api.md | 2 +- docs/5.api/rpc/setup.md | 2 +- docs/6.integrations/create-transactions.md | 4 ++-- docs/pagoda/rpc/api.md | 22 +++++++++---------- docs/pagoda/rpc/setup.md | 2 +- docs/welcome.md | 2 +- website/src/theme/Footer/index.js | 5 ----- 31 files changed, 69 insertions(+), 72 deletions(-) diff --git a/blog/2024-04-24.md b/blog/2024-04-24.md index e8bfebbdfac..1d32eab828d 100644 --- a/blog/2024-04-24.md +++ b/blog/2024-04-24.md @@ -15,7 +15,7 @@ hide_table_of_contents: true ## Organic growth Our documentation is the result of multiple people collaborating across the span of four very active years, and it has seen a lot of changes: [2942 commits and counting](https://github.com/near/docs/commits/master/). -In the beginning, our docs only needed to explain how to create [smart contracts](/build/smart-contracts/what-is), and how to [interact with them through a frontend](/build/web3-apps/quickstart). Fast forward to today, and we have more than 200 pages of documentation, covering topics such as [chain abstraction](/build/chain-abstraction/what-is), [on-chain components](/build/near-components/what-is), [data infrastructure](/build/data-infrastructure/what-is), and [primitives such as NFT, FT](/build/primitives/what-is). +In the beginning, our docs only needed to explain how to create [smart contracts](/build/smart-contracts/what-is), and how to [interact with them through a frontend](/build/web3-apps/quickstart). Fast forward to today, and we have more than 200 pages of documentation, covering topics such as [chain abstraction](/build/chain-abstraction/what-is), [data infrastructure](/build/data-infrastructure/what-is), and [primitives such as NFT, FT](/build/primitives/what-is). The best thing is that new features are released every single month. However, all progress comes at a cost, and as our ecosystem grew, so did the disorganization of our documentation. diff --git a/blog/2024-07-01.md b/blog/2024-07-01.md index 39d78d57515..66ad80cd988 100644 --- a/blog/2024-07-01.md +++ b/blog/2024-07-01.md @@ -76,4 +76,4 @@ If your application relies on community-contributed or unreviewed third-party co If you are not relying on any untrusted component code, then **maybe**. You are not being forced to migrate and there are still teams actively building new applications leveraging B.O.S. Additionally, there are no plans to deprecate main B.O.S. gateways at [dev.near.org](https://dev.near.org), [near.social](https://near.social), [dapdap](https://dapdap.net) or [bos.gg](https://bos.gg). However, the underlying framework and virtual machine are no longer actively developed or maintained by the original team. Consequently, the pace at which new features are introduced and existing bugs or vulnerabilities are addressed may be slower than expected. We openly welcome new maintainers for [this codebase](https://github.com/nearsocial). However, as previously mentioned, we anticipate that additional security vulnerabilities may still be discovered. -We have updated [“Frontends for Web3 dApps” in docs.near.org](https://docs.near.org/build/web3-apps/frontend) to help you choose a solution that is right for you. If you need help, please reach out to one of our support channels on [Telegram](https://t.me/neardev) or [Discord](https://near.chat) and we will be happy to assist you or answer any questions you have. +We have updated [“Frontends for Web3 dApps” in docs.near.org](https://docs.near.org/build/web3-apps/integrate-contracts) to help you choose a solution that is right for you. If you need help, please reach out to one of our support channels on [Telegram](https://t.me/neardev) or [Discord](https://near.chat) and we will be happy to assist you or answer any questions you have. diff --git a/blog/2024-08-13.md b/blog/2024-08-13.md index 85d350c9b0f..fa0a806f93c 100644 --- a/blog/2024-08-13.md +++ b/blog/2024-08-13.md @@ -15,7 +15,7 @@ As the NEAR ecosystem continues to decentralize, Pagoda will cease operations wi The critical services below will continue to be operated and maintained by Pagoda until they are smoothly transitioned to new operators in the NEAR ecosystem during the second half of 2024: - [near.org RPC](https://docs.near.org/api/rpc/providers) ([Request for Proposals](https://dev.near.org/infrastructure-committee.near/widget/app?page=rfp&id=2)) -- [NEAR Lake](https://docs.near.org/concepts/advanced/near-lake-framework) ([Request for Proposals](https://dev.near.org/infrastructure-committee.near/widget/app?page=rfp&id=3)) +- [NEAR Lake](https://docs.near.org/build/data-infrastructure/lake-framework/near-lake-framework) ([Request for Proposals](https://dev.near.org/infrastructure-committee.near/widget/app?page=rfp&id=3)) - [BigQuery Public Dataset](https://docs.near.org/build/data-infrastructure/big-query) ([Request for Proposals](https://dev.near.org/infrastructure-committee.near/widget/app?page=rfp&id=4)) - [Node Snapshots](https://near-nodes.io/intro/node-data-snapshots) - [State Sync](https://near-nodes.io/rpc/state-sync) diff --git a/docs/1.concepts/abstraction/chain-signatures.md b/docs/1.concepts/abstraction/chain-signatures.md index 9fa799b2a3f..965a270c8cd 100644 --- a/docs/1.concepts/abstraction/chain-signatures.md +++ b/docs/1.concepts/abstraction/chain-signatures.md @@ -101,7 +101,7 @@ This contract has a `sign` method that takes two parameters: For example, a user could request a signature to `send 0.1 ETH to 0x060f1...` **(transaction)** using the `ethereum-1` account **(path)**. -After a request is made, the `sign` method will [yield execution](/blog/yield-resume) waiting while the [MPC signing service](#multi-party-computation-service-mpc) signs the transaction. +After a request is made, the `sign` method will [yield execution](/blog/yield-resume) waiting while the [MPC signing service](#multi-party-computation-service) signs the transaction. Once the signature is ready, the contract resumes computation and returns it to the user. This signature is a valid signed transaction that can be readily sent to the target blockchain to be executed. diff --git a/docs/1.concepts/abstraction/meta-tx.md b/docs/1.concepts/abstraction/meta-tx.md index e930bc99fb5..faff4458d03 100644 --- a/docs/1.concepts/abstraction/meta-tx.md +++ b/docs/1.concepts/abstraction/meta-tx.md @@ -161,7 +161,7 @@ but will fail on Bob's shard. ## Function Call Access Keys in Meta Transactions -[Function Call Access Keys](../protocol/access-keys.md#function-call-keys-function-call-keys) +[Function Call Access Keys](../protocol/access-keys.md#function-call-keys) are limited to signing transactions for specific methods on a specific contract. @@ -175,4 +175,4 @@ make the call, the action is executed. The allowance however is not checked, as all costs have been covered by the relayer. Hence, the action will be executed even if the allowance is insufficient -to cover the costs. \ No newline at end of file +to cover the costs. diff --git a/docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures.md b/docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures.md index 9a7369b5683..f0fb334a287 100644 --- a/docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures.md +++ b/docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures.md @@ -78,13 +78,15 @@ We provide code to derive the address, as it's a complex process that involves m +We recommend hardcoding the derivation paths in your application to ensure the signature request is made to the correct account + :::tip -We recommend hardcoding the derivation paths in your application to ensure the signature request is made to the correct account +Here you can find MPC service public keys: -- **v1.signer-prod.testnet** (testnet): `secp256k1:4NfTiv3UsGahebgTaHyD9vF8KYKMBnfd6kh94mK6xv8fGBiJB8TBtFMP5WWXz6B89Ac1fbpzPwAvoyQebemHFwx3` +- **v1.signer-prod.testnet** ([testnet](https://testnet.nearblocks.io/address/v1.signer-prod.testnet)): `secp256k1:4NfTiv3UsGahebgTaHyD9vF8KYKMBnfd6kh94mK6xv8fGBiJB8TBtFMP5WWXz6B89Ac1fbpzPwAvoyQebemHFwx3` -- **v1.signer** (mainnet): `secp256k1:3tFRbMqmoa6AAALMrEFAYCEoHcqKxeW38YptwowBVBtXK1vo36HDbUWuR6EZmoK4JcH6HDkNMGGqP1ouV7VZUWya` +- **v1.signer** ([mainnet](https://nearblocks.io/address/v1.signer)): `secp256k1:3tFRbMqmoa6AAALMrEFAYCEoHcqKxeW38YptwowBVBtXK1vo36HDbUWuR6EZmoK4JcH6HDkNMGGqP1ouV7VZUWya` ::: diff --git a/docs/2.build/5.primitives/ft/bos/check-balance.md b/docs/2.build/5.primitives/ft/bos/check-balance.md index 1f6eea8909f..09a3ffd2612 100644 --- a/docs/2.build/5.primitives/ft/bos/check-balance.md +++ b/docs/2.build/5.primitives/ft/bos/check-balance.md @@ -1,5 +1,5 @@ :::info -Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [above](#get-token-metadata). +Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [here](/build/primitives/ft/bos/get-metadata). ::: ```js @@ -19,4 +19,4 @@ const userTokenBalance = Near.view(tokenContract, "ft_balance_of", {

- \ No newline at end of file + diff --git a/docs/2.build/5.primitives/ft/web-app/check-balance.md b/docs/2.build/5.primitives/ft/web-app/check-balance.md index 004f7d83dd9..02d6a711b22 100644 --- a/docs/2.build/5.primitives/ft/web-app/check-balance.md +++ b/docs/2.build/5.primitives/ft/web-app/check-balance.md @@ -1,7 +1,7 @@ :::info -Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [above](#get-token-metadata). +Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [here](/build/primitives/ft/web-app/get-metadata). ::: ```js @@ -31,4 +31,4 @@ await wallet.viewMethod({ -_The `Wallet` object comes from our [quickstart template](https://github.com/near-examples/hello-near-examples/blob/main/frontend/near-wallet.js)_ \ No newline at end of file +_The `Wallet` object comes from our [quickstart template](https://github.com/near-examples/hello-near-examples/blob/main/frontend/near-wallet.js)_ diff --git a/docs/2.build/5.primitives/oracles.md b/docs/2.build/5.primitives/oracles.md index a8e3c6960c7..6c3ce7d0b6d 100644 --- a/docs/2.build/5.primitives/oracles.md +++ b/docs/2.build/5.primitives/oracles.md @@ -27,7 +27,7 @@ Here is a directory of third-party oracle services deployed on the NEAR blockcha | Name | Creator | Description | | -------------------------------------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------------- | -| [Price Oracle](#price-oracle) | [NearDefi](https://github.com/NearDeFi) | Open source oracle for real-time asset pricing | +| [Price Oracle](#price-oracle-by-neardefi) | [NearDefi](https://github.com/NearDeFi) | Open source oracle for real-time asset pricing | | [Pyth Network Oracle](#pyth-network-oracle) | [Pyth Network](https://pyth.network/) | High-frequency, low-latency oracle for price feeds | | **[[Your Project Here]](https://github.com/near/docs/edit/master/docs/2.build/5.primitives/oracles.md)** | - | - | @@ -243,7 +243,7 @@ Although unused deposit will be refunded, you can calculate an estimate by calli > Fetches the most recent price feed stored in the Pyth Oracle contract. Is a view method, so does not require a signature or payment. -- args: `price_identifier` _(unique [price feed identifier](#environment-variables))_ +- args: `price_identifier` _(unique price feed identifier)_ - type: `object` - example: `{ price_identifier: 'f9c0172ba10dfa8...' }` diff --git a/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/nft-indexer.md b/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/nft-indexer.md index 16a969a6af6..1efe3574250 100644 --- a/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/nft-indexer.md +++ b/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/nft-indexer.md @@ -13,7 +13,7 @@ sidebar_label: NFT Indexer ## The End -This tutorial ends with a working NFT indexer built on top [NEAR Lake Framework JS](/concepts/advanced/near-lake-framework). The indexer is watching for `nft_mint` [Events](https://nomicon.io/Standards/EventsFormat) and prints some relevant data: +This tutorial ends with a working NFT indexer built on top [NEAR Lake Framework JS](/build/data-infrastructure/lake-framework/near-lake-framework). The indexer is watching for `nft_mint` [Events](https://nomicon.io/Standards/EventsFormat) and prints some relevant data: - `receiptId` of the [Receipt](/build/data-infrastructure/lake-data-structures/receipt) where the mint has happened - Marketplace - NFT owner account name @@ -31,7 +31,7 @@ In this tutorial our goal is to show you how you can "listen" to the Events cont As the example we will be building an indexer that watches all the NFTs minted following the [NEP-171 Events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) standard, assuming we're collectors who don't want to miss a thing. Our indexer should notice every single NFT minted and give us a basic set of data like: in what Receipt it was minted, and show us the link to a marketplace (we'll cover [Paras](https://paras.id) and [Mintbase](https://mintbase.io) in our example). -We will use JS version of [NEAR Lake Framework](/concepts/advanced/near-lake-framework) in this tutorial. Though the concept is the same for Rust, but we want to show more people that it's not that complex to build your own indexer. +We will use JS version of [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) in this tutorial. Though the concept is the same for Rust, but we want to show more people that it's not that complex to build your own indexer. ## Preparation diff --git a/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/python-nft-indexer.md b/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/python-nft-indexer.md index e7a348b1cc5..ec2cf688111 100644 --- a/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/python-nft-indexer.md +++ b/docs/2.build/6.data-infrastructure/lake-framework/building-indexers/python-nft-indexer.md @@ -13,7 +13,7 @@ sidebar_label: "NFT indexer for Python" ## The Goal -This tutorial ends with a working NFT indexer built on top [NEAR Lake Framework for Python](/concepts/advanced/near-lake-framework). The indexer is watching for `nft_mint` [Events](https://nomicon.io/Standards/EventsFormat) and prints some relevant data: +This tutorial ends with a working NFT indexer built on top [NEAR Lake Framework for Python](/build/data-infrastructure/lake-framework/near-lake-framework/). The indexer is watching for `nft_mint` [Events](https://nomicon.io/Standards/EventsFormat) and prints some relevant data: - `receipt_id` of the [Receipt](/build/data-infrastructure/lake-data-structures/receipt) where the mint has happened - Marketplace - NFT owner account name @@ -31,7 +31,7 @@ In this tutorial our goal is to show you how you can "listen" to the Events cont As the example we will be building an indexer that watches all the NFTs minted following the [NEP-171 Events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) standard, assuming we're collectors who don't want to miss a thing. Our indexer should notice every single NFT minted and give us a basic set of data like: in what Receipt it was minted, and show us the link to a marketplace (we'll cover [Paras](https://paras.id) and [Mintbase](https://mintbase.io) in our example). -We will use Python version of [NEAR Lake Framework](/concepts/advanced/near-lake-framework) in this tutorial. Though the concept is the same for Rust, but we want to show more people that it's not that complex to build your own indexer. +We will use Python version of [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) in this tutorial. Though the concept is the same for Rust, but we want to show more people that it's not that complex to build your own indexer. ## Preparation diff --git a/docs/2.build/6.data-infrastructure/lake-framework/migrating-to-near-lake-framework.md b/docs/2.build/6.data-infrastructure/lake-framework/migrating-to-near-lake-framework.md index a954186dd4d..4f1cb561911 100644 --- a/docs/2.build/6.data-infrastructure/lake-framework/migrating-to-near-lake-framework.md +++ b/docs/2.build/6.data-infrastructure/lake-framework/migrating-to-near-lake-framework.md @@ -5,7 +5,7 @@ sidebar_label: Migrating to NEAR Lake framework # Migrating to NEAR Lake Framework -We encourage everyone who don't have a hard requirement to use [NEAR Indexer Framework](/concepts/advanced/near-indexer-framework) consider the migration to [NEAR Lake Framework](/concepts/advanced/near-lake-framework). +We encourage everyone who don't have a hard requirement to use [NEAR Indexer Framework](https://github.com/near/nearcore/tree/master/chain/indexer) consider the migration to [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework). In this tutorial we'll show you how to migrate the project using [indexer-tx-watcher-example](https://github.com/near-examples/indexer-tx-watcher-example) as a showcase. @@ -83,7 +83,7 @@ near-lake-framework = "0.4.0" ## Change the clap configs -Currently we have structure `Opts` that has a subcommand with `Run` and `Init` command. Since [NEAR Lake Framework](/concepts/advanced/near-lake-framework) doesn't need `data` and config files we don't need `Init` at all. So we need to combine some structures into `Opts` itself. +Currently we have structure `Opts` that has a subcommand with `Run` and `Init` command. Since [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) doesn't need `data` and config files we don't need `Init` at all. So we need to combine some structures into `Opts` itself. ```rust title=src/config.rs ... @@ -271,7 +271,7 @@ async fn main() -> Result<(), tokio::io::Error> { ``` -Let's cast `LakeConfig` from `Opts` and instantiate [NEAR Lake Framework](/concepts/advanced/near-lake-framework)'s `stream` +Let's cast `LakeConfig` from `Opts` and instantiate [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework)'s `stream` ```rust title=src/main.rs #[tokio::main] @@ -308,7 +308,7 @@ async fn main() -> Result<(), tokio::io::Error> { .collect(); ``` -Now we can call `listen_blocks` function we have used before in our indexer while it was built on top of [NEAR Indexer Framework](/concepts/advanced/near-indexer-framework). And return `Ok(())` so our `main()` would be happy. +Now we can call `listen_blocks` function we have used before in our indexer while it was built on top of [NEAR Indexer Framework](https://github.com/near/nearcore/tree/master/chain/indexer). And return `Ok(())` so our `main()` would be happy. ### Final async main with NEAR Lake Framework stream @@ -341,7 +341,7 @@ We're done. That's pretty much entire `main()` function. Drop the old one if you ## Changes in other function related to data types -Along with [NEAR Lake Framework](/concepts/advanced/near-lake-framework) release we have extracted the structures created for indexers into a separate crate. This was done in order to avoid dependency on `nearcore` as now you can depend on a separate crate that is already [published on crates.io](https://crates.io/crates/near-indexer-primitives) or on NEAR Lake Framework that exposes that crate. +Along with [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) release we have extracted the structures created for indexers into a separate crate. This was done in order to avoid dependency on `nearcore` as now you can depend on a separate crate that is already [published on crates.io](https://crates.io/crates/near-indexer-primitives) or on NEAR Lake Framework that exposes that crate. ### `listen_blocks` @@ -394,7 +394,7 @@ fn is_tx_receiver_watched( ## Conclusion -And now we have a completely migrated to [NEAR Lake Framework](/concepts/advanced/near-lake-framework) indexer. +And now we have a completely migrated to [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) indexer. We are posting the complete diffs for the reference diff --git a/docs/2.build/6.data-infrastructure/lake-framework/near-lake-state-changes-indexer.md b/docs/2.build/6.data-infrastructure/lake-framework/near-lake-state-changes-indexer.md index 939f8362302..e2364928fd8 100644 --- a/docs/2.build/6.data-infrastructure/lake-framework/near-lake-state-changes-indexer.md +++ b/docs/2.build/6.data-infrastructure/lake-framework/near-lake-state-changes-indexer.md @@ -11,13 +11,13 @@ title: NEAR Lake Indexer Tutorial :::info Version 0.2.0 -The video is based on the [`near-lake-framework`](/concepts/advanced/near-lake-framework) version 0.2.0 +The video is based on the [`near-lake-framework`](/build/data-infrastructure/lake-framework/near-lake-framework) version 0.2.0 At the same time we're keeping the source code up to date with the latest version of the published crate. ::: -We've created a video tutorial to empower the release announcement of [NEAR Lake Framework](/concepts/advanced/near-lake-framework). +We've created a video tutorial to empower the release announcement of [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework). In this tutorial you will build an indexer application to watch for any `StateChange`s affecting the account or a list of account provided. diff --git a/docs/2.build/6.data-infrastructure/lake-framework/near-lake.md b/docs/2.build/6.data-infrastructure/lake-framework/near-lake.md index 4bda47886dc..b975004ca15 100644 --- a/docs/2.build/6.data-infrastructure/lake-framework/near-lake.md +++ b/docs/2.build/6.data-infrastructure/lake-framework/near-lake.md @@ -4,7 +4,7 @@ sidebar_label: Lake Overview title: NEAR Lake Indexer --- -NEAR Lake is an indexer built on top of [NEAR Indexer Framework](/concepts/advanced/near-indexer-framework) to watch the network and store all the event logs such as [FT Events](https://nomicon.io/Standards/Tokens/FungibleToken/Event) and [NFT Events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) as JSON files on AWS S3. +NEAR Lake is an indexer built on top of [NEAR Indexer Framework](https://github.com/near/nearcore/tree/master/chain/indexer) to watch the network and store all the event logs such as [FT Events](https://nomicon.io/Standards/Tokens/FungibleToken/Event) and [NFT Events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) as JSON files on AWS S3. :::info GitHub repo @@ -50,7 +50,7 @@ The data structure used by Lake Indexer is the following: ### How to use it -We have created the [NEAR Lake Framework](/concepts/advanced/near-lake-framework) to have a simple straightforward way to create an indexer on top of the data stored by NEAR Lake itself. +We have created the [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) to have a simple straightforward way to create an indexer on top of the data stored by NEAR Lake itself. :::info NEAR Lake Framework diff --git a/docs/2.build/6.data-infrastructure/lake-framework/running-near-lake/lake-start-options.md b/docs/2.build/6.data-infrastructure/lake-framework/running-near-lake/lake-start-options.md index dc612e0d77c..49ee1430c8f 100644 --- a/docs/2.build/6.data-infrastructure/lake-framework/running-near-lake/lake-start-options.md +++ b/docs/2.build/6.data-infrastructure/lake-framework/running-near-lake/lake-start-options.md @@ -7,7 +7,7 @@ sidebar_label: "Start options" ## The End -This tutorial ends with the example code of the simple indexer built on top of [NEAR Lake Framework](/concepts/advanced/near-lake-framework) that can start: +This tutorial ends with the example code of the simple indexer built on top of [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) that can start: - from specified block height (out of the box) ```bash ./target/release/indexer mainnet from-block 65359506 @@ -34,11 +34,11 @@ There is another important side - the maintenance. This involves: Almost in all of the above cases you might want to start or restart your indexer not only from the specific block you need to provide, but from the block it was stopped, or from the latest final block in the network. -[NEAR Lake Framework](/concepts/advanced/near-lake-framework) doesn't provide such options. Actually, we didn't empower the library with these options to start indexer intentionally. +[NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) doesn't provide such options. Actually, we didn't empower the library with these options to start indexer intentionally. :::info Intent -We want to keep [NEAR Lake Framework](/concepts/advanced/near-lake-framework) crate in the narrowest possible way. The goal for the library is to do a single job and allow it to be empowered with any features but outside of the crate itself +We want to keep [NEAR Lake Framework](/build/data-infrastructure/lake-framework/near-lake-framework) crate in the narrowest possible way. The goal for the library is to do a single job and allow it to be empowered with any features but outside of the crate itself ::: diff --git a/docs/3.tutorials/examples/advanced-xcc.md b/docs/3.tutorials/examples/advanced-xcc.md index eae98efc9b9..7b188bc7426 100644 --- a/docs/3.tutorials/examples/advanced-xcc.md +++ b/docs/3.tutorials/examples/advanced-xcc.md @@ -187,7 +187,7 @@ value returned by each call, or an error message. ### Multiple Calls - Same Result Type -This example is a particular case of the previous one ([Calling Multiple Contracts](#2-calling-multiple-contracts)). +This example is a particular case of the previous one ([Calling Multiple Contracts](#calling-multiple-contracts)). It simply showcases a different way to check the results by directly accessing the `promise_result` array. In this case, we call multiple contracts that will return the same type: diff --git a/docs/3.tutorials/fts/1-skeleton.md b/docs/3.tutorials/fts/1-skeleton.md index 1efd4496ebf..d61a6cd6224 100644 --- a/docs/3.tutorials/fts/1-skeleton.md +++ b/docs/3.tutorials/fts/1-skeleton.md @@ -35,7 +35,7 @@ The repository comes with many different folders. Each folder represents a diffe | File | Description | | -------------------------------- | -------------------------------------------------------------------------------- | -| [ft_core.rs](#corers) | Contains the logic for transferring and controlling FTs. This file represents the implementation of the [core](https://nomicon.io/Standards/Tokens/FungibleToken/Core) standard. | | +| [ft_core.rs](#ft_corers) | Contains the logic for transferring and controlling FTs. This file represents the implementation of the [core](https://nomicon.io/Standards/Tokens/FungibleToken/Core) standard. | | | [lib.rs](#librs) | Holds the smart contract initialization functions and dictates what information is kept on-chain. | | [metadata.rs](#metadatars) | Defines the metadata structure. This file represents the implementation of the [metadata](https://nomicon.io/Standards/Tokens/FungibleToken/Metadata) extension of the standard. | | [storage.rs](#storagers) | Contains the logic for registration and storage. This file represents the implementation of the [storage management](https://nomicon.io/Standards/StorageManagement) standard. | diff --git a/docs/3.tutorials/fts/5.transfers.md b/docs/3.tutorials/fts/5.transfers.md index 022945a3b22..f04bf5f8af1 100644 --- a/docs/3.tutorials/fts/5.transfers.md +++ b/docs/3.tutorials/fts/5.transfers.md @@ -369,7 +369,7 @@ Hurray! At this point, your FT contract is fully complete and all the functional ## Conclusion -In this tutorial, you learned how to expand a FT contract by adding ways for users to transfer FTs. You [broke down](#introduction) the problem into smaller, more digestible subtasks and took that information and implemented both the [FT transfer](#transfer-function) and [FT transfer call](#transfer-call-function) functions. In addition, you deployed another [contract](#redeploying-contract) and [tested](#testing-changes) the transfer functionality. +In this tutorial, you learned how to expand a FT contract by adding ways for users to transfer FTs. You [broke down](#introduction) the problem into smaller, more digestible subtasks and took that information and implemented both the [FT transfer](#transfer-function) and [FT transfer call](#transfer-call-function) functions. In addition, you deployed another [contract](#redeploying-contract) and [tested](#testing-the-transfer-function) the transfer functionality. In the [next tutorial](/tutorials/fts/marketplace), you'll learn about how an NFT marketplace can operate to purchase NFTs by using Fungible Tokens. diff --git a/docs/3.tutorials/nfts/1-skeleton.md b/docs/3.tutorials/nfts/1-skeleton.md index 5e284e0b815..4cc8fca7eb0 100644 --- a/docs/3.tutorials/nfts/1-skeleton.md +++ b/docs/3.tutorials/nfts/1-skeleton.md @@ -65,7 +65,7 @@ Here is a brief description of what each source file is responsible for: | [mint.rs](#mintrs) | Contains token minting logic | | [nft_core.rs](#nft_corers) | Core logic that allows you to transfer NFTs between users. | | [royalty.rs](#royaltyrs) | Contains payout-related functions | -| [events.rs](#events) | Contains events related structures | +| [events.rs](#eventsrs) | Contains events related structures | :::tip Explore the code in our [GitHub repository](https://github.com/near-examples/nft-tutorial/). diff --git a/docs/3.tutorials/nfts/2-minting.md b/docs/3.tutorials/nfts/2-minting.md index 87f620fdfa8..0241a479db4 100644 --- a/docs/3.tutorials/nfts/2-minting.md +++ b/docs/3.tutorials/nfts/2-minting.md @@ -420,7 +420,7 @@ In this tutorial, you went through the basics of setting up and understand the l You first looked at [what it means](#what-does-minting-mean) to mint NFTs and how to break down the problem into more feasible chunks. You then started modifying the skeleton contract chunk by chunk starting with solving the problem of [storing information / state](#storing-information) on the contract. You then looked at what to put in the [metadata and token information](#metadata-and-token-info). Finally, you looked at the logic necessary for [minting NFTs](#minting-logic). -After the contract was written, it was time to deploy to the blockchain. You [deployed the contract](#deploy-the-contract) and [initialized it](#initialize-contract). Finally, you [minted your very first NFT](#minting-our-first-nft) and saw that some changes are needed before you can view it in the wallet. +After the contract was written, it was time to deploy to the blockchain. You [deployed and initialized the contract](#deploy-the-contract). Finally, you [minted your very first NFT](#minting-our-first-nft) and saw that some changes are needed before you can view it in the wallet. --- diff --git a/docs/3.tutorials/nfts/5-approval.md b/docs/3.tutorials/nfts/5-approval.md index 79b5f83aeca..6329c5a0124 100644 --- a/docs/3.tutorials/nfts/5-approval.md +++ b/docs/3.tutorials/nfts/5-approval.md @@ -50,7 +50,7 @@ Before transferring, you would need to clear the list of approved accounts since On the surface, this would work, but if you start thinking about the edge cases, some problems arise. Often times when doing development, a common approach is to think about the easiest and most straightforward solution. Once you've figured it out, you can start to branch off and think about optimizations and edge cases. -Let's consider the following scenario. Benji has an NFT and gives two separate marketplaces access to transfer his token. By doing so, he's putting the NFT for sale (more about that in the [marketplace integrations](#marketplace-integrations) section). Let's say he put the NFT for sale for 1 NEAR on both markets. The tokens list of approved account IDs would look like the following: +Let's consider the following scenario. Benji has an NFT and gives two separate marketplaces access to transfer his token. By doing so, he's putting the NFT for sale. Let's say he put the NFT for sale for 1 NEAR on both markets. The tokens list of approved account IDs would look like the following: ``` Token: { @@ -583,17 +583,17 @@ With the testing finished, you've successfully implemented the approvals extensi Today you went through a lot of logic to implement the [approvals extension](https://nomicon.io/Standards/Tokens/NonFungibleToken/ApprovalManagement) so let's break down exactly what you did. -First, you explored the [basic approach](#basic-solution) of how to solve the problem. You then went through and discovered some of the [problems](#the-problem) with that solution and learned how to [fix it](#the-solution). +First, you explored the [basic approach](#allow-an-account-to-transfer-your-nft) of how to solve the problem. You then went through and discovered some of the [problems](#the-problem) with that solution and learned how to [fix it](#the-solution). -After understanding what you should do to implement the approvals extension, you started to [modify](#expanding-json-and-token) the JsonToken and Token structs in the contract. You then implemented the logic for [approving accounts](#approving-accounts) and saw how [marketplaces](#marketplace-integrations) are integrated. +After understanding what you should do to implement the approvals extension, you started to [modify](#expanding-the-token-and-jsontoken-structs) the JsonToken and Token structs in the contract. You then implemented the logic for [approving accounts](#approving-accounts). -After implementing the logic behind approving accounts, you went and [changed the restrictions](#changing-restrictions) needed to transfer NFTs. The last step you did to finalize the approving logic was to go back and edit the [nft_core](#nft-core-changes) files to be compatible with the new changes. +After implementing the logic behind approving accounts, you went and [changed the restrictions](#changing-the-restrictions-for-transferring-nfts) needed to transfer NFTs. The last step you did to finalize the approving logic was to go back and edit the [nft_core](#changes-to-nft_corers) files to be compatible with the new changes. At this point, everything was implemented in order to allow accounts to be approved and you extended the functionality of the [core standard](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core) to allow for approved accounts to transfer tokens. -You implemented a view method to [check](#check-if-account-approved) if an account is approved and to finish the coding portion of the tutorial, you implemented the logic necessary to [revoke an account](#revoke-account) as well as [revoke all accounts](#revoke-all-accounts). +You implemented a view method to [check](#check-if-an-account-is-approved) if an account is approved and to finish the coding portion of the tutorial, you implemented the logic necessary to [revoke an account](#revoke-an-account) as well as [revoke all accounts](#revoke-all-accounts). -After this, the contract code was finished and it was time to move onto testing where you created an [account](#deployment) and tested the [approving](#approving-an-account) and [transferring](#transferring-the-nft) for your NFTs. +After this, the contract code was finished and it was time to move onto testing where you created an [account](#deployment-and-initialization) and tested the [approving](#approving-an-account) and [transferring](#transferring-the-nft) for your NFTs. In the [next tutorial](6-royalty.md), you'll learn about the royalty standards and how you can interact with NFT marketplaces. diff --git a/docs/3.tutorials/nfts/7-events.md b/docs/3.tutorials/nfts/7-events.md index 7e7b1a10cb2..c4bc030bbbc 100644 --- a/docs/3.tutorials/nfts/7-events.md +++ b/docs/3.tutorials/nfts/7-events.md @@ -287,7 +287,7 @@ Hurray! At this point, your NFT contract is fully complete and the events standa ## Conclusion -Today you went through the [events standard](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) and implemented the necessary logic in your smart contract. You created events for [minting](#logging-minted-tokens) and [transferring](#logging-transfers) NFTs. You then deployed and [tested](#initialization-and-minting) your changes by minting and transferring NFTs. +Today you went through the [events standard](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) and implemented the necessary logic in your smart contract. You created events for [minting](#logging-minted-tokens) and [transferring](#logging-transfers) NFTs. You then deployed and tested your changes by [minting](#minting) and [transferring](#transferring) NFTs. In the [next tutorial](8-marketplace.md), you'll look at the basics of a marketplace contract and how it was built. diff --git a/docs/3.tutorials/nfts/js/5-approval.md b/docs/3.tutorials/nfts/js/5-approval.md index 5799bbc7823..b06450c6bf4 100644 --- a/docs/3.tutorials/nfts/js/5-approval.md +++ b/docs/3.tutorials/nfts/js/5-approval.md @@ -523,15 +523,15 @@ With the testing finished, you've successfully implemented the approvals extensi Today you went through a lot of logic to implement the [approvals extension](https://nomicon.io/Standards/Tokens/NonFungibleToken/ApprovalManagement) so let's break down exactly what you did. -First, you explored the [basic approach](#basic-solution) of how to solve the problem. You then went through and discovered some of the [problems](/tutorials/nfts/js/approvals#the-problem) with that solution and learned how to [fix it](#the-solution). +First, you explored the [basic approach](#allow-an-account-to-transfer-your-nft) of how to solve the problem. You then went through and discovered some of the [problems](/tutorials/nfts/js/approvals#the-problem) with that solution and learned how to [fix it](#the-solution). -After understanding what you should do to implement the approvals extension, you started to [modify](#expanding-json-and-token) the JsonToken and Token structs in the contract. You then implemented the logic for [approving accounts](#approving-accounts) and saw how [marketplaces](#marketplace-integrations) are integrated. +After understanding what you should do to implement the approvals extension, you started to [modify](#expanding-the-token-and-jsontoken-structs) the JsonToken and Token structs in the contract. You then implemented the logic for [approving accounts](#approving-accounts) and saw how [marketplaces](#marketplace-integrations) are integrated. -After implementing the logic behind approving accounts, you went and [changed the restrictions](#changing-restrictions) needed to transfer NFTs. The last step you did to finalize the approving logic was to go back and edit the [nft_core](#nft-core-changes) files to be compatible with the new changes. +After implementing the logic behind approving accounts, you went and [changed the restrictions](#changing-the-restrictions-for-transferring-nfts) needed to transfer NFTs. The last step you did to finalize the approving logic was to go back and edit the [nft_core](#changes-to-nft_corets) files to be compatible with the new changes. At this point, everything was implemented in order to allow accounts to be approved and you extended the functionality of the [core standard](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core) to allow for approved accounts to transfer tokens. -You implemented a view method to [check](#check-if-account-approved) if an account is approved and to finish the coding portion of the tutorial, you implemented the logic necessary to [revoke an account](#revoke-account) as well as [revoke all accounts](#revoke-all-accounts). +You implemented a view method to [check](#check-if-an-account-is-approved) if an account is approved and to finish the coding portion of the tutorial, you implemented the logic necessary to [revoke an account](#revoke-an-account) as well as [revoke all accounts](#revoke-all-accounts). After this, the contract code was finished and it was time to move onto testing where you created a [subaccount](#creating-sub-account) and tested the [approving](/tutorials/nfts/js/approvals#approving-an-account) and [transferring](#transferring-the-nft) for your NFTs. diff --git a/docs/4.tools/indexing-tools.md b/docs/4.tools/indexing-tools.md index cb0ea02b754..225ded01327 100644 --- a/docs/4.tools/indexing-tools.md +++ b/docs/4.tools/indexing-tools.md @@ -10,7 +10,7 @@ Indexers are used by apps that need to access blockchain data efficiently, such - [BigQuery](../2.build/6.data-infrastructure/big-query.md): Blockchain data indexing in NEAR Public Lakehouse is for anyone wanting to understand blockchain data. -- [NEAR Lake Framework](../2.build/6.data-infrastructure/lake-framework/near-lake.md): a companion library to NEAR Lake. It allows you to build your own indexer that watches a stream of blocks **from a NEAR Lake data source** and allows you to **create your own logic to process that data**. Keep in mind this is **the one you want to use for future projects**, instead of the Indexer Framework. Read [why it is better](https://docs.near.org/concepts/advanced/near-indexer-framework#why-is-it-better-than-near-indexer-framework). +- [NEAR Lake Framework](../2.build/6.data-infrastructure/lake-framework/near-lake.md): a companion library to NEAR Lake. It allows you to build your own indexer that watches a stream of blocks **from a NEAR Lake data source** and allows you to **create your own logic to process that data**. Keep in mind this is **the one you want to use for future projects**, instead of the Indexer Framework. Read [why it is better](/build/data-infrastructure/lake-framework/near-lake-framework#how-does-it-compare-to-near-indexer-framework). - [Indexer.xyz Multichain Indexer](https://indexer.xyz/): Indexer.xyz is an application layer that you can build your NFT or DeFi applications entirely on top of. In addition to raw transaction indexing, Indexer.xyz provides you with a standardized GraphQL API layer to easily tap into transactions across contracts and chains. @@ -22,7 +22,7 @@ Indexers are used by apps that need to access blockchain data efficiently, such - [Covalent](https://www.covalenthq.com/docs/networks/aurora/): for [Aurora EVM](https://aurora.dev/) indexing, Covalent provides a unified API bringing visibility to billions of Web3 data points. -- [NEAR Indexer Framework](https://docs.near.org/concepts/advanced/near-indexer-framework): a micro-framework providing you with a "live" stream of blocks. Useful to handle on-chain real-time `events`. +- [NEAR Indexer Framework](https://github.com/near/nearcore/tree/master/chain/indexer): a micro-framework providing you with a "live" stream of blocks. Useful to handle on-chain real-time `events`. - [NEAR Indexer for Explorer](https://github.com/near/near-indexer-for-explorer): an indexer built on top of the indexer microframework. It watches and stores all events/data from the blockchain to a **PostgreSQL database**. You can clone the [GitHub repository](https://github.com/near/near-indexer-for-explorer) and customize your own indexer solution. diff --git a/docs/4.tools/near-api.md b/docs/4.tools/near-api.md index 12b1f9d1403..7f35b3c7c26 100644 --- a/docs/4.tools/near-api.md +++ b/docs/4.tools/near-api.md @@ -117,7 +117,7 @@ To allow users to login into your web application using a wallet you will need t The object returned from `connect` is your entry-point for all commands in the API. - To transactions you'll need a [`KeyStore`](#signers). + To transactions you'll need a [`KeyStore`](#key-handlers-stores--signers). @@ -535,7 +535,7 @@ This endpoint returns the transaction history for the given NFT and `timestamp`/ |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|OK|[HistoryResponse](#schemahistoryresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|OK|[HistoryResponse](#historyresponse)| |500|[Internal Server Error](https://tools.ietf.org/html/rfc7231#section-6.6.1)|See the inner `code` value to get more details|None|