Skip to content

MSC4354: Sticky Events#4354

Open
kegsay wants to merge 44 commits intomainfrom
kegan/persist-edu
Open

MSC4354: Sticky Events#4354
kegsay wants to merge 44 commits intomainfrom
kegan/persist-edu

Conversation

@kegsay
Copy link
Member

@kegsay kegsay commented Sep 16, 2025

@kegsay kegsay changed the title Sticky Events MSC4354: Sticky Events Sep 16, 2025
It wasn't particulalry useful for clients, and doesn't help equivocation much.
@turt2live turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Sep 16, 2025
@github-project-automation github-project-automation bot moved this to Tracking for review in Spec Core Team Workflow Sep 16, 2025
@turt2live turt2live added the matrix-2.0 Required for Matrix 2.0 label Sep 16, 2025
turt2live added a commit to matrix-org/gomatrixserverlib that referenced this pull request Nov 3, 2025
MSC: matrix-org/matrix-spec-proposals#4354

This is for policyserv so we can block sticky events in our public rooms
(they aren't needed there)
@turt2live
Copy link
Member

This MSC appears to still be in flux and is failing to acquire checkboxes. Because I'm the one that initially asked for FCP, I'm cancelling that request at the moment. Another SCT member can put it forward again at any time.

@mscbot fcp cancel

@mscbot mscbot added proposal-in-review and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Nov 18, 2025
@turt2live turt2live moved this from Ready for FCP ticks to Ready for general review in Spec Core Team Workflow Nov 18, 2025
@turt2live turt2live removed the 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. label Nov 18, 2025
@turt2live turt2live moved this from Ready for general review to Tracking for review in Spec Core Team Workflow Dec 2, 2025
Comment on lines 164 to 169
Over Simplified Sliding Sync, Sticky Events have their own extension `sticky_events`, which has the following response shape:

```js
{
"rooms": {
"!726s6s6q:example.com": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Clarify which rooms show up here. All rooms or only rooms relevant to the lists/room_subscriptions

- B) Persist the sticky events but wait a while before delivering them to clients.

Option A means servers don't need to store sticky events in their database, protecting disk usage at the cost of more bandwidth.
To implement this, servers MUST return a non-2xx status code from `/send` such that the sending server
Copy link
Contributor

Choose a reason for hiding this comment

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

suspicious: rather than saying what code you should use, it says what code you shouldn't. If we want to suggest this approach I think we should provide stronger guidance.
But the /send endpoint already has per-event statuses, so this feels a bit off as an approach. Separately, a non-2xx response will likely just cause the sending server to retry and/or mark you as down.
For this reason it's hard to recommend this approach and I'm wondering if we should recommend against it, except as a fallback when you're desperate / dealing with a highly-likely malicious case?

@reivilibre reivilibre force-pushed the kegan/persist-edu branch 2 times, most recently from 2183282 to 68581b7 Compare December 16, 2025 16:37
Comment on lines +149 to +150
Sticky messages MAY be sent in the timeline section of the `/sync` response, regardless of whether
or not they exceed the timeline limit[^ordering]. If a sticky event is in the timeline, it MAY be
Copy link
Contributor

Choose a reason for hiding this comment

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

This (allowing servers to exceed the limit of the existing timeline section) seems like a breaking change and I'd be uncomfortable supporting it.

Sticky messages MAY be sent in the timeline section of the `/sync` response, regardless of whether
or not they exceed the timeline limit[^ordering]. If a sticky event is in the timeline, it MAY be
omitted from the `sticky.events` section. This ensures we minimise duplication in the `/sync` response JSON.
This proposal recommends always putting sticky events into the `sticky.events` section _except_ if
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd like to suggest we make this MUST rather than recommendation.
I don't see any benefit in allowing divergence and it could result in clients mishandling events on some server implementations.

These messages may be combined with [MSC4140: Delayed Events](https://github.com/matrix-org/matrix-spec-proposals/pull/4140)
to provide heartbeat semantics (e.g required for MatrixRTC). Note that the sticky duration in this proposal
is distinct from that of delayed events. The purpose of the sticky duration in this proposal is to ensure sticky events are cleaned up,
whereas the purpose of delayed events is to affect the send time (and thus start time for stickiness) of an event.
Copy link
Contributor

Choose a reason for hiding this comment

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

Sticky events is an awesome and fun name, I would even say elegant if it wasnt for the following issue. It appears to be named after an implication of what it does, but I think the metaphor isn't at all obvious. This is particularly true wrt self-destruct semantics (= inverted heartbeat) of delayed events as the apparent need for this clarifying section emphasizes.

In conversation with peers, people who have not read this MSC but only somehow heard about it are usually assuming some kind of self-destruction related to the timer. Perhaps the event "sticks around" that long. It's quite possible this is also burdened by mixup with that actual requirement as delayed events and matrixrtc as a whole remain a developing topic, and so often both being mentioned in one sentence.

My interpretation after reading is that they are sticky in a sense of sticking to the top, eager high priority sharing, similar to state events, and eventually unsticking to fall back to regular priority.

I realize I'm a bit late to complain about the name which has already been used proudly in public a bunch. We could sti consider finding a name that more intuitively fits the purpose. Priority Events, Important Events?

Copy link
Member

@BillCarsonFr BillCarsonFr left a comment

Choose a reason for hiding this comment

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

I have a question regarding mixed content sticky chains (clear sticky replacing encrypted sticky)

As such, this proposal relies somewhat on NTP to ensure clocks over federation are roughly in sync.
As a consequence of this, the sticky duration SHOULD NOT be set to below 5 minutes.[^ttl]

### Encryption
Copy link
Member

Choose a reason for hiding this comment

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

What is the strategy regarding Mixed Content sticky chain? Like a clear event replacing an encrypted one?
Can we disable mixed content? Only an encrypted event can replace an encrypted sticked event.

Or at least having a way to discard such a sticky event?
If not it would be like allowing clear edits of encrypted messages without showing a big red warning.

Copy link
Member

Choose a reason for hiding this comment

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

FWIW there is prior art / similar rules for edits validity of replacement events

Maybe we could add similar rules? to be consistent.
Things like

  • The replacement and original events must have the same type
  • If the original event was encrypted the replacement should be too.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess this is referring to the 'Addendum: Implementing an ephemeral map'? I wonder if the formalisation of that addendum would be better-suited to another MSC?


When an event loses its stickiness, these properties disappear with the stickiness. Servers SHOULD NOT
eagerly synchronise such events anymore, nor send them down `/sync`, nor re-evaluate their soft-failure status.
Note: policy servers and other similar antispam techniques still apply to these events.
Copy link
Contributor

@reivilibre reivilibre Jan 26, 2026

Choose a reason for hiding this comment

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

It should probably be described what this concretely means. (coming from the PR review)

From the Synapse PR that was developed alongside the MSC, I'm taking this to mean that we don't treat the events as sticky at all if our policy server is not happy with them, so we don't propagate them to other servers or clients.

alexlebens pushed a commit to alexlebens/infrastructure that referenced this pull request Feb 24, 2026
This PR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [element-hq/synapse](https://github.com/element-hq/synapse) | minor | `v1.147.1` → `v1.148.0` |

---

### Release Notes

<details>
<summary>element-hq/synapse (element-hq/synapse)</summary>

### [`v1.148.0`](https://github.com/element-hq/synapse/releases/tag/v1.148.0)

[Compare Source](element-hq/synapse@v1.147.1...v1.148.0)

### Synapse 1.148.0 (2026-02-24)

No significant changes since 1.148.0rc1.

### Synapse 1.148.0rc1 (2026-02-17)

#### Features

- Support sending and receiving [MSC4354 Sticky Event](matrix-org/matrix-spec-proposals#4354) metadata. ([#&#8203;19365](element-hq/synapse#19365))

#### Improved Documentation

- Fix reference to the `experimental_features` section of the configuration manual documentation. ([#&#8203;19435](element-hq/synapse#19435))

#### Deprecations and Removals

- Remove support for [MSC3244: Room version capabilities](matrix-org/matrix-spec-proposals#3244) as the MSC was rejected. ([#&#8203;19429](element-hq/synapse#19429))

#### Internal Changes

- Add in-repo Complement tests so we can test Synapse specific behavior at an end-to-end level. ([#&#8203;19406](element-hq/synapse#19406))
- Push Synapse docker images to Element OCI Registry. ([#&#8203;19420](element-hq/synapse#19420))
- Allow configuring the Rust HTTP client to use HTTP/2 only. ([#&#8203;19457](element-hq/synapse#19457))
- Correctly refuse to start if the Rust workspace config has changed and the Rust library has not been rebuilt. ([#&#8203;19470](element-hq/synapse#19470))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yNS44IiwidXBkYXRlZEluVmVyIjoiNDMuMjUuOCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW1hZ2UiXX0=-->

Reviewed-on: https://gitea.alexlebens.dev/alexlebens/infrastructure/pulls/4203
Co-authored-by: Renovate Bot <renovate-bot@alexlebens.net>
Co-committed-by: Renovate Bot <renovate-bot@alexlebens.net>
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Feb 26, 2026
Tested on NetBSD 9 amd64 by reporting pyproject.toml buglets upstream!

# Synapse 1.148.0 (2026-02-24)

## Features

- Support sending and receiving [MSC4354 Sticky Event](matrix-org/matrix-spec-proposals#4354) metadata. ([\#19365](element-hq/synapse#19365))

## Deprecations and Removals

- Remove support for [MSC3244: Room version capabilities](matrix-org/matrix-spec-proposals#3244) as the MSC was rejected. ([\#19429](element-hq/synapse#19429))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

client-server Client-Server API kind:core MSC which is critical to the protocol's success matrix-2.0 Required for Matrix 2.0 proposal A matrix spec change proposal proposal-in-review unresolved-concerns This proposal has at least one outstanding concern

Projects

Status: Tracking for review

Development

Successfully merging this pull request may close these issues.