MSC4306: Thread Subscriptions

[reivilibre]

Rendered

[clokep]

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. 😢

[Johennes]

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?

[reivilibre]

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.

[Johennes]

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.

[clokep]

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.

[clokep]

I wonder if expanding this to "relation subscriptions" would be helpful for any other use-cases. So a subscription is parent event+relation type?

Might not be super useful with the current relations though.

[Johennes]

An API listing active subscriptions per room might also make unsubscribing easier?

[clokep]

I'm kind of surprised there's no changes to the /threads API?

[giomfo]

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

[MadLittleMods]

Why isn't there an endpoint to paginate all thread subscriptions in a room? (my expectation)

Similar to how clients back-paginate with messages in a room by starting with /sync and then using /messages to get the rest as necessary.

[reivilibre]

This would be pretty shoddy for performance if it was per-room (= 1 request needed per room), but maybe a global endpoint would be OK.

It just felt like sliding sync would do the job of getting the state down to the client without much fuss (like for room account data), but maybe that's wrong

[bnjbvr]

It just felt like sliding sync would do the job of getting the state down to the client without much fuss (like for room account data), but maybe that's wrong

We'd need to increase the equivalent of "timeline_limit" to simulate back-pagination, and that complicates a few things:

• if we're using the same SSS connection, then we're penalizing other updates, because we might change the connection parameters again and again until we've "paginated" all the receipts of all rooms
• …or we have to use a different SSS connection just for that, but it sounds a bit overkill 🥲

So agreed with @MadLittleMods that having the same "N last + pagination token if needs be" would be ideal.

[reivilibre]

This seems to boil down to: we should add an endpoint for backpaginating these. I'm tempted to push that into MSC4308 since it seems to complement the Sliding Sync API nicely

[MadLittleMods]

Pagination endpoint added in MSC4308

More discussion -> element-hq/synapse#18695 (comment)

[andybalaam]

Should we also subscribe when a user sends a message within a thread?

[clokep]

Yes IMO

[reivilibre]

Added the semantics for this in 84be8db, let me know if that works :)

[bnjbvr]

For what it's worth, I thought there was a little chicken-and-egg problem here, in the case of a new automatic subscription, but turns out there might not be.

Say I receive an event that would automatically subscribe me to a thread I haven't subscribed to (nor unsubscribed from). At this point, the thread subscription push rule wouldn't be triggered, because the subscription doesn't exist quite yet. But I'd expect the client to still notify about the thing! However, if an automatic subscription were to happen, that's likely because other push rules decided so: I've been mentioned in the thread, or there was a keyword mention, or something else. So there should be some notification created for that other event, which then causes the automatic subscription to the thread.

A notification will exist for the initial event that causes an automatic subscription; it is just not created by the new push rule yet. Future events in this thread will imply notifications because of the thread subscription push rule.

Am I getting this right? If so, it may be worth mentioning this around here, to help client implementations?

[reivilibre]

Yeah, you have it right.
Notably, the push rule unsubscribed_thread is lower priority than the push rules for mentions, so it won't prevent you getting notifications for mentions

Though looking at it now, this unsubscribed_thread does have higher priority than the rule that makes the server always push encrypted events to clients, so that's an angle we might need to find a solution for.
Could well be 'this rule needs to get ignored on encrypted events' :/

[bnjbvr]

Another precision question: should the wording say "when a user is mentioned" (in which case we're only interested in intentional mentions), or should the wording say "whenever a notification would be generated by push rules" (which then also includes keyword mentions, and would nicely generalize to any trigger of current and future push rules, making it future compatible as well)?

[bnjbvr]

Hmm, maybe not such a bright idea: in this case, in a room where I'd get a notification for any message, I would be automatically subscribed to every thread (since every thread message is a message, and would trigger a notification).

It would be nice to clarify the intent here:

• should we auto-subscribe any time a notification would be generated (per the push rules), as hinted in my previous comment?
• if not, what's a mention? (keyword mention? username mention in clear text? intentional mention in metadata?)

[reivilibre]

this was intended to be very explicitly mentions, but you're bang on that we should carefully say what we mean here.

Here's my thoughts:

• @room — both intentional and fallback
• intentional user mentions
• fallback plaintext mentions
• keyword mentions

[zecakeh]

Fallback mentions are going to be removed from the spec since MSC4210 was accepted.

[reivilibre]

added in c3fecfa, let me know if this suits

[anoadragon453]

Overall I love how clearly written this MSC is; kudos.

[anoadragon453]

I'm curious how this portion of the MSC would be translated to spec text. I worry if we have a separate list of "what's a mention", then that may because out of date over time.

Was this included to minimise inconsistent behaviour between clients w.r.t subscribing to threads?

[reivilibre]

Hmm, the secret is, we don't have a concept of mention for the subscription rules, that's just the intent. It's actually based on the existing push rules. (Kind of hard to read in between all the threads that interrupt, but if you look closely it's there, I think!)

So the spec text should probably try to make a stronger distinction with e.g. 'subscribe-on-notified', perhaps clarifying that the intent was for mentions to trigger this, but not only.

[anoadragon453]

Servers have access to ignored users and membership metadata (currently). Would it not make sense for the server to take this on?

[reivilibre]

Hm, interesting point. Wasn't intending for the server to store the information about which events contain mentions (it's not super nice for metadata); was also ultimately hoping that sending the event IDs would be a temporary workaround until clients can determine ordering themselves.

Maybe we are just essentially divulging metadata to the server anyway, without making the most of the information server-side? Not sure.

[anoadragon453]

M_SKIPPED and M_NOT_IN_THREAD should have unstable alternatives as well.

[MadLittleMods]

Is it possible to pre-subscribe to a message so if people thread off it, you can catch it?

[MadLittleMods]

Spawning from a comment on a implementation PR,

Currently, in Synapse, this is implemented as when a person unsubscribes, it will store the latest stream_ordering and topological_ordering in the room to compare against any future subscription 'cause' events.

Looking up the max stream_ordering and topological_ordering on the server at the time of unsubscription has the flaw that if the client has an outdated view of the world and sends an unsubscribe, we will be unsubscribed even though other clients may see new mentions in the thread that they want to subscribe to.

[reivilibre]

My justification here is that, talking of user action, 'unsubscribe means unsubscribe' and 'subscribe means subscribe'. i.e. if the user wants to do something, we don't question them.
I think this is ultimately defensible, even if you could argue both ways about it.

It's a fairly slim window for a race, and even still, if you clicked unsubscribe at 18:09 but later scroll down and notice you are (still) auto-subscribed because of an event at 18:07 that you didn't read yet, would you think the software was being reasonable or unreasonable?

[zecakeh]

postcontent should use an unstable prefix for now.

[bnjbvr]

I've used io.element.msc4306.postcontent at the time being, in the Ruma PR implementing the new push rules changes. Not sure it should be that or post_content, depending on how would one capitalize it: Postcontent or PostContent. (Let the doors of bikeshedding hell open :))

[ajbura]

If the proposal is to receive notification for all messages from "subscribed" thread could not that be achieved with the existing push rules semantics? Example:

{
  "conditions": [
    {
      "kind": "event_property_is",
      "key": "content.m\\.relates_to.rel_type",
      "value": "m.thread"
    },
    {
      "kind": "event_property_is",
      "key": "content.m\\.relates_to.event_id",
      "value": "$thread_root_message_id"
    }
  ],
  "actions": [
    "notify",
    {
      "set_tweak": "highlight"
    }
  ],
  "rule_id": "$thread_root_message_id",
  "default": true,
  "enabled": true
}

[bnjbvr]

In the set of conditions, where does the fact that the user is subscribed (or not) to a thread appear?

[ajbura]

Client can check for the rule_id generated with thread root event_id in m.push_rules. If it finds the rule that means user has opt for "subscribed" (if rule has actions) and "unsubscribed" (if actions are empty). If it does not find any rule, client will work how it works currently and suggest for "subscribe" / "mute" thread button in UI.

[bnjbvr]

Interesting idea, thanks for bringing it up. I think that it's a tradeoff: the approach you're suggesting here would likely make the size of the rules event blow up, especially thanks to the prescribed automatic subscription mechanisms which could add lots and lots of subscribed threads by default. The approach suggested in this MSC makes it a default rule, that requires a bit more work during evaluation of the push rules (now, a client might need to fetch via network, or load from disk, the subscription status of a thread). The MSC's approach doesn't make the push rules event grow linearly with the number of threads one's subscribed to/muted, which I find a strong benefit here.

[reivilibre]

Main problems I can see are that I would rather avoid speccing anything that depends on an unlimited account data size, ultimately.

Other than that, this doesn't support the automatic subscription ordering logic that we need.

[ajbura]

After reading again through the msc, I have following concerns which might be helpful for this alternative consideration:

1. Automatic subscription have exploitable behaviour and "Malicious users can be ignored by the user" is practically undoable as a system can not easily detect Malicious users, the same problem as we have with invites. And since the mention already create notification a user will notice the activity in thread and can decide to subscribe/ignore when they will open the thread.
2. Since the notification preference for "subscribe" and "unsubscribed" is applied on all rooms a user can not configure it per-room bases. Example: 1) I want to receive notification for all thread messages from my work related room and not for public community rooms. 2) I want sound notification from my subscribed thread from work room but without sound from public community rooms.
3. If a room is muted subscribed thread rule in postContent is suppressed as muted room rule will be in override.

We may can consider this kind of three rules:

1. In underride to configure default notification behaviour for all rooms and for all thread replies.
2. In rooms to configure notification behaviour for specific room for all thread replies.
3. In override to subscribe to specific thread

Although the event size will always be a limiting factor, but a client can provide a section for all subscribed threads to maintain this list but the experience of such a feature will depend on the quality of implementation.

[bnjbvr]

Re (2), is there anything preventing a client from reusing the thread_subscription condition kind in a rooms rule? I don't see any such restriction, so the behavior you're describing could be implemented by reusing this condition kind in this section.

[reivilibre]

(1) Automatic subscription have exploitable behaviour and "Malicious users can be ignored by the user" is practically undoable as a system can not easily detect Malicious users,

This is referring to the user's own 'ignored user' list, not any automated system.

(2) can be configured with push rules, but we are cautious about suggesting exposing too many control knobs to users because it makes for confusing UI

(3) a room being muted when muted is indeed intentional. As described in the MSC, the mental model is that the 'Mentions & Keyword' setting becomes equivalent to 'Mentions, Keywords & Subscribed Thread' and this is the level we're working at. (Our hands are also tied whilst keeping the push rules as sane as possible, until push rules are replaced in the future)

---

The account data being of unlimited size is considered a mistake, fwiw, therefore I don't buy that we should rely on it for this.

[ajbura]

Re (2), is there anything preventing a client from reusing the thread_subscription condition kind in a rooms rule?

Yes, since the msc specify that:

we propose the addition of two new push rules, both added to a new push rule kind called postcontent, which is ordered between content and room

any rule added in rooms with condition kind: thread_subscription will be overridden by the same rule in the postcontent since it has the high priority over rooms.

[ajbura]

(3) a room being muted when muted is indeed intentional.

I am not sure if i get it correctly. What i mean was that msc says.

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.

user can not get notification for subscribed thread because the room mute rule is added to the override section and apply on every event and should suppress the subscribed thread notifications per the spec.

[ajbura]

Since the default thread subscription state is "unsubscribed", could not this confuse user as the propose of showing "activity" is to advertise user that there can be possible interesting conversation. This suggestion can make user missing them.

Also the exceptions mentions to generate notification for "mentions" which includes room mentions, user/fallback mention, user configured keywords. but the push rule semantic is free for other personal customization wondering how that will with work with them.

[reivilibre]

The default 'unsubscription' state is intended to reduce noise and notification fatigue, so keeping it squirreled away in the UI is kind of intentional — not that you can't have other UI to surface missed activity there, just that it shouldn't (in principle) count as noisy room activity.

The semantics are written in https://github.com/matrix-org/matrix-spec-proposals/pull/4306/files#diff-f42a2b8bda41aad63a982965d5f5b7165e62ddc06484c0ee3806024646ab9fdaR140 and should generalise semi-well (about as well as one could hope, given the free-for-all nature of push rules) to custom rules.

[ajbura]

The proposals says:

I do not want to see the room as unread because there are new messages in an unsubscribed thread.

It says unread (generally a dot without count) compare to notification (noisy/not) (badge with count). Notifications as badge-with-count are suppressed purposefully but unread as dot-without-count indicate general room activity is what I have concern about.

[reivilibre]

Yes, suppressing the indicator of room-wide activity is considered a good thing, because it reduces the cognitive load on users. But for use cases where it's important to see all activity, I think it is easy to either disable the push rule or provide other UI if necessary