marking rooms as unread

Signed-off-by: Marcus Hoffmann <bubu@bubu1.eu>

proposals/2867-rooms_marked_unread.md

@@ -0,0 +1,73 @@
+# MSC2867: Marking rooms as unread
+
+There is currently no way to mark a room for later attention. A common use-case is receiving a 
+notification on the go and opening the corresponding room but then deciding to deal with it at a later time.
+
+They'd then just mark the room as unread and when opening a matrix client on their desktop PC that rooms 
+would appear prominently in their room list waiting for attention.
+
+Similarly one might want to mute a rooms notifications while there's a discussion going on but still flag it
+for catching up later.
+
+Both WhatsApp and Telegram offer this functionality.
+
+## Proposal
+
+We add a [room account data](https://matrix.org/docs/spec/client_server/r0.6.1#put-matrix-client-r0-user-userid-rooms-roomid-account-data-type) 
+field `m.marked_unread` which just stores the following:
+
+```json
+{
+  "unread": true | false
+}
+```
+
+When this is true a client should show the room with an indeterminate unread marker. This marker should
+be of similar visual importance to a notification badge without the notification count. For example if 
+you have a red circle with small numbers inside for counting notifications next to a room then a room 
+without notifications but marked as unread should have just the red circle. If a client gets new 
+notifications after marking a room as unread the notification count should be displayed instead as normal.
+
+The `m.fully_read` marker should not be touched when marking a room as unread to keep the users read position 
+in the room.
+
+Marking a room as read, if a client implements such a functionality, now involves read receipts for the last 
+event as well as setting `m.marked_unread` to false.
+
+The unread flag should be cleared when opening the room again.
+
+## Potential issues
+
+Client not aware of this feature will not clear the unread flag, when reading the room. In addition they'll obviously 
+not show the room with a special badge. This seems preferable the alternative of clearing the unread flag of a room
+without intending to because it didn't actually show up as unread.
+
+## Alternatives
+
+There are multiple possible alternatives here;
+
+* Marking individual messages as unread as discussed [here](https://github.com/matrix-org/matrix-doc/issues/2506):
+  This is a far more complex feature that has possible interactions with server-side implementations and notification
+  counts. This proposal aims to be a far more lightweight alternative. Looking at other messengers marking a room as 
+  unread is a more common operation than marking messages as unread, so it could be argued that others already found 
+  this to strike a good balance of complexity and use-cases covered.
+* Modifying the `m.fully_read` marker instead of introducing the new `m.marked_unread` field:
+  Another idea was setting the `m.fully_read` marker to some earlier event which would then cause clients to show 
+  unread messages again. This has two problems:
+    * It makes it harder to distinguish between rooms which happen to have unread messages that you don't necessarily 
+      care about and rooms which were manually marked as such and thus should be shown much more prominently.
+    * When trying to work around this, by setting the marked at a special location like the room creation event then we completely
+      lose the the user's actual read position in a room when using this feature.
+
+## Security considerations
+
+None.
+
+## Unstable prefix
+
+While this feature is not yet fully specced, implenmenters can use the `com.famedly.marked_unread` room 
+account data type.
+
+Implementations using this unstable prefix in a released version should automatically migrate 
+a users unread rooms to `m.marked_unread` when this is released as stable.
+This ensures the users unread rooms are not lost.