Addresses reviewer feedback

Author: franrob-projects

src/data/nav/platform.ts

@@ -133,10 +133,6 @@ export default {
           link: '/docs/platform/pricing/faqs',
           name: 'Pricing FAQs',
         },
-        {
-          link: '/docs/platform/pricing/terms-faqs',
-          name: 'Legal terms FAQ',
-        },
       ],
     },
     {

src/pages/docs/basics/index.mdx

@@ -65,15 +65,6 @@ The REST interface communicates with Ably using the HTTP protocol and is effecti
 * issue tokens on behalf of other realtime clients
 * retrieve persisted messages, presence history and application usage statistics
 
-#### Implementing realtime features with REST-only SDKs <a id="rest-realtime-alternatives"/>
-
-If you're working with REST-only SDKs or environments where realtime connections aren't available, you can still implement realtime functionality using these alternatives:
-
-1. **[MQTT protocol adapter](/docs/protocols/mqtt)** - Translates between MQTT and Ably's protocol, ideal for IoT devices and constrained environments
-2. **[PubNub protocol adapter](/docs/protocols/pubnub)** - Use existing PubNub SDKs with Ably for easy migration
-3. **[Ably queues](/docs/platform/integrations/queues)** - Consume realtime data server-side using AMQP or STOMP protocols
-
-These solutions enable you to subscribe to and process realtime messages without maintaining persistent connections through Ably SDKs.
 
 ### Realtime interface <a id="realtime"/>
 

src/pages/docs/chat/patterns/direct-messaging.mdx

@@ -35,7 +35,7 @@ For example, if you're building a product called "chat-app", you could create:
 This approach provides complete isolation between environments, ensuring that development activities don't interfere with production traffic. An alternative approach for complete resource isolation, consider using separate Ably accounts for development and production environments. This ensures development activities cannot impact production resources under any circumstances.
 
 <Aside data-type='important'>
-Account limits are shared. While apps are sandboxed from each other, they share the same account limits such as connection counts and channel limits. A development app experiencing high usage could potentially impact your production app if account limits are reached.
+Account limits are shared. While apps are sandboxed from each other, they share the same [account limits](/docs/platform/pricing/limits) such as connection counts and channel limits. A development app experiencing high usage could potentially impact your production app if account limits are reached.
 </Aside>
 
 ## App overview

src/pages/docs/platform/account/app/index.mdx

@@ -599,15 +599,6 @@ The request will be automatically retried by the SDK.
 
 **Resolution:** If the client never connects to the [primary or fallback endpoints](https://faqs.ably.com/routing-around-network-and-dns-issues), check any firewall rules that may be blocking access to Ably's [endpoints](https://faqs.ably.com/if-i-need-to-whitelist-ablys-servers-from-a-firewall-which-ports-ips-and/or-domains-should-i-add).
 
-**Network connectivity detection:** Ably SDKs use `https://internet-up.ably-realtime.com/is-the-internet-up.txt` to test network connectivity when connection attempts fail. If CSP policies block this endpoint, ensure your Content Security Policy includes:
-
-<Code>
-```
-Content-Security-Policy: connect-src https://internet-up.ably-realtime.com; script-src https://internet-up.ably-realtime.com
-```
-</Code>
-
-Blocking this resource causes clients to assume they're offline and prevents fallback host usage.
 
 ## 80016: Operation on superseded connection <a id="80016"/>
 

src/pages/docs/platform/errors/codes.mdx

@@ -43,9 +43,6 @@ Some of the integrations available with Ably include:
 
 Use Ably's products and SDKs to build realtime applications for your clients. They all utilize Ably's reliable platform to ensure that you don't need to worry about managing things such as scaling, latency and data integrity.
 
-<Aside data-type='note'>
-Ably is designed for realtime messaging, not media streaming or file transfer. However, you can use Ably as a signaling layer alongside [WebRTC](https://webrtc.org/) for video calls or CDN services for file sharing.
-</Aside>
 
 ### Ably Pub/Sub <a id="pub-sub"/>
 

src/pages/docs/platform/index.mdx

@@ -89,13 +89,6 @@ Channel limits relate to the number, rate and membership of [channels](/docs/cha
 | **Objects per channel**<p>*the maximum number of objects that can be stored on a channel*</p> | 100 | 100 | 100 | 100 |
 
 
-## Client identifier limits <a id="client-id"/>
-
-There is no limit to the length of a `clientId`, however, the clientId is counted as part of the message size and will contribute towards the total message size limits for your package.
-
-## Channel identifier limits <a id="channel-id"/>
-
-There is no strict limit to the length of channel names. Channel names must comply with the [channel naming restrictions](/docs/channels#use) regarding allowed characters and format.
 
 ## Connection limits <a id="connection"/>
 

src/pages/docs/platform/pricing/limits.mdx

@@ -437,27 +437,6 @@ if err := channel.Publish(context.Background(), "example", "message data"); err
 ```
 </Code>
 
-### REST publish timeouts <a id="rest-timeouts"/>
-
-REST publish operations have a default 10-second timeout. While you may consider reducing this timeout for faster failure feedback, be aware that this can create problems:
-
-Short timeouts can be problematic for the following reasons:
-
-- Most requests that exceed short timeouts, for example < 1s, still succeed with normal latency.
-- Retrying typically doesn't speed up message delivery and creates additional system load.
-- During high load or scaling operations, retry storms can worsen performance.
-- You'll miss important error notifications (rate limits, channel limits) if requests timeout prematurely.
-
-The default 10-second timeout is designed to:
-
-- Account for channel activation latency in multi-region deployments.
-- Handle network and processing queue variations.
-- Provide reliable error reporting for legitimate failures.
-
-When to consider timeout adjustments:
-
-- Use `httpOpenTimeout` (default 4s) for connection establishment issues, not `httpRequestTimeout` for the full request.
-- Only reduce request timeouts if you have robust retry logic and can handle increased system load.
 
 <Aside data-type="further-reading">
 You can find out more detail about how [channels](/docs/channels) and [messages](/docs/messages) work.