Merge branch 'near:master' into fix-bug-bounty-link

.github/workflows/build-docs.yml

@@ -63,3 +63,5 @@ jobs:
     env:
       NODE_OPTIONS: --max-old-space-size=8192
       CROWDIN_PERSONAL_TOKEN: ${{ secrets.CROWDIN_PERSONAL_TOKEN }}
+      REACT_APP_PUBLIC_POSTHOG_KEY: ${{ secrets.REACT_APP_PUBLIC_POSTHOG_KEY }}
+      REACT_APP_PUBLIC_POSTHOG_HOST: ${{ secrets.REACT_APP_PUBLIC_POSTHOG_HOST }}

.gitignore

@@ -14,3 +14,4 @@ neardev
 .docz
 serve*
 .vscode
+.env.local

blog/2024-05-15.md

@@ -24,7 +24,7 @@ As an added bonus, trades are atomic across chains, settlement takes just 2 seco
 :::tip Keep in mind
 
  There are transactions happening on different blockchains.
- The difference is that a [Multi-Party Computation service](../chain-signatures.md#multi-party-computation-service) (MPC) signs a transaction for you, and that transaction is then broadcast to another blockchain RPC node or API.
+ The difference is that a [Multi-Party Computation service](/concepts/abstraction/chain-signatures#multi-party-computation-service) (MPC) signs a transaction for you, and that transaction is then broadcast to another blockchain RPC node or API.
 
 :::
 
@@ -77,7 +77,7 @@ JSON Web Tokens are a standard RFC 7519 method for representing claims securely
 
 Using unique features of the NEAR account model, [Keypom](https://docs.keypom.xyz/) provides zero-friction onboarding and transactions on NEAR. They are generally used for NFT drops, FT drops, and ticketing.
 
-A generic Keypom user-flow could be: 
+A generic Keypom user-flow could be:
 
 1. The developer creates a restricted NEAR account
 2. The account is funded with `NEAR`
@@ -86,10 +86,10 @@ A generic Keypom user-flow could be:
 5. The user returns the remaining funds to the developer and their account is unlocked
 
 :::tip
-This allows easy on-boarding to decentralized apps. The accounts are initially restricted to prevent the user being able to simply withdraw the `NEAR` from the account. 
+This allows easy on-boarding to decentralized apps. The accounts are initially restricted to prevent the user being able to simply withdraw the `NEAR` from the account.
 :::
 
-## DeFi on Bitcoin (and other non-smart contract chains). 
+## DeFi on Bitcoin (and other non-smart contract chains).
 
 Using chain signatures, smart contracts on NEAR can control externally-owned accounts on non-smart contract chains like Bitcoin, Dogecoin, XRP Ledger, Bittensor, Cosmos Hub, etc. This enables developers to use NEAR as a smart contract “layer” for chains that do not support this functionality natively.
 

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-07-18.md

@@ -0,0 +1,51 @@
+---
+title: An update on the near.org / RPC outage on July 11, 2024
+authors: [ewiner]
+slug: 2024-07-11-near-org-outage
+tags: [updates, postmortems]
+hide_table_of_contents: true
+---
+
+From Thursday, July 11 to Saturday, July 13, many visitors to [near.org](https://near.org) and its subdomains (like [dev.near.org](https://dev.near.org) and [docs.near.org](https://docs.near.org/)) were unable to reach those websites. Also, NEAR applications that rely on [RPC services](https://docs.near.org/api/rpc/providers) hosted on near.org were affected. This was due to a security incident followed by an outage from one of our vendors, Squarespace. During this period, the NEAR protocol & blockchain was unaffected by this incident, as it does not rely on any centralized services.
+
+<!-- truncate -->
+
+### Our Use of Squarespace DNS
+
+The near.org domain is operated by [Pagoda](https://www.pagoda.co/), an engineering arm of the NEAR Foundation. An important part of operating a domain like near.org is choosing a DNS provider; to learn more about DNS and how it operates, please see [this introduction](https://www.cloudflare.com/learning/dns/what-is-dns/). For years, we happily used Google’s domain name registration & DNS service to manage near.org, as part of our broad usage of Google Cloud services. In June 2023, Google announced it had [sold its Domains business to Squarespace](https://support.google.com/domains/answer/13689670?hl=en), and that our account would be transitioned to Squarespace “in the next few months.” We expected that the new service from Squarespace would closely match the feature set, reliability, and security we had enjoyed while using Google Domains, and if there were any problems then we could easily switch from Squarespace to another DNS provider after the transition.
+
+Our first domain, near.wiki, was automatically moved over to Squarespace in May 2024. As we explored the new offering, our Security & IT teams quickly had concerns about the feature set, security controls, and level of enterprise support we could get from Squarespace. After some meetings with Squarespace sales and support failed to assuage our concerns, we decided to explore other DNS providers and to start migrating our domains off of Squarespace, starting with the ‘simpler’ ones and ending with near.org, our most complex and important domain name. As of last week, when this incident began, we had not yet begun migrating near.org to our new provider, Amazon Web Services, so it was still using Squarespace as its DNS provider.
+
+
+### The Squarespace Security Incident
+
+Unbeknownst to us, Squarespace had a major security vulnerability. You can read about the problem in [this in-depth blog post from Security Alliance](https://securityalliance.notion.site/A-Squarespace-Retrospective-or-How-to-Coordinate-an-Industry-Wide-Incident-Response-fead693b66c14543a48283d85aec19ad). In short, when each domain was migrated from Google to Squarespace, all existing users on the Google Domains account were sent an email inviting them to create a new Squarespace account. But not everybody clicked on that email right away – some people, e.g. managers or our accounting team, only needed to log into the DNS service rarely or in emergencies. From what we can tell, all the attacker needed to do was identify one of those email addresses and sign up for a new Squarespace account using that email address, and they would be instantly granted full access to change or delete DNS entries for near.org. From our investigation, Squarespace did not require the attacker to verify ownership of the email address before letting them have full control on our account. In fact, we see no evidence that Squarespace even sent a “welcome” email to that address upon account creation, which might have raised warning flags.
+
+On July 11, an attacker gained access to our Squarespace account. They deleted the DNS entries for near.org and its subdomains, causing the outage described above. But unlike some other domains affected by this attack, the impact on near.org seems limited to an outage; we have seen no evidence that the attacker put in place an ‘imposter’ site to try and phish or scam users.
+
+Through a combination of our actions and Squarespace’s actions behind the scenes, we were able to quickly regain control of the account. However, due to other issues with Squarespace, it took another two days for near.org and its subdomains and services to get fully back online.
+
+
+### The Squarespace Outage
+
+Even with full and exclusive access to our Squarespace, we were unable to restore service on near.org. The attacker had deleted our DNS entries, and when we re-added them, Squarespace failed to propagate those new entries to other DNS providers around the world. We attempted to quickly execute a switch to Amazon Web Service’s DNS provider, but the feature to switch to a different DNS service was also broken on the Squarespace site.
+
+The next morning, on Friday July 12, on a hunch we deleted and re-added all of our DNS entries once again. This time, it did take effect and DNS providers around the world quickly saw the new information. That resolved the outage for many users, but not for everyone. near.org had been set up with an additional security feature, DNSSEC, in which Squarespace was supposed to digitally sign our DNS entries to prove that the entries had not been forged by another DNS provider. But Squarespace wasn’t properly updating and signing new DNSSEC entries, so any other DNS provider that validates DNSSEC was detecting near.org’s DNS entries as a forgery and refusing to allow access to near.org. This affected [approximately 34% of users](https://stats.labs.apnic.net/dnssec), especially in Europe. There is a button on the Squarespace site to turn off DNSSEC, but unsurprisingly, that button also just showed an error message.
+
+Finally, on Saturday July 13, we were able to make contact with a specialist on the Squarespace team, and later that day they were able to fix the DNSSEC issue. Once that change propagated to other DNS providers around the world over the next few hours, near.org and the RPC service was restored for everyone.
+
+
+### Reflections on this Incident
+
+You may have noticed that we made a few assumptions in this blog post, saying “from what we can tell” and “we see no evidence of…” a few times. Ideally, almost a week after the incident began, we would have more hard truths and solid information about what happened.
+
+Unfortunately, we’ve seen little to no communication from Squarespace throughout this period. We tried multiple support tickets, chat, personal contacts, LinkedIn messages, and going through our Google support team, and still didn’t hear anything back from Squarespace until late on Friday July 12, about 36 hours after the incident began. Other affected companies also reported total silence from the Squarespace team. As far as we know, Squarespace has still not acknowledged this incident publicly, let alone shared details of the issue and how they remediated it, and their [status page](https://status.squarespace.com/) showed no outages or issues during this time.
+
+I personally find this lack of support, communication, and forthrightness to be unacceptable for any service provider. I’m also somewhat disappointed in Google for transitioning a security-critical service to a new provider without proper vetting. We are accelerating our plans to move near.org and other domains out of Squarespace to Amazon Web Services’s domain registrar and DNS provider, which has a great track record of reliability and security.
+
+DNS is a core part of internet infrastructure, but it’s far from a perfect system. Every domain name owner must rely on one centralized DNS provider to maintain their DNS entries, and every user and application must rely on one or more centralized DNS providers to look up entries as they navigate the internet. Various projects in the blockchain industry have created non-custodial on-chain alternatives to DNS, such as [Unstoppable Domains](https://unstoppabledomains.com/) and [3DNS](https://3dns.box/) (FYI: neither have sponsored or were made aware of this post), but the existing DNS system is so entrenched that adoption has been a challenge. Hopefully as an industry we can make headway on a more decentralized, trustless open web before further incidents like this happen.
+
+I’m deeply sorry to anyone affected by this outage, especially people exploring NEAR for the first time during the EthCC conference and EthGlobal hackathon. We will be more vigilant about using high-quality vendor services going forward – and, where possible, moving to decentralized on-chain solutions.
+
+-Eric Winer<br />
+CTO & Managing Director, Pagoda

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.

blog/authors.yml

@@ -21,3 +21,9 @@ bucanero:
   title: Docs Maintainer
   url: https://github.com/bucanero
   image_url: https://github.com/bucanero.png
+
+ewiner:
+  name: Eric Winer
+  title: CTO & Managing Director, Pagoda
+  url: https://github.com/ewiner
+  image_url: https://github.com/ewiner.png

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).