feat(docs): Nits

docs/docs/aztec/concepts/accounts/index.md

@@ -35,7 +35,7 @@ Instead of implementing it at the protocol level as in Aztec, account abstractio
 
 A simple example would be Gnosis Safe (see [_Account Abstraction is NOT coming_](https://safe.mirror.xyz/9KmZjEbFkmI79s28d9xar6JWYrE50F5AHpa5CR12YGI)), where it's the multisig contract responsibility to define when an execution request is valid by checking it carries N out of M signatures, and then executing it. [Argent](https://www.argent.xyz/blog/wtf-is-account-abstraction/) has also been working on smart wallets for years, and collaborating with network teams to implement AA natively at the protocol layer.
 
-Ethereum is currently following this approach via [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), an evolution of the [GSN](https://opengsn.org/). This EIP defines a standard method for relaying meta-transactions in a decentralized way, including options for delegating payment to other agents (called paymasters). See [this chart](https://twitter.com/koeppelmann/status/1632257610455089154) on how 4337 relates to other smart contract wallet efforts.
+Ethereum is currently following this approach via [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), an evolution of the [GSN](https://opengsn.org/). This EIP defines a standard method for relaying meta-transactions in a decentralized way, including options for delegating payment to other agents (called paymasters). See [this chart](https://x.com/koeppelmann/status/1632257610455089154) on how 4337 relates to other smart contract wallet efforts.
 
 Implementing AA at the application layer has the main drawback that it's more complex than doing so at the protocol layer. It also leads to duplicated efforts in both layers (eg the wrapper transaction in a meta-transactions still needs to be checked for its ECDSA signature, and then the smart contract wallet needs to verify another set of signatures).
 

docs/docs/protocol-specs/cryptography/proving-system/overview.md

@@ -90,7 +90,7 @@ When passing data between successive IVC steps, the canonical method is to do so
 
 The Data Bus protocol eliminates this cost by representing cross-step data via succinct commitments instead of raw field elements.
 
-The [Plonk Data Bus](https://aztecprotocol.slack.com/files/U8Q1VAX6Y/F05G2B971FY/plonk_bus.pdf) protocol enables efficient data transfer between two Honk instances within a larger IVC protocol.
+The Plonk Data Bus protocol enables efficient data transfer between two Honk instances within a larger IVC protocol.
 
 # Polynomial Commitment Schemes
 

docs/docs/protocol-specs/data-publication-and-availability/overview.md

@@ -30,7 +30,7 @@ From distributed systems, the _security_ of a protocol or system is defined by:
 :::
 
 In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node.
-For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)):
+For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://x.com/sreeramkannan/status/1683735050897207296)):
 
 - **Liveness**:
   - Data Availability - The chain data must be available for anyone to reconstruct the state and build blocks
@@ -318,5 +318,5 @@ Of these, Celestia has the current best "out-the-box" solution, but Eigen-da and
 - https://forum.celestia.org/t/security-levels-for-data-availability-for-light-nodes/919
 - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541
 - https://jumpcrypto.com/writing/bridging-and-finality-ethereum/
-- https://twitter.com/sreeramkannan/status/1683735050897207296
+- https://x.com/sreeramkannan/status/1683735050897207296
 - https://blog.celestia.org/introducing-blobstream/

docs/docs/reference/developer_references/limitations.md

@@ -54,7 +54,7 @@ That's right, the Sandbox doesn't actually generate or verify any zk-SNARKs yet!
 
 The main goal of the Sandbox is to enable developers to experiment with building apps, and hopefully to provide feedback. We want the developer experience to be as fast as possible, much like how Ethereum developers use Ganache or Anvil to get super-fast block times, instead of the slow-but-realistic 12-second block times that they'll encounter in production. A fast Sandbox enables fast testing, which enables developers to iterate quickly.
 
-That's not to say a super-fast proving system isn't being worked on [as we speak](../../aztec/roadmap/cryptography_roadmap.md).
+That's not to say a super-fast proving system isn't being worked on as we speak.
 
 #### What are the consequences?
 

docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md

@@ -195,7 +195,7 @@ Copy the last function into your Crowdfunding contract:
 
 You should be able to compile successfully with `aztec-nargo compile`. 
 
-**Congraulations,** you have just built a multi-contract project on Aztec!
+**Congratulations,** you have just built a multi-contract project on Aztec!
 
 ## Conclusion
 

docs/docusaurus.config.js

@@ -290,14 +290,14 @@ const config = {
               {
                 type: "docSidebar",
                 sidebarId: "protocolSpecSidebar",
-                target: "_blank",
                 label: "Protocol Specification",
+                className: "no-external-icon",
               },
               {
                 type: "docSidebar",
                 sidebarId: "roadmapSidebar",
-                target: "_blank",
                 label: "Roadmap",
+                className: "no-external-icon",
               },
               {
                 to: "https://noir-lang.org/docs",
@@ -317,7 +317,7 @@ const config = {
                 rel: "noopener noreferrer",
               },
               {
-                to: "https://twitter.com/aztecprotocol",
+                to: "https://x.com/aztecnetwork",
                 label: "X/Twitter",
                 target: "_blank",
                 rel: "noopener noreferrer",
@@ -359,8 +359,8 @@ const config = {
                 href: "https://discord.gg/DgWG2DBMyB",
               },
               {
-                label: "X/Twitter",
-                href: "https://twitter.com/aztecnetwork",
+                label: "X (Twitter)",
+                href: "https://x.com/aztecnetwork",
               },
               {
                 label: "Plonk Cafe",