From e4c1be96fcac6ed5464c87f2cecde955c4f58b95 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Fri, 3 Apr 2026 16:03:49 -0500 Subject: [PATCH] Disabled by default --- crates/config/src/sections/experimental.rs | 5 ++++- docs/config.schema.json | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/crates/config/src/sections/experimental.rs b/crates/config/src/sections/experimental.rs index 1d1a76498..c55cd8823 100644 --- a/crates/config/src/sections/experimental.rs +++ b/crates/config/src/sections/experimental.rs @@ -150,13 +150,16 @@ pub struct SessionLimitConfig { /// Whether we should automatically choose the least recently used devices to remove /// when the [`hard_limit`] is reached; in order to allow the new login to continue. /// + /// Disabled by default + /// /// WARNING: Removing sessions is a potentially damaging operation. Any end-to-end /// encrypted history on the device will be lost and can only be recovered if you /// have another verified active device or have a recovery key setup. /// /// When using [`hard_limit_eviction`], the [`hard_limit`] must be at-least 2 to /// avoid catastropically losing encrypted history and digital identity in - /// pathological cases. + /// pathological cases. Keep in mind this is a bare minimum restriction and you can + /// still run into trouble. /// /// This is most applicable in scenarios where your homeserver has many legacy /// bots/scripts that login over and over (which ideally should be using [personal diff --git a/docs/config.schema.json b/docs/config.schema.json index 9c70e056f..34dc725f9 100644 --- a/docs/config.schema.json +++ b/docs/config.schema.json @@ -2910,7 +2910,7 @@ "minimum": 1 }, "hard_limit_eviction": { - "description": "Whether we should automatically choose the least recently used devices to remove\n when the [`hard_limit`] is reached; in order to allow the new login to continue.\n\n WARNING: Removing sessions is a potentially damaging operation. Any end-to-end\n encrypted history on the device will be lost and can only be recovered if you\n have another verified active device or have a recovery key setup.\n\n When using [`hard_limit_eviction`], the [`hard_limit`] must be at-least 2 to\n avoid catastropically losing encrypted history and digital identity in\n pathological cases.\n\n This is most applicable in scenarios where your homeserver has many legacy\n bots/scripts that login over and over (which ideally should be using [personal\n access\n tokens](https://github.com/element-hq/matrix-authentication-service/issues/4492))\n and you want to avoid breaking their operation while maintaining some level of\n sanity with the number of devices that people can have.", + "description": "Whether we should automatically choose the least recently used devices to remove\n when the [`hard_limit`] is reached; in order to allow the new login to continue.\n\n Disabled by default\n\n WARNING: Removing sessions is a potentially damaging operation. Any end-to-end\n encrypted history on the device will be lost and can only be recovered if you\n have another verified active device or have a recovery key setup.\n\n When using [`hard_limit_eviction`], the [`hard_limit`] must be at-least 2 to\n avoid catastropically losing encrypted history and digital identity in\n pathological cases. Keep in mind this is a bare minimum restriction and you can\n still run into trouble.\n\n This is most applicable in scenarios where your homeserver has many legacy\n bots/scripts that login over and over (which ideally should be using [personal\n access\n tokens](https://github.com/element-hq/matrix-authentication-service/issues/4492))\n and you want to avoid breaking their operation while maintaining some level of\n sanity with the number of devices that people can have.", "type": "boolean", "default": false }