MSC4306: Thread Subscriptions #4306
Conversation
reivilibre
changed the title
reivilibre
force-pushed
the
rei/msc_thread_subscriptions
branch
from
1b3a088 to
3f1e83a
Compare
| - Clients could maintain thread subscription settings in Room Account Data, as a map from event ID to the subscription settings. | ||
| - This would be inefficient by requiring the entire subscription set for an entire room to be transferred at once, for example in Sliding Sync. | ||
| - This would make subscriptions vulnerable to Read-Modify-Write race conditions (though this could be addressed with extensions to the Room Account Data APIs). |
There was a problem hiding this comment.
My hope was you could use (room) account data, but that doesn't have a "state key" or anything. I think it also limits you in size, which probably wouldn't work. 😢
There was a problem hiding this comment.
I was also thinking of account data and I believe it isn't subject to the 64KiB limit?
What were you planning to use a state key for with thread subscriptions?
There was a problem hiding this comment.
Using account data in this way may not have the 64 kiB limit, but ideally we should try to avoid using it in more places that will make it hard to add that limit. (Since the lack of a limit is a mistake, I believe.)
The two problems I noted above are the main reasons I don't like using account data here:
- The read-modify-write issue
- Clients and servers having to operate on whole lists when they only care about one tiny portion of it.
I think Patrick's 'state key' mention is along the lines of: 'we only have a single key for each piece of room account data: the type'.
You could imagine using having an extra key, so room account data could be keyed on (m.thread.subscription, $abc123def456).
Or we could stretch things further to have 'Event Account Data' or something.
There was a problem hiding this comment.
I think Patrick's 'state key' mention is along the lines of: 'we only have a single key for each piece of room account data: the type'.
You could imagine using having an extra key, so room account data could be keyed on (m.thread.subscription,$abc123def456).
Oh, I see.
There was a problem hiding this comment.
Since the lack of a limit is a mistake, I believe.
Correct.
And your example of a state keys is spot on for what I was thinking.
turt2live
added
proposal
github-project-automation
bot
moved this to Tracking for review
in Spec Core Team Workflow
|
|
||
| If the client is already aware of the user being subscribed to the thread, then making a `PUT /subscription` request is not necessary. | ||
|
|
||
| If the mentioning user is banned, the automatic thread subscription should not occur. |
There was a problem hiding this comment.
Does "banned" mean the sender is in the recipient's m.ignored_user_list?
There was a problem hiding this comment.
I meant banned from the room, but the mentioning user getting ignored by the mentioned user also sounds like a good case to apply this!
|
|
||
| When a client becomes aware of a banned user in a room, it may need to backpaginate thread history to determine whether there are any threads whose automatic subscriptions should be reversed, or to determine if there are any other qualifying mentions that would obviate the need to reverse automatic subscriptions. | ||
|
|
||
| For efficiency reasons, clients may limit the depth of this backpagination with an implementation-defined recency limit, owing to the observation that abuse is usually cleaned up shortly after it occurs. |
There was a problem hiding this comment.
This sounds like it might either be expensive or leave dangling subscriptions. If the server exposed an API to list all thread subscriptions in the room, clients could use /relations to only walk the subscribed threads which might be more efficient?
There was a problem hiding this comment.
The idea would be that through MSC4308 (or another mechanism) the client will already know its active subscriptions, so indeed it can just walk the (recently- and automatically-)subscribed threads.
However it's hard to give a general definition of 'time' to describe how much the client should consider, so it's left purposefully flexible here.
There was a problem hiding this comment.
I would make optional this Reversal of automatic subscriptions. This add complexity client side for a low gain.
This is relevant to not subscribe if the mentioning user has been banned or ignored before the client takes into account the mention to set up the subscription.
I would let the user reverse manually the automatically subscribed thread if any
|
|
||
| - Messages in unsubscribed threads should not count as activity at all; as a user, I do not want to see the room as unread because there are new messages in an unsubscribed thread. | ||
| - Exceptions: if the user is mentioned, this should generate a notification as usual. (The push notification thus generated is also useful for the client to realise it needs to create an automatic thread subscription.) | ||
| - Messages in subscribed threads should always count as a notification, and the (effective) room notification settings should not matter at all. E.g. the room can be muted, but if I, as a user, am subscribed to a thread, I still want to get a notification for new messages in that thread. If I do not want that, then I will unsubscribe. |
There was a problem hiding this comment.
An API listing active subscriptions per room might also make unsubscribing easier?
| - There is precedent for this granularity in the popular forum software *Discourse*, but the author is not aware of Instant Messaging software with this granularity. | ||
| - With that said, this could be feasibly extended by a later MSC with no apparent issues. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
I'm kind of surprised there's no changes to the /threads API?
|
|
||
| - Messages in unsubscribed threads should not count as activity at all; as a user, I do not want to see the room as unread because there are new messages in an unsubscribed thread. | ||
| - Exceptions: if the user is mentioned, this should generate a notification as usual. (The push notification thus generated is also useful for the client to realise it needs to create an automatic thread subscription.) | ||
| - Messages in subscribed threads should always count as a notification, and the (effective) room notification settings should not matter at all. E.g. the room can be muted, but if I, as a user, am subscribed to a thread, I still want to get a notification for new messages in that thread. If I do not want that, then I will unsubscribe. |
There was a problem hiding this comment.
When a user mutes a room, it puts an override rule in for that room. And this override rule is the highest priority
So this is not possible to receive notification from a thread in a muted room.
The manual subscription should be disabled in this room at the UI level until the end user unmutes the room.
When a room is muted, the client should pursue the automatic thread subscriptions. These subscriptions will be ignored until the room is unmuted Keep managing the automatic subscription eases the potential switch mute/unmute of a room. The client UI should let the end user know any potential thread subscription is disabled in a muted room
Rendered