Remove Channels FAQs

src/pages/docs/auth/capabilities.mdx

@@ -49,6 +49,18 @@ The following capability operations are available for API keys and issued tokens
 
 Although most capabilities need to be enabled for the resource you're using them with, there are exceptions. The `stats` permission only does something when attached to the wildcard resource `'*'`, or a resource that contains that as a subset, such as `'[*]*'`, since stats are app-wide.
 
+## Channel access control <a id="access-control"/>
+
+Ably does not provide numeric limits on channel access. Control channel access using token authentication and capabilities.
+
+Channel access is controlled through:
+
+* [Token authentication](/docs/auth/token) to restrict access by issuing tokens with specific capabilities to authorized users
+* Specific `clientId` values in tokens to ensure only certain users can access particular channels
+* Granting or restricting specific operations (`subscribe`, `publish`, `presence`) on channels through capability configurations
+
+For private messaging or group chats, design channel naming strategies and use token authentication to ensure users receive tokens with access only to relevant channels.
+
 The `channel-metadata` permission works both ways. When associated with a specific channel or set of channels it allows you to [query the metadata of a channel](/docs/metadata-stats/metadata/rest) to request its status. When associated with the wildcard resource `'*'` it takes on an additional meaning: as well as allowing channel status requests for all channels, it also allows you to [enumerate all active channels](/docs/metadata-stats/metadata/rest#enumerate).
 
 <Aside data-type='note'>

src/pages/docs/messages/index.mdx

@@ -34,6 +34,12 @@ The following are the properties of a message:
 | **extras** | A JSON object of arbitrary key-value pairs that may contain metadata, and/or ancillary payloads. Valid payloads include those related to [Push Notifications](/docs/push), [deltas](/docs/channels/options/deltas) and headers |
 | **encoding** | This is typically empty, as all messages received from Ably are automatically decoded client-side using this value. However, if the message encoding cannot be processed, this attribute contains the remaining transformations not applied to the data payload |
 
+## Message delivery tracking <a id="delivery-tracking"/>
+
+Ensure a message was successfully published by checking the [history](/docs/storage-history/history) of the channel for your message. It is only possible to check if a device has received a message from the device itself.
+
+Ably does not store per-message delivery logs, nor logs of who is subscribed to a channel at any point in time. This means it is not possible to check which users have received messages retroactively.
+
 ## Message conflation <a id="conflation"/>
 
 Use message conflation to ensure that clients only ever receive the most up-to-date message, by removing redundant and outdated messages. Message conflation will aggregate published messages for a set period of time and evaluate all messages against a [conflation key](#routing). All but the latest message for each conflation key value will be discarded, and the resulting message, or messages, will be delivered to subscribers as a single batch once the period of time elapses.

src/pages/docs/metadata-stats/metadata/subscribe.mdx

@@ -56,6 +56,12 @@ The following events are published to `[meta]channel.lifecycle`:
 
 The `data` property of all events is a [`ChannelDetails`](/docs/api/realtime-sdk/channel-metadata#channel-details) object. The [`ChannelDetails.ChannelStatus`](/docs/api/realtime-sdk/channel-metadata#channel-status) which includes [occupancy](/docs/presence-occupancy/occupancy) details varies depending on the event. If the event is specific to a region, such as `channel.region.active` then the occupancy metrics will only be for that region. For other events such as `channel.opened`, the occupancy metrics will be global.
 
+### Understanding regional channel activity
+
+Seeing `channel.region.inactive` events in your [Dev Console](/docs/platform/account/app/console) logs is normal behavior. Channels become active in different regions globally according to where clients are located and Ably's internal placement rules. 
+
+A `channel.region.inactive` event indicates that a channel no longer has any clients in that specific region, or that the channel is shutting down altogether. This is part of Ably's normal operation to efficiently manage resources across its global infrastructure.
+
 The following is an example of subscribing to all `[meta]channel.lifecycle` events:
 
 <Code>

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

@@ -24,6 +24,18 @@ The following explains the realtime monitoring tools in the application-wide eve
 | **Average application-wide events per second (p/s)** | This metric shows the average number of events occurring per second across your application. For example, if the current rate is 0, no active events are being processed. |
 | **Event log table** | The event log table displays a record of events related to the current client's connection status. This table can be used to debug potential issues in your application. |
 
+## Message auditing and logging <a id="message-auditing"/>
+
+The dev console displays messages in realtime for debugging and testing purposes, but does not provide persistent message auditing or logging capabilities. Ably does not currently offer native functionality to view historical messages filtered by specific channels or client IDs for auditing purposes.
+
+If you need to audit or log messages by channel or client ID, implement this functionality on the application side. Consider using:
+
+- [Webhooks](/docs/platform/integrations/webhooks) to send message events to your logging system
+- [Message queues](/docs/platform/integrations/queues) to process and store message data
+- Client-side logging in your application code
+
+For native message auditing features, [contact support](mailto:[email protected]) to discuss requirements.
+
 ## Channels
 
 The following is a step-by-step instructions for connecting to a channel, publishing messages.

src/pages/docs/platform/architecture/message-ordering.mdx

@@ -58,3 +58,26 @@ When building globally distributed applications, developers should understand th
 The dual ordering system allows applications to choose the appropriate consistency model for their needs. For highly interactive applications where responsiveness is critical, realtime order minimizes latency. For applications that require a consistent historical record, the canonical global order provides a stable view that all components can agree on.
 
 To support both ordering systems efficiently, messages are stored with metadata that tracks their position in multiple sequences. This allows the platform to rapidly retrieve messages in either realtime or canonical global order as needed for different API operations or connection recovery scenarios.
+
+## Message ordering guarantees <a id="ordering-guarantees"/>
+
+Ably delivers messages to persistently connected subscribers on a channel in the order they were published when using the Realtime libraries. Each message sent on a realtime connection has a unique incrementing serial number, enabling this ordering guarantee.
+
+If you publish messages using a Realtime client library, subscribers on that channel anywhere in the world will receive those messages in the same order they were originally published.
+
+### REST publishing considerations <a id="rest-considerations"/>
+
+When publishing using REST client libraries, Ably still guarantees that the order messages are received will be honoured for all subscribers. However, if you are sending messages at a high rate with separate REST requests, it is possible that a later HTTP request may reach Ably before a previous request due to variable network factors outside of Ably's control.
+
+If ordering is important when using REST, consider these approaches:
+- Rate limit your HTTP requests.
+- [Batch messages](/docs/messages/batch) together in a single request.
+- Use Realtime to publish messages instead.
+
+### Connection recovery edge cases <a id="recovery-edge-cases"/>
+
+Ably supports connection state recovery, so even if a connection is lost and re-established, messages replayed when reconnected will be in sequential order.
+
+However, there is a rare situation where ordering may not be maintained: if a client is disconnected and the server maintaining that client's connection state is terminated or recycled during connection state recovery, messages may potentially be replayed out of order. This behavior is by design to ensure that the backlog of messages held in the connection state do not prevent the new server from sending realtime messages to clients.
+
+If message ordering is required in all cases, consider catching the connection disconnected event and either re-establishing a new connection or manually re-ordering incoming messages following disconnection.

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

@@ -13,9 +13,9 @@ FAQs related to package costs and package billing.
 
 ### When and how often am I billed? <a id="billing-time"/>
 
-Your usage is calculated on the last day of the month. Invoices are issued in arrears on the 1st of the following month.
+Usage is calculated on the last day of the month. Invoices are issued in arrears on the 1st of the following month.
 
-If you upgraded in the middle of the month then the base package price will be charged pro-rata from the point in the month that you upgraded.
+Mid-month upgrades are charged pro-rata from the upgrade date.
 
 Package downgrades take effect on the 1st of the following month.
 
@@ -27,11 +27,11 @@ FAQs related to pricing concepts and package limits.
 
 ### How do you count concurrent connections? <a id="concurrent-connections"/>
 
-The [limit](/docs/platform/pricing/limits#connection) on concurrent connections is for the maximum number of realtime clients [connected](/docs/connect) to Ably simultaneously at any point in time. HTTP requests such as those from REST clients do not count towards this number, as it is solely related to realtime connections.
+The [limit](/docs/platform/pricing/limits#connection) on concurrent connections is the maximum number of realtime clients [connected](/docs/connect) to Ably simultaneously at any point in time. HTTP requests from REST clients do not count towards this number.
 
 ### How do you count concurrent channels? <a id="concurrent-channels"/>
 
-The [limit](/docs/platform/pricing/limits#channel) on concurrent channels is for the maximum number of channels that are active simultaneously at any point in time.
+The [limit](/docs/platform/pricing/limits#channel) on concurrent channels is the maximum number of channels active simultaneously at any point in time.
 
 [Channels](/docs/channels) are opened when either a message is published on the channel using a REST client, or a realtime client attaches to the channel. They are considered active until the channel is closed.
 
@@ -41,7 +41,7 @@ For example, if you have 10,000 users, and at your busiest time of the month the
 
 ### How is maximum message size measured? <a id="message-size"/>
 
-The maximum message size is based on the [package type](/docs/pricing#packages). The size is calculated as the sum of the `name`, `clientId`, `data` and `extras` [properties](/docs/api/realtime-sdk/messages#properties). This is before any compression or expansion occurs in the serialization process.
+Maximum message size is based on the [package type](/docs/pricing#packages). The size is calculated as the sum of the `name`, `clientId`, `data` and `extras` [properties](/docs/api/realtime-sdk/messages#properties) before any compression or expansion occurs in the serialization process.
 
 * `name` and `clientId` are calculated as the size in bytes of their UTF-8 representation.
 * `data` is calculated as the size in bytes if it is in binary, or its UTF-8 byte length if it is a string.
@@ -55,7 +55,7 @@ If [publishing](/docs/api/realtime-sdk/channels#publish) an array of messages, t
 
 The effect of exceeding a [limit](/docs/platform/pricing/limits) differs depending on the limit.
 
-In most cases, if you exceed a limit then it means that your app is performing well. Ably won't penalize your success by blocking usage on your account for most limits. Normal service will continue to function, up to a point, beyond the limit. You would have received a notification of nearing a limit, and will receive another notification alerting you to the need to upgrade your package to accommodate your increased usage.
+In most cases, exceeding a limit means that an app is performing well. Ably won't penalize success by blocking usage on accounts for most limits. Normal service will continue to function, up to a point, beyond the limit. Notifications are sent when nearing a limit, and again when you need to upgrade your package to accommodate increased usage.
 
 Limits will come into force either because there isn't any buffer on them, or because you have exceeded the buffer. Exceeding the limit depends on the limit:
 
@@ -76,15 +76,15 @@ Yes. [Enterprise packages](/docs/platform/pricing/enterprise) can include the ab
 
 ### Does Ably have a GDPR (General Data Protection Regulation) DPA (Data Processing Agreement) to sign? <a id="gdpr"/>
 
-No. This is not necessary as Ably's online Terms incorporate everything that is required within a DPA document. This means that all customers globally can rely on Ably's [standard terms](https://www.ably.io/terms) which include the provisions for GDPR DPA, and which will apply automatically whenever they use AWS (Amazon Web Services) services to process personal data under the GDPR. By incorporating our GDPR DPA into the Ably Service Terms, we are simply extending the terms of our GDPR DPA to all customers globally who will require it under GDPR. Note that you can review the changes to our terms to incorporate GDPR requirements by reviewing our [legals audit trail](https://www.ably.io/legals) from 29 March 2018.
+No. This is not necessary as Ably's online Terms incorporate everything required within a DPA document. All customers globally can rely on Ably's [standard terms](https://www.ably.io/terms) which include the provisions for GDPR DPA, and which apply automatically when using AWS (Amazon Web Services) services to process personal data under the GDPR. By incorporating the GDPR DPA into the Ably Service Terms, the terms of the GDPR DPA extend to all customers globally who require it under GDPR. You can review the changes to the terms to incorporate GDPR requirements by reviewing the [legals audit trail](https://www.ably.io/legals) from 29 March 2018.
 
 ### Is Ably compliant with HIPAA (Health Insurance Portability and Accountability Act)? <a id="hipaa"/>
 
-The following information outlines Ably's compliance with the US HIPAA Security Rule. If you require further information then [contact us](https://ably.com/contact) to find out more.
+The following information outlines Ably's compliance with the US HIPAA Security Rule. For further information, [contact us](https://ably.com/contact).
 
 #### Is Ably a 'covered entity' which is required to comply with the HIPAA Security Rule?
 
-No. The HIPAA Security Rule operationalizes the protections contained in the HIPAA Privacy Rule by addressing the technical and non-technical safeguards that organizations called 'covered entities' must put in place to secure individuals' electronic protected health information (e-PHI).
+No. The HIPAA Security Rule operationalizes the protections contained in the HIPAA Privacy Rule by addressing the technical and non-technical safeguards that 'covered entities' must put in place to secure individuals' electronic protected health information (e-PHI).
 
 Covered entities include Health Plans, Health Care Providers and Healthcare Clearinghouses.
 
@@ -110,7 +110,7 @@ Whilst Ably may be used by covered entities to transport individually identifiab
 
 As a transport for information Ably does not know the nature of the data we are handling. It is possible for our customers, who may be covered entities under HIPAA, to transport individually identifiable health information. However, Ably cannot inspect that data so there is no access to protected health information and any such access would be incidental, if at all.
 
-Under HIPAA there are no restrictions on the use or disclosure of de-identified health information which neither identifies nor provides a reasonable basis to identify an individual. So where Ably customers, even covered entities, are using Ably only to transport de-identified health information, then HIPAA does not apply.
+Under HIPAA there are no restrictions on the use or disclosure of de-identified health information which neither identifies nor provides a reasonable basis to identify an individual. Where Ably customers, even covered entities, use Ably only to transport de-identified health information, HIPAA does not apply.
 
 #### What level of data encryption does Ably use?
 
@@ -120,7 +120,7 @@ Ably also offers optional 256-bit AES symmetric encryption which makes it imposs
 
 #### Where is data going through the Ably platform stored?
 
-Data in transit is stored ephemerally (i.e. not on disk) in all 16+ data centres [globally](https://www.ably.io/network). Each region can have two or more data centres.
+Data in transit is stored ephemerally (not on disk) in all 16+ data centres [globally](https://www.ably.io/network). Each region can have two or more data centres.
 
 Messages are only persisted when history is [explicitly enabled](/docs/storage-history/storage), and that data is stored in US East Virginia, Europe Ireland, and Asia Singapore.
 
@@ -132,7 +132,7 @@ Under HIPAA, any covered entity must impose specified written safeguards on the
 
 As per the points above Ably is neither a covered entity nor a business associate under the terms of the HIPAA Security Rule.
 
-However, some customers still like Ably to sign a business associate agreement which requires Ably to comply with specified safeguards.
+Some customers still like Ably to sign a business associate agreement which requires Ably to comply with specified safeguards.
 
 In most cases, Ably is happy to do this as we have such safeguards in place as a matter of course and most business associate agreements are standard. We also recognize that an Ably customer, if a covered entity, may not contractually authorize Ably to make any use or disclosure of protected health information that would violate the Security Rule.
 
@@ -144,17 +144,17 @@ FAQs related to managing your Ably package.
 
 ### How does the Free package work? <a id="free"/>
 
-The [Free package](/docs/platform/pricing/free) is a zero friction way for you to explore Ably and its features without any commitment. No credit card is required to sign up and there's no time limit on how long you can try it for.
+The [Free package](/docs/platform/pricing/free) is a zero friction way to explore Ably and its features without any commitment. No credit card is required to sign up and there's no time limit.
 
-Once you need production-level scale then there's a simple path to upgrade to a subscription-based plan such as a [Standard](/docs/platform/pricing/standard) or [Pro](/docs/platform/pricing/pro) package.
+Once production-level scale is needed, there's a simple path to upgrade to a subscription-based plan such as a [Standard](/docs/platform/pricing/standard) or [Pro](/docs/platform/pricing/pro) package.
 
 ### Can I upgrade or downgrade my package at any time? <a id="change-package"/>
 
 Yes.
 
 1. Ensure you are the [account owner](/docs/platform/account/users).
-2. Log in to your [account](https://ably.com/login) and select **Billing** from the **Account** menu.
-3. Select the package that you would like to upgrade or downgrade to.
+2. Log in to your [account](https://ably.com/login) and select Billing from the Account menu.
+3. Select the package to upgrade or downgrade to.
 
 Upgrades take effect immediately, whilst downgrades will take effect at the beginning of the following month.