feat(sliding-sync): allow configuring sync presence

[lhjt]

Allow sliding sync clients to configure the set_presence value sent with generated sync requests.

This adds presence configuration to SlidingSyncBuilder, stores it on SlidingSync, and exposes SlidingSync::set_presence for runtime updates. The UI sync helpers now thread the same presence setting through both the room-list sync and encryption sync services, so background sync users can request offline or unavailable presence instead of being marked online by polling.

The default remains PresenceState::Online, matching the Matrix sync API default and preserving existing behaviour.

API shape

The core SlidingSyncBuilder::set_presence and SyncServiceBuilder::with_presence APIs follow the existing builder style. RoomListService::new_with_presence and EncryptionSyncService::new_with_presence are added to keep the existing public constructors backwards-compatible while allowing callers to configure presence at construction time.

I would be happy to refactor this into a dedicated builder or options struct for RoomListService and EncryptionSyncService, which would likely scale better than adding more new_with_* constructors (if this is something the maintainers would prefer).

Tests

• cargo test -p matrix-sdk test_sliding_sync_request_uses_configured_presence --lib
• cargo test -p matrix-sdk-ui --test integration test_sync_service_presence_is_used_by_both_syncs

cargo fmt --check currently fails on an unrelated upstream formatting difference in crates/matrix-sdk/src/event_cache/redecryptor.rs.

• I've documented the public API changes in the appropriate changelog files (see Writing changelog entries).
• This PR was made with the help of AI.

[codecov]

Codecov Report

❌ Patch coverage is 94.70199% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.89%. Comparing base (340bbc8) to head (e5f1fce).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk/src/sliding_sync/mod.rs	66.66%	0 Missing and 6 partials ⚠️
crates/matrix-sdk/src/client/mod.rs	98.36%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6672      +/-   ##
==========================================
- Coverage   89.89%   89.89%   -0.01%     
==========================================
  Files         396      396              
  Lines      110264   110412     +148     
  Branches   110264   110412     +148     
==========================================
+ Hits        99117    99250     +133     
+ Misses       7376     7375       -1     
- Partials     3771     3787      +16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 50 untouched benchmarks

---

_{Comparing lhjt:feat/presence (e5f1fce) with main (340bbc8)}

[stefanceriu]

Hello, thank you for raising this!

I've conferred with my coleagues and we believe this isn't really the right approach, the RoomListService shouldn't expose any interfaces into the underlying sliding sync or even mention it really, its only responsibility is and should be to deal with well .. room lists.

We think a better avenue would be to expose this on the client itself, where SlidingSync would read the value from when generating a sync request.

[lhjt]

Hi @stefanceriu, thanks so much for the review!

I wholly agree with the sentiment above; my initial goal was to bring idle status on suspend to element x, and ensuring background sync in element x wouldn't set the user's presence to online (in an effort to help improve the push notification experience within the matrix ecosystem)

I'll update this PR accordingly 🙂

[jmartinesp]

I was checking your changes and I think this could maybe be simplified further? In SlidingSync we have generate_sync_request, which creates a the request to send in sync_once: in this method it's possible to access the Client using self.inner.client, so it should be possible to use self.inner.client.sync_presence() to get the presence value and use it later to set request.set_presence.

With this you wouldn't have to duplicate the presence property and set/clear methods in SlidingSync if I'm not mistaken.

---

Also, maybe instead of having several set_presence and set_sync_presence methods, you could have just one with an immediate: bool param? WDYT @stefanceriu ?

[stefanceriu]

in an effort to help improve the push notification experience

That sounds great, thanks for looking into it!

WDYT @stefanceriu ?

All if it makes sense to me, thanks for reviewing Jorge. generate_sync_request was ideed the intended target, I should've been clearer with my when generating a sync request comment.

[lhjt]

Thanks for the review @jmartinesp (and @stefanceriu)!

I have updated the PR to simplify this down further as per your recommendation 🙂

Regarding immediate: bool: I kept set_sync_presence and set_presence separate for now because they have different semantics:

• set_sync_presence is a local default used by future generated sync requests;
• set_presence sends an immediate presence update to the homeserver and can fail.

I figured maintaining those as separate methods would be more explicit (though I am happy to collapse them behind a single API if you’d still prefer that signature)

[stefanceriu]

I figured maintaining those as separate methods would be more explicit

To be honest I think and immediate parameter is more explicit than sync and sync_presence for which you would need more context to understand.

[lhjt]

Sure thing; I'll update it

[stefanceriu]

Looking good but I did leave some more comments inline. Thank you!

[stefanceriu]

Great, thank you very much for the contribution! 🙏