Simplified Sliding Sync is the native Matrix synchronisation approach designed to let clients request just the rooms and state they need instead of downloading a large account's entire view up front. It replaced the earlier architecture that required a separate sliding-sync proxy between clients and homeservers.
Why the old /sync became a bottleneck
Traditional Matrix /sync can become expensive for accounts in many rooms because the client initially receives substantial state before the interface becomes useful. Sliding Sync introduced a windowed model in which the client describes lists and ranges of rooms it currently wants. The first widely deployed design used a proxy that maintained additional state. Matrix later moved the simplified protocol into homeservers themselves, removing that extra component and making the behaviour part of the native client-server API path.
From a proxy to native homeserver support
The user-visible goal is fast startup, especially on mobile. A client can render the most relevant rooms first, then fetch more as the person scrolls or opens a conversation. Removing the proxy also simplifies deployment for homeserver operators and avoids asking the ecosystem to run a second stateful service merely to obtain responsive modern clients.
Older documentation can be misleading
Support depends on both homeserver and client versions, so a Matrix deployment can still encounter older sync paths. The word 'simplified' describes a protocol redesign, not an absence of complexity: clients still need to handle incremental state, encryption and room-list changes correctly. The migration also means older articles about the separate Sliding Sync proxy can now describe an obsolete architecture.
Related reading
- What Is plc.directory and Why Does AT Protocol Depend on It?
- What Is did:plc? The Identity System Behind Most Bluesky Accounts