Merge branch 'master' into feat/posthog-analytics

blog/2024-06-05.md

@@ -24,6 +24,11 @@ Scrolling down will reveal the option `Windows Subsystem for Linux`. Make sure i
 
 Now we will spend some time in either `PowerShell` or [Windows Terminal](https://apps.microsoft.com/detail/9n0dx20hk701), which is a modern terminal application that supports various command-line tools and shells.
 
+```bash
+# may be desirable for seamless integration between WSL2 distros of linux and docker with WSL backend 
+wsl --set-default-version 2
+```
+
 ```
 wsl --install --d Ubuntu
 ```

blog/2024-08-13.md

@@ -0,0 +1,65 @@
+---
+title: Future of Pagoda Services
+authors: [ewiner]
+slug: 2024-08-13-pagoda-services
+tags: [updates]
+hide_table_of_contents: false
+---
+
+As the NEAR ecosystem continues to decentralize, Pagoda will cease operations within the next six months and decentralize its functions into NEAR ecosystem teams and committees.  This document describes the transition plan for each of the services, activities, and tools that Pagoda develops or operates.
+
+<!-- truncate -->
+
+### Critical NEAR Services
+
+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)
+-   [NEAR Lake](https://docs.near.org/concepts/advanced/near-lake-framework)
+-   [BigQuery Public Dataset](https://docs.near.org/build/data-infrastructure/big-query)
+-   [Node Snapshots](https://near-nodes.io/intro/node-data-snapshots)
+-   [State Sync](https://near-nodes.io/rpc/state-sync)
+-   Undocumented but critical services:
+    -   KitWallet Indexer API
+    -   near-cli Testnet Faucet
+
+Each transition will be independently planned and communicated on its own timeline and this page will be updated accordingly.
+
+The NEAR [Infrastructure Committee](https://dev.near.org/infrastructure-committee.near/widget/near-prpsls-bos.components.pages.app?page=about) will manage this transition process by soliciting proposals from the community for continued operation of these services, then will select, fund, and oversee the new operator.
+
+#### A Note About near.org RPC
+
+The Infrastructure Committee feels that Pagoda's fully-subsidized near.org RPC service is getting in the way of decentralization efforts and is preventing high-quality commercial RPC offerings from gaining traction. If a NEAR core team continues to support a free-to-use near.org RPC service, it will be required to gradually lower its rate limits over the coming months to prevent abuse. More details on this plan will be communicated by the end of September 2024. In light of this proposed change, **high-traffic near.org RPC users should start making plans to switch to other RPC providers**.
+
+### Chain Abstraction Services
+
+[Chain Signatures](https://docs.near.org/concepts/abstraction/chain-signatures), [Multichain Gas Relayer](https://docs.near.org/build/chain-abstraction/multichain-gas-relayer/overview), and [FastAuth](https://docs.near.org/build/chain-abstraction/fastauth-sdk) will continue to be developed by Pagoda, then will be taken over by the new Chain Abstraction / Multichain spinout from Pagoda and Proximity. More information will be shared in September or October 2024.
+
+### Pagoda Operations & Ecosystem Services
+
+Pagoda’s ecosystem services will transition as follows:
+
+-   [Infrastructure Committee](https://dev.near.org/infrastructure-committee.near/widget/near-prpsls-bos.components.pages.app?page=about) administration, the recently rebooted Security Assessment Program, and management of the [near.org](http://near.org) website will move under the purview of NEAR Foundation.
+-   [Bug bounty](https://hackenproof.com/company/near/programs) triage will be transitioned to the protocol team at NEAR One.
+-   The [NEAR Helpdesk](https://help.near.org/) will be turned into self-service documentation.
+-   Pagoda's informal technical / smart contract advisory services for other ecosystem companies will wind down over the next few months.
+
+### Open-Source Libraries
+
+These open-source libraries and tools will be developed by Pagoda until they reach a logical completion or stopping point:
+
+-   [Pagoda Metatransaction Relayer](https://github.com/near/pagoda-relayer-rs)
+-   [Chain Hosted UI](https://github.com/near/chain-hosted-ui)
+-   [Modularization and Refactor](https://t.me/neardev/53280) of near-api-js
+
+Once active development by Pagoda has ceased, it doesn't mean these tools have to languish. We encourage the NEAR community to continue this work. If you need funding to do so, you can submit proposals to [DevHub](https://dev.near.org/devhub.near/widget/app) or the [Infrastructure Committee](https://dev.near.org/infrastructure-committee.near/widget/near-prpsls-bos.components.pages.app?page=about).
+
+### Deprecated Services
+
+Between now and February 2025, Pagoda's development work will slow down or stop on the following products and services:
+
+-   [QueryAPI](https://docs.near.org/build/data-infrastructure/query-api/intro)
+-   [Enhanced API](https://docs.near.org/pagoda/rpc/api)
+-   [Alerts & Triggers](https://docs.near.org/pagoda/alerts/intro)
+
+These are open-source services and we encourage the community to continue with their development and operation. If we can't identify new operators quickly, we will encourage remaining users of these services to switch to alternative solutions, then communicate a timeline for these services to be turned off.

docs/1.concepts/3.advanced/indexers.md

@@ -88,4 +88,4 @@ We hope this article gives you an understanding of the Indexer concept. Also, we
 ## What's next?
 We encourage you to learn more about the [Lake Indexer project](/build/data-infrastructure/lake-framework/near-lake). Please, proceed to [Tutorials](/build/data-infrastructure/lake-framework/near-lake-state-changes-indexer) section to learn how to build an indexer on practice.
 
-Alternatively, there are a few other third-party indexers that are tightly integrated with the NEAR ecosystem. You can review all of your data sourcing options (including The Graph, Pagoda, Pipespeak, and SubQuery) under [data tools](/concepts/data-flow/data-storage#data-tools).
+Alternatively, there are a few other third-party indexers that are tightly integrated with the NEAR ecosystem. You can review all of your data sourcing options (including The Graph, Pagoda, Pikespeak, and SubQuery) under [data tools](/concepts/data-flow/data-storage#data-tools).

docs/1.concepts/web3/blockchain.md

@@ -153,7 +153,7 @@ There are a lot of blockchains out there and it might be hard to choose the most
 
 Historically, the first blockchain to introduce smart contracts was Ethereum. However, as the number of users grew, transaction speed and cost skyrocketed, and it became apparent that it couldn't handle the demand. So, a number of [scaling solutions](https://ethereum.org/en/developers/docs/scaling/) appeared - [layer 2 chains](https://ethereum.org/en/developers/docs/scaling/#layer-2-scaling), [sidechains](https://ethereum.org/en/developers/docs/scaling/sidechains/), and [plasma chains](https://ethereum.org/en/developers/docs/scaling/plasma/). However, they all use some kind of workarounds with their own unique drawbacks. Ethereum tries to fix the core problem and redesign its network - like switching to a Proof-of-stake consensus, which is ongoing for quite a long time, but exact timeline when all of the problems will be fixed is very unclear.
 
-Meanwhile, a new generation of blockchains started to appear. They learned from the Etherium mistakes, and designed them from ground-up to be fast, cheap and scalable. 
+Meanwhile, a new generation of blockchains started to appear. They learned from the Ethereum mistakes, and designed them from ground-up to be fast, cheap and scalable. 
 Choosing the right one is by no means an easy task, but for us we found the [NEAR](https://near.org/) blockchain to be an ideal solution, because of the following properties:
 - Transactions are cheap and very fast.
 - Designed to be extremely scalable from the beginning. This means we can count that transaction cost and speed will remain stable in the future.

docs/1.concepts/web3/near.md

@@ -148,7 +148,7 @@ As an alternative to building your own indexer with a database and an API server
 
 By now, we should be familiar with necessary concepts to start developing WEB 3.0 applications, so let’s explore the development tools available.
 
-First of all, we need a development and testing environment. Of course, we could theoraticaly perform development and testing on the main blockchain network, but this would not be cheap. For this reason, NEAR provides [several networks](../../1.concepts/basics/networks.md) that can be used during development:
+First of all, we need a development and testing environment. Of course, we could theoretically perform development and testing on the main blockchain network, but this would not be cheap. For this reason, NEAR provides [several networks](../../1.concepts/basics/networks.md) that can be used during development:
 - testnet - public NEAR network which is identical to mainnet and can be used for free.
 - localnet - you can deploy your personal NEAR network on your own environment. Because it’s owned by you, data and code can be kept private during development. More info on how you can run your own node can be [found here](https://near-nodes.io/validator/running-a-node). Alternatively, you can bootstrap an entire testing infrastructure in Docker on your local machine using Kurtosis - [guide is here](../../2.build/2.smart-contracts/testing/kurtosis-localnet.md).
 - workspaces - you can start your own local network to perform e2e testing. More info [here](../../2.build/2.smart-contracts/testing/integration-test.md).

docs/1.concepts/web3/nfts.md

@@ -325,7 +325,7 @@ In the blockchain world, creation of new NFTs is usually called minting. And as
 
 
 
-* Users can mint them directly. This can be done by either allowing creation of NFTs from scratch, or by using more complex processes, like breeding or upgrading. The most famous example of such process is breeding in [CrytoKitties](https://www.cryptokitties.co/) game - new NFTs are created by combining existing ones. With this approach users usually have to pay to cover the storage and gas cost of NFTs creation.
+* Users can mint them directly. This can be done by either allowing creation of NFTs from scratch, or by using more complex processes, like breeding or upgrading. The most famous example of such process is breeding in [CryptoKitties](https://www.cryptokitties.co/) game - new NFTs are created by combining existing ones. With this approach users usually have to pay to cover the storage and gas cost of NFTs creation.
 * NFTs can be distributed by the developer to a set of users - it is usually called [NFTs airdrop](https://www.investopedia.com/terms/a/airdrop-cryptocurrency.asp). Most often this is used as a marketing strategy to kickstart NFTs usage in applications. Storage and gas costs in this case are covered by developers.
 * NFTs can be bought on a market or obtained from the lootbox. Depending on an exact strategy, costs can either be paid by a user or by developer. Also, in this case NFTs sometimes can be minted on-demand, to avoid paying upfront costs.
 
@@ -516,7 +516,7 @@ Implementing an own Marketplace contract is more involved since there is no stan
 * [Basic marketplace example](../../3.tutorials/nfts/8-marketplace.md)
 * [Paras ](https://paras.id/)marketplace contract - [source](https://github.com/ParasHQ/paras-marketplace-contract/tree/master/paras-marketplace-contract/src). 
 
-As for third-party solutions, the most complete one is [Mintibase](https://www.mintbase.io/), which provides a full suite of components for NFTs integration - including contracts, indexer, API and a web client:
+As for third-party solutions, the most complete one is [Mintbase](https://www.mintbase.io/), which provides a full suite of components for NFTs integration - including contracts, indexer, API and a web client:
 
 
 

docs/2.build/1.chain-abstraction/fastauth-sdk.md

@@ -75,7 +75,7 @@ service cloud.firestore {
 - Press the gear button next to "Project Overview", and go to "Project settings"
 - Under "Your apps", click on the `</>` button
 - Set the app nickname as `issuer-gcp` and hit "Register app"
-- You should see the code needed for initilization and authentication of Firestore, such as:
+- You should see the code needed for initialization and authentication of Firestore, such as:
 ```js
 // Import the functions you need from the SDKs you need
 import { initializeApp } from "firebase/app";
@@ -253,7 +253,7 @@ const onCLick = () => selector.then((selector: any) => selector.wallet('fast-aut
         }),);
 ```
 
-Wehenever the user tries to login, call `onClick`.
+Whenever the user tries to login, call `onClick`.
 
 ### Getting added to the MPC recovery service
 

docs/2.build/1.chain-abstraction/meta-transactions.md

@@ -86,7 +86,7 @@ In this method we are creating an arbitrary smart contract call, instantiating a
 
 As mentioned in the above note in order to be able to relay on the client side it's necessary to have access to signing transactions directly on the client. Luckily leveraging the near biometric library it's possible to do so in a non custodial way.
 
-By calling this method and passing in the URL for the account creation endpoint (mentioned in the server section) as well as the `accoundId` everything is handled under the hood to successfully create an account.
+By calling this method and passing in the URL for the account creation endpoint (mentioned in the server section) as well as the `accountId` everything is handled under the hood to successfully create an account.
 
 <Github language='typescript' url='https://github.com/SurgeCode/near-relay/blob/main/example/src/app/page.tsx' start='17' end='23'/>
 

docs/2.build/1.chain-abstraction/wallet.md

@@ -10,7 +10,7 @@ You'll also learn how to ensure that a signature on one chain is not used to tak
 
 ### Key derivation
 
-When signing using [chain signatures](./chain-signatures.md) each account has an unlimited number of keys. Each key's public key is derived from the account name and the key extension which is an arbitrary string. 
+When signing using [chain signatures](./chain-signatures/chain-signatures.md) each account has an unlimited number of keys. Each key's public key is derived from the account name and the key extension which is an arbitrary string.
 
 User's keys can be described as follow:
 
@@ -94,7 +94,7 @@ In the following examples, the messages are coming from the user's wallet fronte
 - [Using a personal Bitcoin key](#using-a-personal-bitcoin-key)
 - [Using a personal EVM key to sign a Binance transaction](#using-a-personal-evm-key-to-sign-a-binance-transaction)
 - [Using an untyped domain key](#using-an-untyped-domain-key)
-- [Using another domains Bitcoin key](#using-another-domains-bitcoin-key)
+- [Using another domain's Bitcoin key](#using-another-domains-bitcoin-key)
 
 :::tip
 Wallet developers should follow this user flow format.

docs/2.build/2.smart-contracts/testing/kurtosis-localnet.md

@@ -622,9 +622,9 @@ Once you've logged in, you can sign a message with an optional donation.
 
 ---
 
-## Managing NEAR Pacakages
+## Managing NEAR Packages
 
-The Kurtosis NEAR Pacakages you create will continue to run on your local machine for as long as your Docker engine is running. This package runs inside of a Kurtosis "enclave" which is an environment isolated from both your computer and other enclaves. In practice, this means that you can have multiple independent local NEAR clusters running on your machine simply by rerunning the script we executed from the [setup instructions](#setup).
+The Kurtosis NEAR Packages you create will continue to run on your local machine for as long as your Docker engine is running. This package runs inside of a Kurtosis "enclave" which is an environment isolated from both your computer and other enclaves. In practice, this means that you can have multiple independent local NEAR clusters running on your machine simply by rerunning the script we executed from the [setup instructions](#setup).
 
 ### View Package Status
 

docs/2.build/5.primitives/ft.md

@@ -33,7 +33,7 @@ import CLICreateToken from "./ft/near-cli/create.md"
 import SmartContractSendToken from "./ft/smart-contract/send.md"
 import SmartContractAttachTokenToCall from "./ft/smart-contract/attach-to-call.md"
 
-Besides the native NEAR token, NEAR accounts have access to a [multitude of tokens](https://guide.ref.finance/developers-1/cli-trading#query-whitelisted-tokens) to use thoughtout the ecosystem. Moreover, it is even possible for users to create their own fungible tokens.
+Besides the native NEAR token, NEAR accounts have access to a [multitude of tokens](https://guide.ref.finance/developers-1/cli-trading#query-whitelisted-tokens) to use throughout the ecosystem. Moreover, it is even possible for users to create their own fungible tokens.
 
 In contrast with the NEAR native token, fungible token (FT) are **not stored** in the user's account. In fact, each FT lives in **their own contract** which is in charge of doing **bookkeeping**. This is, the contract keeps track of how many tokens each user has, and handles transfers internally.
 

docs/2.build/6.data-infrastructure/lake-data-structures/state_change.mdx

@@ -11,7 +11,7 @@ import TabItem from '@theme/TabItem';
 
 ## Definition
 
-This entitiy from `nearcore` describes how account's state has changed and the reason
+This entity from `nearcore` describes how account's state has changed and the reason
 
 ## `StateChangeWithCauseView`
 
@@ -101,4 +101,3 @@ export type StateChange = {
 
   </TabItem>
 </Tabs>
-

docs/2.build/6.data-infrastructure/lake-data-structures/transaction.mdx

@@ -10,7 +10,7 @@ import TabItem from '@theme/TabItem';
 
 ## Definition
 
-Transaction is the main way of interraction between a user and a blockchain. Transaction contains:
+Transaction is the main way of interaction between a user and a blockchain. Transaction contains:
 - Signer account ID
 - Receiver account ID
 - Actions

docs/2.build/6.data-infrastructure/lake-framework/migrating-to-near-lake-framework.md

@@ -499,7 +499,7 @@ We are posting the complete diffs for the reference
 -    /// Specify a custom download URL for the genesis file.
 -    #[clap(long)]
 -    pub download_genesis_url: Option<String>,
--    /// Download the verified NEAR config file automtically.
+-    /// Download the verified NEAR config file automatically.
 -    #[clap(long)]
 -    pub download_config: bool,
 -    /// Specify a custom download URL for the config file.

docs/2.build/6.data-infrastructure/lake-framework/running-near-lake/credentials.md

@@ -30,7 +30,7 @@ aws_secret_access_key=<YOUR_AWS_ACCESS_KEY>
 
 [AWS docs: Configuration and credential file settings](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
 
-#### Environment varibales
+#### Environment variables
 
 Alternatively, you can provide your AWS credentials via environment variables with constant names: