Bold is too unclear for unread messages.

[ara4n]

Long-standing problem, particularly on the dark or Status themes, is that using 'bold' to indicate unread is way too cryptic and hard to spot.

Maybe show an unread counter on rooms as per #3374? 😇

[lukebarnard1]

I was thinking we could do a small circle to the top-right of the room avatars, although it would end up conflicting with badges a little bit.

[ara4n]

i think @Matrixcoffee's suggestion of revisiting #3374 is a good one; it's a bit weird that there isn't a way to be told how many unread messages are in a room (only unread notifications). A better solution might be:

• 10 unread messages (no notifications) = 50% transparent green badge with number 10
• 10 unread messages (of which 5 were notifs) = solid green badge with number 10
• 10 unread messages (of which 5 were notifs, 1 was a bing) = solid red badge with number 10

@lampholder wdyt?

Every time we've changed the badge settings it's been a huge can of worms, but i'm not sure that the suggestion here is bad (although we'd end up with a lot more badges flying around the place, and so look busier)

[ara4n]

oh - the problem here, thinking about it, is that maintaining unread badge counts is surprisingly resource intensive on the server, and doing it for every room (whether notifs are turned on or not) might be completely nightmarish for synapse. On the otherhand, it might simplify the logic and make it easier to maintain (given we're just tracking unread messages rather than unread notifications). @dbkr, any idea?

[dbkr]

Yep, indeed this needs server support because the only way the client would be able to know is by paginating all the way back to its last read marker which could be a long way.

I suspect it's not fundamentally difficult and probably not that resource intensive - most of the pushrules stuff is running the push rules themselves, ie. the fact that everyone could have different rules. I suspect the hardest part about this would be incrementing a counter for everyone in the room (or rather, saving that back to the db in a way that's fast and safe).

One gotcha is that not all clients are necessarily able to render the same types of messages, ie. in Riot we avoid bolding the room for message we don't display, but the server doesn't know which messages we're not going to display. This could be another thing solved by all renderable events sharing a 'body' field. ;)

That said, you could also increase the number of messages we get per room in an initial /sync to, say, 11 (I think we currently only sync 2?). This would let you display a correct count most of the time except when you first logged in / cleared cache, at which point if it was more than 10, you'd display '10+' or something. This would obviously increase login time though.

[t3chguy]

One gotcha is that not all clients are necessarily able to render the same types of messages, ie. in Riot we avoid bolding the room for message we don't display, but the server doesn't know which messages we're not going to display. This could be another thing solved by all renderable events sharing a 'body' field. ;)

Except riot also doesn't bold on hidden events (hide parts joins whatever)

[turt2live]

That said, you could also increase the number of messages we get per room in an initial /sync to, say, 11 (I think we currently only sync 2?).

Setting up a new device takes long enough as is :(

Do the unread counts need to be exact? Could we get reasonable results by looking at the message depth field?

[t3chguy]

I think if it said 7 unread messages and I open it to find 2 because of hiddenPartsJoins/whatever I'll be wondering what the hell happened

Right, 7 for 2 is clearly not a reasonable approximation.

So get low counts directly from the sync, possibly with some kind of server-assisted middle ground to deal with the 2-10 event gap. For higher counts, you'd probably be able to get away with a ballpark figure from the message depth.