Lazy channels

Is your feature request related to a problem? Please describe.

[18:37]polyzium: WHat's "sliding sync"?
[18:39]Cat/FSG-Cat: its a different Sync paradigm for matrix.
[18:40]Cat/FSG-Cat: And well its diffrent
[18:41]Cat/FSG-Cat: if we talk about the stuff in discord terms
[18:41]Cat/FSG-Cat: today your matrix client would sync all guilds all channels in them
[18:41]Cat/FSG-Cat: Now with sliding sync it would actually be closer to that it only syncs the guild your in currently
[18:42][thearcanebrony@localhost ~]$: heres the thing with discord
[18:42]Cat/FSG-Cat: and it wont even be aware fully of the guilds your not currently seeing.
[18:42]erkinalp:0001@discord.com: well discord lacks that kind of sync
[18:42][thearcanebrony@localhost ~]$: you get all MESSAGE_CREATEs for for all channels youre in
[18:42]Cat/FSG-Cat: Like the idea is that in Sliding sync you only sync what you see
[18:42][thearcanebrony@localhost ~]$: yet, opening a channel will just load the entire history
[18:43]Cat/FSG-Cat: So if you dont need to sync a room because its hidden in a space your not in
[18:43]Cat/FSG-Cat: dont sync it
[18:43]Cat/FSG-Cat: hell dont sync it if its not actually in your current list view
[18:43]erkinalp:0001@discord.com: as an optimisation, we could suppress gateway push from muted channels until they're interacted with
[18:43]Cat/FSG-Cat: as in not on your screen not synced
[18:43][thearcanebrony@localhost ~]$: even easier
[18:44][thearcanebrony@localhost ~]$: track last viewed channel via GET /channels/:id/messages and only send gateway for that channel
[18:45]erkinalp:0001@discord.com: well that'd require comms between REST ingressor and gateway
[18:46][thearcanebrony@localhost ~]$: fair
[18:46]Maddy: Or have a new gateway op REQUEST_CHANNEL_UPDATES similar to lazy request, subscribes a client to channel updates. Client sends after get /messages.
[18:46]erkinalp:0001@discord.com: the mutes way is backwards compatible tho
[18:47][thearcanebrony@localhost ~]$: wait you make a fair point
[18:47][thearcanebrony@localhost ~]$: we could track via lazy request
[18:47]Maddy: Just implement both, and put the non-backwards compat behind an intent
[18:47][thearcanebrony@localhost ~]$: since isnt lazy request fired every time you visit a channel?
[18:48]Maddy: Yes
[18:48][thearcanebrony@localhost ~]$: thatd work then
[18:48][thearcanebrony@localhost ~]$: on lazy request, update a map between user and channel id to point to current channel
[18:49]Maddy: Although this entire idea breaks unread notifications
[18:49][thearcanebrony@localhost ~]$: unread notifications is based on CREATE_MESSAGE?
[18:49]erkinalp:0001@discord.com: iirc pidgin discord doesn't do guilds request on channel switch
[18:49]erkinalp:0001@discord.com: any timeline-visible event, including boost messages
[18:50]erkinalp:0001@discord.com: and we'd call the feature "lazy channels"
[18:52]Maddy: We could send a new 'unread' event for when the read status is no longer up to date. If it's already out of date don't send it again
[18:53]Maddy: Or 'read_state_update' it could be called
[18:54]Maddy: Someone should create an issue in gh with a link to this discussion + some notes pls. I'm in bed rn so haha
[18:54]erkinalp:0001@discord.com: well, that's required once we truly implement separate read marker, receipt and notifs cursor stuff

Describe the solution you'd like
Would be used to send gateway pushes for just the channels that are requested.

Describe alternatives you've considered
Using mutes to suppress gateway pushes

Additional context

No files, tests, or entry points are identified. Start by locating gateway push handling and the existing lazy request flow, then determine how requested channels should control updates without losing unread state. Done means the design and implementation define channel subscriptions, compatibility with mutes, and read or unread notification behavior.