fix docs about history meta ttl, more clarifications

docs/server/channels.md

@@ -228,6 +228,8 @@ By default history TTL duration is zero – this means that channel history is d
 
 **Again – to turn on history you should wisely configure both `history_size` and `history_ttl` options**.
 
+Also note, that `history_ttl` must be less than [history_meta_ttl](#history_meta_ttl).
+
 For example for top-level channels (which do not belong to a namespace):
 
 ```json title="config.json"
@@ -282,9 +284,9 @@ History persistence properties are dictated by Centrifugo [engine](./engines.md)
 
 `history_meta_ttl` ([duration](./configuration.md#setting-time-duration-options)) – sets a time of history stream metadata expiration (with seconds precision).
 
-When using a history in a channel, Centrifugo keeps some metadata for each channel stream. Metadata includes the latest stream offset and its epoch value. In some cases, when channels are created for а short time and then not used anymore, created metadata can stay in memory while not useful. For example, you can have a personal user channel but after using your app for a while user left it forever. From a long-term perspective, this can be an unwanted memory growth. Setting a reasonable value to this option can help to expire metadata faster (or slower if you need it). The rule of thumb here is to keep this value much bigger than maximum history TTL used in Centrifugo configuration.
+If not specified Centrifugo namespace inherits value from `global_history_meta_ttl` ([duration](./configuration.md#setting-time-duration-options)) option which is 30 days by default. This should be a good default for most use cases to avoid tweaking `history_meta_ttl` on a namespace level at all. If you have `history_ttl` greater than 30 days – then increase `history_meta_ttl` for namespace (recommended) or increase `global_history_meta_ttl` to be larger than `history_ttl`.
 
-If not specified Centrifugo uses a global `history_meta_ttl` which is 30 days. This should be a good default for most use cases to avoid tweaking `history_meta_ttl` on a namespace level at all.
+The motivation to have history meta information TTL is as follows. When using a history in a channel, Centrifugo keeps some metadata for each channel stream. Metadata includes the latest stream offset and its epoch value. In some cases, when channels are created for а short time and then not used anymore, created metadata can stay in memory while not useful. For example, you can have a personal user channel but after using your app for a while user left it forever. From a long-term perspective, this can be an unwanted memory growth. Setting a reasonable value to this option can help to expire metadata faster (or slower if you need it). The rule of thumb here is to keep this value larger than history TTL used.
 
 ### force_positioning
 

docs/server/engines.md

@@ -36,16 +36,6 @@ Disadvantages:
 * Does not allow scaling nodes (actually you still can scale Centrifugo with Memory engine but you have to publish data into each Centrifugo node and you won't have consistent history and presence state throughout Centrifugo nodes)
 * Does not persist message history in channels between Centrifugo restarts.
 
-### Memory engine options
-
-#### history_meta_ttl
-
-[Duration](../server/configuration.md#setting-time-duration-options), default `2160h` (90 days).
-
-`history_meta_ttl` sets a time of history stream metadata expiration. 
-
-When using a history in a channel, Centrifugo keeps some metadata for it. Metadata includes the latest stream offset and its epoch value. In some cases, when channels are created for а short time and then not used anymore, created metadata can stay in memory while not useful. For example, you can have a personal user channel but after using your app for a while user left it forever. From a long-term perspective, this can be an unwanted memory growth. Setting a reasonable value to this option can help to expire metadata faster (or slower if you need it). The rule of thumb here is to keep this value much bigger than maximum history TTL used in Centrifugo configuration.
-
 ## Redis engine
 
 [Redis](https://redis.io/) is an open-source, in-memory data structure store, used as a database, cache, and message broker.
@@ -90,16 +80,6 @@ Boolean, default `false` – turns on using Redis Lists instead of Stream data s
 
 Boolean, default `false`. If set to true it forces using RESP2 protocol for communicating with Redis. By default, Redis client used by Centrifugo tries to detect supported Redis protocol automatically trying RESP3 first.
 
-#### history_meta_ttl
-
-[Duration](../server/configuration.md#setting-time-duration-options), default `2160h` (90 days).
-
-`history_meta_ttl` sets a time of history stream metadata expiration. 
-
-Similar to a Memory engine Redis engine also looks at `history_meta_ttl` option. Meta key in Redis is a HASH that contains the current offset number in channel and the stream epoch value.
-
-When using a history in a channel, Centrifugo saves metadata for it. Metadata includes the latest stream offset and its epoch value. In some cases, when channels are created for а short time and then not used anymore, created metadata can stay in memory while not useful. For example, you can have a personal user channel but after using your app for a while user left it forever. From a long-term perspective, this can be an unwanted memory growth. Setting a reasonable value to this option can help. The rule of thumb here is to keep this value much bigger than maximum history TTL used in Centrifugo configuration.
-
 ### Configuring Redis TLS
 
 Some options may help you configuring TLS-protected communication between Centrifugo and Redis. 
@@ -457,12 +437,6 @@ String, default `""`. Allows setting a user.
 
 String, default `""`. Allows setting a password.
 
-#### history_meta_ttl
-
-[Duration](../server/configuration.md#setting-time-duration-options), default `2160h`.
-
-Same option as for Memory engine and Redis engine also applies to Tarantool case.
-
 ## Nats broker
 
 It's possible to scale with [Nats](https://nats.io/) PUB/SUB server. Keep in mind, that Nats is called a **broker** here, **not an Engine** – Nats integration only implements PUB/SUB part of Engine, so carefully read limitations below.