Scrub HS from docs (#740)

* Scrub HS from docs

* Ida's feedback

website/pages/en/about.mdx

@@ -20,7 +20,7 @@ You could also build out your own server, process the transactions there, save t
 
 Blockchain properties like finality, chain reorganizations, or uncled blocks complicate this process further. They make it time consuming and conceptually hard to retrieve correct query results from blockchain data.
 
-The Graph provides a solution with a decentralized protocol that indexes and enables the efficient and high-performance querying of blockchain data. These APIs (indexed "subgraphs") can then be queried with a standard GraphQL API. Today, there is a hosted service as well as a decentralized protocol with the same capabilities. Both are backed by the open source implementation of [Graph Node](https://github.com/graphprotocol/graph-node).
+The Graph provides a solution with a decentralized protocol that indexes and enables the efficient and high-performance querying of blockchain data. These APIs (indexed "subgraphs") can then be queried with a standard GraphQL API.
 
 ## How The Graph Works
 

website/pages/en/chain-integration-overview.mdx

@@ -46,4 +46,4 @@ Protocol support for indexing rewards depends on the stakeholders' bandwidth to
 
 ### 4. How will priorities be handled?
 
-Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process. This is especially true for chains previously supported on the [hosted service](https://thegraph.com/hosted-service) or those relying on already tested stacks.
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

website/pages/en/cookbook/grafting.mdx

@@ -30,7 +30,7 @@ In this tutorial, we will be covering a basic usecase. We will replace an existi
 
 ### Why Is This Important?
 
-Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. While this is an effective way to preserve data and save time on indexing, grafting may introduce complexities and potential issues when migrating from a hosted environment to the decentralized network. It is not possible to graft a subgraph from The Graph Network back to the hosted service or Subgraph Studio.
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
 
 ### Best Practices
 

website/pages/en/cookbook/subgraph-uncrashable.mdx

@@ -18,7 +18,7 @@ title: Safe Subgraph Code Generator
 
 - The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
 
-- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy. These logs can be viewed in the The Graph's hosted service under the 'Logs' section.
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
 
 Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.