Skip to content

MSC4342: Limiting the number of devices per user ID #4342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

MSC4342: Limiting the number of devices per user ID #4342

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d4dd258
MSC4342: Limiting the number of devices per user ID
kegsay Sep 5, 2025
7e2f7b0
Update 4342-device-limit.md
kegsay Sep 5, 2025
221e184
Update 4342-device-limit.md
kegsay Sep 8, 2025
e328a60
Update 4342-device-limit.md
kegsay Sep 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
101 changes: 101 additions & 0 deletions proposals/4342-device-limit.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Server
  • Client (error code)

Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
## MSC4342: Limiting the number of devices per user ID

Matrix currently does not specify any limit to the number of devices a user can have. This has
negative impacts on homeservers:
- They need to persist an unbounded set of devices. If those devices use E2EE, they also need to persist one-time keys (OTKs).
- The way device lists are synced over federation (`prev_id` and `stream_id` in `m.device_list_update` EDUs) is complex and error-prone, primarily to support this unbounded workload.
- Any wildcard queries (`/sendToDevice` with a device ID of `*`) causes massive traffic amplification.

..and on clients:
- Sending encrypted messages encrypts for all devices in the room. A single user with thousands of devices
can significantly impact performance when sending encrypted messages.
- Size limits on HTTP requests means a user with thousands of devices risks causing unable to decrypt errors as the response
to `/keys/claim` exceeds the size permitted by reverse proxies. As `/keys/claim` is server-scoped, this can impact the ability
to claim OTKs for innocent users.

What's worse, often users with many devices are unaware that they have so many e.g because they have logged in via their browser repeatedly.
This ultimately reduces security of E2EE as messages are encrypted for an unnecessarily large number of sessions, any one of which could be
compromised to then decrypt the messages.

Because the number of devices affects not just the user with those devices but everyone they communicate with,
the limit needs to be enforced in the specification, hence this proposal.

In comparison to other encrypted apps:
- WhatsApp restricts to [5 devices](https://faq.whatsapp.com/378279804439436/?cms_platform=android) (one primary, 4 linked).
- Signal restricts to [6 devices](https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices) (one primary, 5 linked).

Unlike these apps however, Matrix is a decentralised protocol with many different types of clients/apps available. This biases towards
users running multiple apps for the same account.

### Proposal

The maximum number of devices a user can have at any one time is reduced to 30.
Servers MAY have an even lower limit than this. Servers MUST NOT have a higher limit than this.
Copy link
Contributor

@tonkku107 tonkku107 Sep 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should homeservers do anything to reject other servers over federation that exceed this limit?
If so, how would the transitionary period work while the proposal is being adopted? How would we deal with raising or lowering the limit in the future?
But if nothing is done over federation a server could just ignore the limit and some of the problems persist.


>[!NOTE]
> This proposal has to balance the needs and desires of users with the needs and desires of server admins
> who cannot allow unbounded amounts of data. This proposal aims to balance this by affecting <1% of "power users"
> where "power users" is defined as having >= 2 devices logged into matrix.org as of Sept 2025.
>
> 30 was chosen based on a statistical analysis of the matrix.org database:
> - 99.312% of users have <= 5 devices. A limit of 5 will affect 1 in every 145 users.
> - 99.839% of users have <= 10 devices. A limit of 10 will affect 1 in every 621 users.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a superb empirical basis for proposing the value; I will remember this MSC as a benchmark to be cited in other situations. Bravo.

> - 99.931% of users have <= 15 devices. A limit of 15 will affect 1 in every 1449 users.
> - 99.978% of users have <= 30 devices. A limit of 30 will affect 1 in every 4545 users.
>
> Excluding users with only 1 device (e.g throwaway accounts or users who try Matrix once and never again):
> - 79.809% of users with >1 device have <= 5 devices. A limit of 5 will affect 1 in every 5 users with >1 device.
> - 95.277% of users with >1 device have <= 10 devices. A limit of 10 will affect 1 in every 21 users with >1 device.
> - 98.818% of users with >1 device have <= 20 devices. A limit of 20 will affect 1 in every 85 users with >1 device.
> - 99.367% of users with >1 device have <= 30 devices. A limit of 30 will affect 1 in every 158 users with >1 device.
> - 99.558% of users with >1 device have <= 40 devices. A limit of 40 will affect 1 in every 226 users with >1 device.
> - 99.654% of users with >1 device have <= 50 devices. A limit of 50 will affect 1 in every 289 users with >1 device.
> - 99.712% of users with >1 device have <= 60 devices. A limit of 60 will affect 1 in every 347 users with >1 device.

Attempts to login and exceed this limit returns the error code `M_TOO_MANY_DEVICES`. A client receiving this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no mention of next gen auth here. It could be as simple as displaying an equivalent error page to the user.

Since users can log in to their homeserver's management interface without creating a device, they could also be instructed to remove an inactive device right there before seamlessly continuing with the login flow.

error code should instruct the user to logout an existing device and try again.

>[!NOTE]
> There's two main options here: prevent the limit being exceed or logout the longest inactive device.
> Logging out devices causes data loss because it drops to-device events which contain encryption keys.
> Therefore, this proposal instead prevents the limit being exceeded by returning an error code.
Comment on lines +58 to +61
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(It might be good to move this paragraph to the "Alternatives" section.)

The auto-logout option actually seems a little more user friendly to me than the login limit. The limit introduces the severe risk of locking yourself out of your own account by losing access to all logged in devices. Also, if you're at the limit and want to log in, you now first need to find another logged-in device and log it out which feels cumbersome.

It's a valid point that auto-logout would cause data loss but I think with a reasonable threshold it would only impact power users (much like the current proposal) or sessions that are obsolete anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, maybe that is the best way then. A compromised password would already allow the attacker to log out all your devices, so by cycling out old devices on login it doesn't introduce any new attack vector.

We would need to have clarity on how the definition of "oldest used device" works. For example, if we tie it to /sync then this would negatively impact bots which may never call /sync.


Application service users will be unaffected by this restriction.

>[!NOTE]
> Application services may have workflows outside expected use cases. To reduce the risk of this proposal
> having unintended consequences, application service users (and their exclusive namespaced users) are exempt
> from this limit.

Servers which retrospectively apply this MSC MAY arbitrarily logout the oldest devices to reclaim resources from those users.
Users SHOULD be informed of this beforehand e.g via a Server Notices room.

### Potential Issues

Clients which do not log out cleanly by failing to talk to the server when logging out will still be tracked
as a device. Certain workflows which repeatedly destroy clients in this way (e.g the client runs on a VM
which is destroyed at the end of every day) will be impacted by this change as they will slowly accumulate
more and more devices. Clients which behave in this manner need to manage the existing sessions for the user
or else they will eventually be unable to login.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about a safety net in case you lose access to all existing devices, but are at the top of this limit? How would you recover your account in that case, considering most clients probably won't let you log in without a device these days so you likely never get access to the UI to delete them, even if at API level this may be possible.


### Alternatives

The number can be higher or lower than 30. 30 was chosen to limit the impact on existing users using matrix.org
as their homeserver.

We could continue to have no limit. However, this will eventually become untenable due to the unbounded
growth of devices.

### Security Considerations

An attacker who has the password for a user may login many devices to stop the real user from logging in
new devices. However, if an attacker has your password they can do worse and logout your devices causing
data loss. The additional denial of service risk seems small in comparison.

### Unstable prefix

The error code is `ORG_MATRIX_MSC4342_M_TOO_MANY_DEVICES` whilst in development.

### Dependencies

None.