Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Should poll votes bump a room to the top of the ordered room list? #3101

Open
wrjlewis opened this issue Jul 30, 2024 · 1 comment
Labels
A-Polls A-Room-List A-SSS Regression or bug observed when using Simplified Sliding Sync O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Rust This issue needs a Rust SDK change. It must have a link to a Rust SDK issue

Comments

@wrjlewis
Copy link

wrjlewis commented Jul 30, 2024

Steps to reproduce

  1. Have a room with active polls
  2. People respond to polls
  3. Room sits at the top of the room list

This could be a feature though I'd argue it's more of a bug as:

  • The timestamps in the room list become out of order, if one of those rooms has polls. Like in this example where the room 'WhatsApple FC' has polls ongoing. The latest message is at 10:09 yet in the room list it appears in between two rooms at 10:32 and 10:37, because a vote was cast between those timestamps.
    IMG_1739

  • The room preview for a room with polls active doesn't acknowledge the latest event was a poll vote, ie it doesn't show 'A vote was cast' or similar. It's confusing to see a room jump to the top of the list, yet the message preview stays the same, not informing you why the room jumped.

So we're in a situation where the room ordering does acknowledge poll votes, but the room list preview and the timestamps on the room list do not. Creating a strange experience when put together.

  • In other chat apps, like WhatsApp, votes do not bump the room in the room list. Perhaps users are therefore used to that same behaviour

(I'm sure not the most important issue right now, just wanted to capture some thoughts while I had them!)

Outcome

What did you expect?

The room with votes to stay in it's position in the room list order, despite votes being cast. Unless an actual new message is sent.

What happened instead?

The room lives at the top of the room list, in my case accentuated by the room having 50 people with active polls.

Your phone model

No response

Operating system version

No response

Application version

663

Homeserver

Synapse 1.112

Will you send logs?

No

@pixlwave
Copy link
Member

This is a known limitation we have right now: It should behave correctly in unencrypted rooms, but as the bump types include m.room.encrypted events and poll votes are encrypted, this is the behaviour we see in encrypted rooms.

It's possible that with a combination of local sorting and (soon) SSS, we might be able to work around this, but gappy syncs make it a lot harder.

@pixlwave pixlwave added X-Needs-Rust This issue needs a Rust SDK change. It must have a link to a Rust SDK issue A-Room-List S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Occasional Affects or can be seen by some users regularly or most users rarely A-Polls labels Jul 30, 2024
@manuroe manuroe added the A-SSS Regression or bug observed when using Simplified Sliding Sync label Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Polls A-Room-List A-SSS Regression or bug observed when using Simplified Sliding Sync O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Rust This issue needs a Rust SDK change. It must have a link to a Rust SDK issue
Projects
None yet
Development

No branches or pull requests

3 participants