Remove prev_batch

It wasn't particulalry useful for clients, and doesn't help equivocation much.

proposals/4354-sticky-events.md

@@ -53,8 +53,8 @@ with a valid value makes the event “sticky”[^stickyobj]. Valid values are th
 This key can be set by clients in the CS API by a new query parameter `stick_duration_ms`, which is
 added to the following endpoints:
 
-* `PUT /\_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}`
+* `PUT /_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}`
-* `PUT /\_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}`
+* `PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}`
 
 To calculate if any sticky event is still sticky:
 
@@ -97,33 +97,28 @@ The new sync section looks like:
         "ephemeral": { ... },
         "state": { ... },
         "timeline": { ... },
-        "sticky_events": [
+        "sticky_events": {
-          {
+            "events": [
-     "event": {
+                {
-              "sender": "@bob:example.com",
+                    "sender": "@bob:example.com",
-              "type": "m.foo",
+                    "type": "m.foo",
-              "sticky": {
+                    "sticky": {
-                "duration_ms": 300000
+                      "duration_ms": 300000
-              },
+                    },
-              "origin_server_ts": 1757920344000,
+                    "origin_server_ts": 1757920344000,
-              "content": { ... }
+                    "content": { ... }
-     },
+                },
-     "prev_batch": "s1234_5678_90123"
+                {
-          },
+                    "sender": "@alice:example.com",
-          {
+                    "type": "m.foo",
-     "event": {
+                    "sticky": {
-              "sender": "@alice:example.com",
+                      "duration_ms": 300000
-              "type": "m.foo",
+                    },
-              "sticky": {
+                    "origin_server_ts": 1757920311020,
-                "duration_ms": 300000
+                    "content": { ... }
-              },
+                }
-              "origin_server_ts": 1757920311020,
+            ]
-              "content": { ... }
+        }
-     },
-     "prev_batch": "s1234_5678_90125"
-          }
-        ],
-      }
     }
   }
 }
@@ -134,10 +129,8 @@ Over Simplified Sliding Sync, Sticky Events have their own extension `sticky_eve
 ```json
 {
   "rooms": {
-      "!726s6s6q:example.com": [
+      "!726s6s6q:example.com": {
-        {
+          "events": [{
-          "prev_batch": "s1234_5678_90125",
-          "event": {
               "sender": "@bob:example.com",
               "type": "m.foo",
               "sticky": {
@@ -145,15 +138,14 @@ Over Simplified Sliding Sync, Sticky Events have their own extension `sticky_eve
               },
               "origin_server_ts": 1757920344000,
               "content": { ... }
-          }
+          }]
-        }
+      }
-      ]
   }
 }
 ```
 
 Sticky messages MAY be sent in the timeline section of the `/sync` response, regardless of whether
-or not they exceed the timeline limit[^ordering]. 
+or not they exceed the timeline limit[^ordering].
 
 Servers SHOULD rate limit sticky events over federation. If the rate limit kicks in, servers MUST
 return a non-2xx status code from `/send` such that the sending server *retries the request* in order
@@ -334,4 +326,4 @@ Furthermore, it didn’t really add any more protection because it assumed serve
 Malicious servers could set the TTL to be the maximum allowed time all the time, ensuring maximum divergence
 on whether or not an event was sticky. In contrast, using `origin_server_ts` is a consistent reference point
 that all servers are guaranteed to see, limiting the ability for malicious servers to cause divergence as all
-servers approximately track NTP.
+servers approximately track NTP.