[WIP] MSC4354: Sticky Events #18968

kegsay · 2025-09-24T13:30:21Z

This implements MSC4354: Sticky Events. To enable it, set this in homeserver.yaml:

experimental_features:
    msc4354_enabled: true

Still a WIP because it needs:

more federation support (sending sticky events to newly joined servers)
complement tests
unit tests

Pull Request Checklist

Pull request is based on the develop branch
Pull request includes a changelog file. The entry should:
- Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
- Use markdown where necessary, mostly for code blocks.
- End with either a period (.) or an exclamation mark (!).
- Start with a capital letter.
- Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
Code style is correct (run the linters)

This only works on postgres for now

Persist inside persist_events to guarantee it is done. After that txn, recheck soft failure.

MadLittleMods

Looked everything over but didn't full evaluate the sticky events part against the MSC or fully ponder weird corners.

MadLittleMods · 2025-09-26T21:17:35Z

synapse/events/builder.py


    content: JsonDict = attr.Factory(dict)
    unsigned: JsonDict = attr.Factory(dict)
+    sticky: Optional[StickyEventField] = None


Suggested change

sticky: Optional[StickyEventField] = None

sticky: Optional[StickyEventField] = None

"""

TODO

"""

It would be good to add a docstring to indicate where this is from and what's used for.

MadLittleMods · 2025-09-26T21:20:39Z

synapse/federation/federation_base.py

+            # Mark this as spam so we don't re-evaluate soft-failure status.
+            redacted_event.internal_metadata.policy_server_spammy = True


Seems unrelated to sticky events

It's related because spam is currently flagged in Synapse via soft-failure, and sometimes via policy_server_spammy. As this PR is re-evaluating soft-failed events, we want to make sure we don't re-evaluate spam, hence need to distinguish it.

MadLittleMods · 2025-09-26T21:23:54Z

synapse/handlers/sliding_sync/extensions.py

+        if not sticky_events_request.enabled:
+            return None
+        now = self.clock.time_msec()
+        from_id = from_token.stream_token.sticky_events_key if from_token else 0


Should we copy this pattern?

synapse/synapse/handlers/sliding_sync/extensions.py

Lines 928 to 931 in 2f2b854

if from_token:

from_stream_id = from_token.stream_token.thread_subscriptions_key

else:

from_stream_id = StreamToken.START.thread_subscriptions_key

MadLittleMods · 2025-09-26T21:32:48Z

synapse/handlers/sliding_sync/extensions.py

+        _, room_to_event_ids = await self.store.get_sticky_events_in_rooms(
+            actual_room_ids,
+            from_id,
+            to_token.sticky_events_key,
+            now,
+        )


To double-check, it's desired to return all sticky events in the room on initial sync? It's fine if there are 100k+ sticky events? Currently, on initial sync, this will return everything from 0 to current.

Here is my suggestion:

I think the better way to go about is to apply the same pattern that we just worked through with thread subscriptions. We would need a few things:

A way to return the new sticky events in /sync

Dedicated sticky_events_limited flag when there are other sticky events that we didn't return

A pagination endpoint for the sticky events

To be more detailed, these could be normal timeline events. If there are more sticky events in between the given sync token and the current position, we set the sticky_events_limited flag. For the pagination endpoint, we could overload /messages with a new filter.

-- @MadLittleMods, internal room

Some other cross-links when we tackled this with thread_subscriptions -> #18695 (comment) and matrix-org/matrix-spec-proposals#4306 (comment)

I speak about this at length in https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/persist-edu/proposals/4354-sticky-events.md#spam

This seems like the same problem as the timeline. While the section talks about the problem extensively, I'm not really convinced this is fine.

The problem is the amount of work needed to come up with the giant 100k response and the amount of network effort to get that back to the client.

MadLittleMods · 2025-09-26T21:35:42Z

synapse/handlers/delayed_events.py

            content: The content of the event to be sent.
            delay: How long (in milliseconds) to wait before automatically sending the event.
-
+            sticky_duration_ms: The sticky duration if any, see MSC4354.


I think this could be expanded a bit to explain what it means without having to look at MSC4354. I have to make a lot of assumptions otherwise.

"Time since xxx that the event should appear in xxx"

MadLittleMods · 2025-09-26T21:59:56Z

synapse/storage/databases/main/sticky_events.py

+# Consumers call 'get_sticky_events_in_rooms' which has `WHERE expires_at > ?`
+# to filter out expired sticky events that have yet to be deleted.
+DELETE_EXPIRED_STICKY_EVENTS_MS = 60 * 1000 * 60  # 1 hour
+MAX_STICKY_DURATION_MS = 3600000  # 1 hour


In the client event creation, we should be preventing creating events that have duration greater than MAX_STICKY_DURATION_MS

MadLittleMods · 2025-09-26T22:00:15Z

synapse/storage/databases/main/sticky_events.py

+            if (
+                type(sticky_duration_ms) is int
+                and sticky_duration_ms >= 0
+                and sticky_duration_ms <= MAX_STICKY_DURATION_MS


Silently ignoring events with a duration greater than the MAX_STICKY_DURATION_MS seems a bit dubious. Is that correct? We should explain why that's fine.

If created locally, we should return an error as per your earlier comment. Over federation, no auth rule forbids a high duration (the field itself isn't even protected from redaction) so we have to continue processing the event. We obviously don't want to action a long duration, so silently ignoring is the right thing to do in this particular case.

MadLittleMods · 2025-09-26T22:02:59Z

synapse/storage/databases/main/sticky_events.py

+        critical_auth_types = (
+            EventTypes.JoinRules,
+            EventTypes.PowerLevels,
+            EventTypes.Member,
+        )


Wondering how this plays with room versions. Do we need to be careful at all with forward compatibility, etc?

Should we be using auth_types_for_event instead?

I don't think we need to be that careful here. We will need to keep this updated if we make new room versions which break the current auth model though.

MadLittleMods · 2025-09-26T22:06:56Z

synapse/types/__init__.py

        9. `groups_key`: `1` (note that this key is now unused)
        10. `un_partial_stated_rooms_key`: `379`
        11. `thread_subscriptions_key`: 4242
+        12. `sticky_events_key`: 4141


Add it to the full example token above

MadLittleMods · 2025-09-26T22:07:28Z

tests/federation/test_federation_catch_up.py

+
+        # now we send a sticky event that we expect to be bundled with the fwd extrem event
+        sticky_event_id = self.helper.send_sticky_event(
+            room_1, "m.room.sticky", 60000, tok=u1_token


60000 is obtuse. Would be nice to have a labeled variable

kegsay added 14 commits September 18, 2025 14:33

WIP MSC4354; stub out soft-failure code for now

abf658c

Persist sticky events in sticky_events table

8699534

This only works on postgres for now

Use multi-writer streams for sticky events

7801e68

Hook up replication receiver, add sticky events to sync tokens

e01a22b

Insert sticky events into /sync responses

3e7a5a6

Don't include expired sticky events in /sync responses

7af7429

Delete from sticky_events periodically

0cfdd0d

Get sticky events working with Simplified Sliding Sync

7c8daf4

Support MSC4140 Delayed Events with sticky events

ac0f8c2

Fix sqlite

1e812e4

Re-evaluate soft-failure on sticky events

2728b21

Don't re-evaluate spam

666e94b

Rejig when we persist sticky events

771692a

Persist inside persist_events to guarantee it is done. After that txn, recheck soft failure.

Update docs to not lie

ad6a2b9

kegsay requested a review from a team as a code owner September 24, 2025 13:30

kegsay mentioned this pull request Sep 24, 2025

MSC4354: Sticky Events matrix-org/matrix-spec-proposals#4354

Open

4 tasks

kegsay marked this pull request as draft September 24, 2025 13:30

MadLittleMods mentioned this pull request Sep 25, 2025

Improve documentation around streams, particularly ID generators and adding new streams. #18943

Open

kegsay added 2 commits September 26, 2025 09:29

Send sticky events when catching up over federation

33d80be

Fix trial tests

148caef

MadLittleMods reviewed Sep 26, 2025

View reviewed changes

kegsay added 4 commits September 29, 2025 16:26

Add msc4354_sticky_duration_ttl_ms support

de3e9b4

Merge branch 'develop' into kegan/sticky-events

105d2cd

Use standard unstable identifiers

651e829

Don't persist sticky outliers

4acc98d

		# Mark this as spam so we don't re-evaluate soft-failure status.
		redacted_event.internal_metadata.policy_server_spammy = True

	if from_token:
	from_stream_id = from_token.stream_token.thread_subscriptions_key
	else:
	from_stream_id = StreamToken.START.thread_subscriptions_key

[WIP] MSC4354: Sticky Events #18968

Are you sure you want to change the base?

[WIP] MSC4354: Sticky Events #18968

Uh oh!

Conversation

kegsay commented Sep 24, 2025

Pull Request Checklist

Uh oh!

MadLittleMods left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MadLittleMods Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MadLittleMods Sep 26, 2025 •

edited

Loading