mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-04 15:37:49 +00:00
Kegan DougalandClaude Fable 5.1
6e7672f595
What a client sees of a member key room: every event names a member key as its sender and, through MSC4428, as its stable ID; `member_info` resolves the keys to users; the requester is recognised by their key wherever the server decides what they may see or which events are theirs; and `/members` and `/joined_members` are keyed by key. One homeserver only, but the code answers for members of other servers too (a verified link names the user it claims, anything else is nobody). `member_info`. MSC4428's map, which only named erased users (the stable ID of an ordinary room is the user ID and the entry is omitted), now gives every member key an entry: the user behind a key we hold, the user named by a verified link for another server's key, and `null` for an erased user or a key nobody vouches for (an unverified claim is anyone's to make). The resolution is one batched store lookup (`get_user_ids_for_identities`, exposed by the member key handler as `user_ids_for_identities`), so the map costs rooms without member keys nothing. The map already covers `/sync` (full and incremental), sliding sync, `/members` and `/joined_members`, which are keyed by state key and so by key; nothing there changes. An erasure is recorded on the change stream under the stable ID that changed, which in these rooms is the member's key, so the entry that flips to `null` is the one clients hold. Visibility. `filter_and_transform_events_for_client` decided what the requester may see from their membership under their user ID, which the state of a member key room does not hold: a joined user saw nothing. It now looks the requester up under their key in each member key room the batch touches, for both the allow check and the membership the event is annotated with, and maps senders back to users, per room (a key is only a user in the room it was looked up in), for the two per-user checks: erased senders, whose events are pruned for users who joined later, so a key with no attributable user is not erased; and ignored senders, where a member may be ignored as the user behind their key or as the key itself, since a key with no attributable user is the only handle a client has on it. `filter_event_for_clients_with_state`, which push evaluation uses to decide who may see an event, does the same per local user, for the ignore lists as for the memberships, including for the out-of-band membership events it returns to their target. The push evaluator itself resolves the sender (so a user is not notified of their own events), the invitee and the inviter (so an invite notifies its target, and the invitee's invite rules see the inviter as a user, where one is attributable). The requester's own events. The serializer echoes `transaction_id` and `delay_id` only to the sender's own session, by comparing the sender with the requester's user ID, which in a member key room never matches. `SerializeEventConfig.requester_member_keys` (a new keyword-only argument, `None` by default, so existing constructions are unchanged) carries the requester's keys and the Rust serializer accepts a sender among them; `create_config` fills it from the cached per-user keys when the feature is on. Keys are unique across rooms, so a key of the requester's can only ever be their own sender. Sync. Where the handlers compared the requester's user ID with a sender or a membership state key, they now use the identity the room knows them by (`room_identity_for_user`: their key where they have one, their user ID otherwise, or the cached map of their keys per room): the incremental sync reads the requester's previous membership under their key, so a change to their own membership (a display name) is an ordinary timeline event rather than the room sent again as newly joined, and a leave is newly left; the heroes of a nameless room no longer include the requester; the lazy-loading full sync fetches the requester's own membership under their key; a leave the user sent themselves is told from a kick by their keys per room, in sync and in the sliding sync room lists; the join-race guard asks the user-keyed membership table; and sliding sync's `$ME` is the requester's key, including in the computation of which required state has changed between requests. An invite's sender is resolved to a user (where attributable) for the ignore list and the invite rules, in sync and in both sliding sync room lists: a key on the ignore list hides the invite too, and an unattributable key no longer reaches the invite rules, which parse user IDs and would have failed the whole sync. The members handed to presence and to device lists, by sync, by the device handler for newly joined and left rooms, and by the room initial sync, are mapped to users first, so clients are told about users' devices and presence, not keys'. The three storage queries that find a user's membership changes in `current_state_delta_stream` and `room_memberships` share one clause that, with the feature on, also matches the keys we hold for the user, each scoped to its room (keys are public strings anyone can name as a state key elsewhere) and spelled out from the cached per-user keys so that every arm of the clause can use the tables' indexes; a user with no keys, and the feature being off, get the legacy clause byte for byte. Sliding sync's "newly joined" and "newly left" detection, and the device handler's shared-room tracking, run on those queries. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
.. image:: https://github.com/element-hq/synapse/raw/develop/docs/element_logo_white_bg.svg :height: 60px **Element Synapse - Matrix homeserver implementation** |support| |development| |documentation| |license| |pypi| |python| Synapse is an open source `Matrix <https://matrix.org>`__ homeserver implementation, written and maintained by `Element <https://element.io>`_. `Matrix <https://github.com/matrix-org>`__ is the open standard for secure and interoperable real-time communications. You can directly run and manage the source code in this repository, available under an AGPL license (or alternatively under a commercial license from Element). There is no support provided by Element unless you have a subscription from Element. 🚀 Getting started ================== This component is developed and maintained by `Element <https://element.io>`_. It gets shipped as part of the **Element Server Suite (ESS)** which provides the official means of deployment. ESS is a Matrix distribution from Element with focus on quality and ease of use. It ships a full Matrix stack tailored to the respective use case. There are three editions of ESS: - `ESS Community <https://github.com/element-hq/ess-helm>`_ - the free Matrix distribution from Element tailored to small-/mid-scale, non-commercial community use cases - `ESS Pro <https://element.io/server-suite>`_ - the commercial Matrix distribution from Element for professional use - `ESS TI-M <https://element.io/server-suite/ti-messenger>`_ - a special version of ESS Pro focused on the requirements of TI-Messenger Pro and ePA as specified by the German National Digital Health Agency Gematik 🛠️ Standalone installation and configuration ============================================ The Synapse documentation describes `options for installing Synapse standalone <https://element-hq.github.io/synapse/latest/setup/installation.html>`_. See below for more useful documentation links. - `Synapse configuration options <https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html>`_ - `Synapse configuration for federation <https://element-hq.github.io/synapse/latest/federate.html>`_ - `Using a reverse proxy with Synapse <https://element-hq.github.io/synapse/latest/reverse_proxy.html>`_ - `Upgrading Synapse <https://element-hq.github.io/synapse/develop/upgrade.html>`_ 🎯 Troubleshooting and support ============================== 🚀 Professional support ----------------------- Enterprise quality support for Synapse including SLAs is available as part of an `Element Server Suite (ESS) <https://element.io/pricing>`_ subscription. If you are an existing ESS subscriber then you can raise a `support request <https://customer.element.io/support>`_ and access the `Element product documentation <https://docs.element.io>`_. 🤝 Community support -------------------- The `Admin FAQ <https://element-hq.github.io/synapse/latest/usage/administration/admin_faq.html>`_ includes tips on dealing with some common problems. For more details, see `Synapse's wider documentation <https://element-hq.github.io/synapse/latest/>`_. For additional support installing or managing Synapse, please ask in the community support room |room|_ (from a matrix.org account if necessary). We do not use GitHub issues for support requests, only for bug reports and feature requests. .. |room| replace:: ``#synapse:matrix.org`` .. _room: https://matrix.to/#/#synapse:matrix.org .. |docs| replace:: ``docs`` .. _docs: docs 🛠️ Development ============== We welcome contributions to Synapse from the community! The best place to get started is our `guide for contributors <https://element-hq.github.io/synapse/latest/development/contributing_guide.html>`_. This is part of our broader `documentation <https://element-hq.github.io/synapse/latest>`_, which includes information for Synapse developers as well as Synapse administrators. Developers might be particularly interested in: * `Synapse's database schema <https://element-hq.github.io/synapse/latest/development/database_schema.html>`_, * `notes on Synapse's implementation details <https://element-hq.github.io/synapse/latest/development/internal_documentation/index.html>`_, and * `how we use git <https://element-hq.github.io/synapse/latest/development/git.html>`_. Alongside all that, join our developer community on Matrix: `#synapse-dev:matrix.org <https://matrix.to/#/#synapse-dev:matrix.org>`_, featuring real humans! Copyright and Licensing ======================= | Copyright 2014–2017 OpenMarket Ltd | Copyright 2017 Vector Creations Ltd | Copyright 2017–2025 New Vector Ltd | Copyright 2025 Element Creations Ltd This software is dual-licensed by Element Creations Ltd (Element). It can be used either: (1) for free under the terms of the GNU Affero General Public License (as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version); OR (2) under the terms of a paid-for Element Commercial License agreement between you and Element (the terms of which may vary depending on what you and Element have agreed to). Unless required by applicable law or agreed to in writing, software distributed under the Licenses is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the Licenses for the specific language governing permissions and limitations under the Licenses. Please contact `licensing@element.io <mailto:licensing@element.io>`_ to purchase an Element commercial license for this software. .. |support| image:: https://img.shields.io/badge/matrix-community%20support-success :alt: (get community support in #synapse:matrix.org) :target: https://matrix.to/#/#synapse:matrix.org .. |development| image:: https://img.shields.io/matrix/synapse-dev:matrix.org?label=development&logo=matrix :alt: (discuss development on #synapse-dev:matrix.org) :target: https://matrix.to/#/#synapse-dev:matrix.org .. |documentation| image:: https://img.shields.io/badge/documentation-%E2%9C%93-success :alt: (Rendered documentation on GitHub Pages) :target: https://element-hq.github.io/synapse/latest/ .. |license| image:: https://img.shields.io/github/license/element-hq/synapse :alt: (check license in LICENSE file) :target: LICENSE .. |pypi| image:: https://img.shields.io/pypi/v/matrix-synapse :alt: (latest version released on PyPi) :target: https://pypi.org/project/matrix-synapse .. |python| image:: https://img.shields.io/pypi/pyversions/matrix-synapse :alt: (supported python versions) :target: https://pypi.org/project/matrix-synapse