Threads: Launch Plan

[daniellekirkwood]

This issue considers the launch plan for Threads.

• We intend to launch Threads with m.threads implemented
• We will launch on different platforms at different times
  • All clients should be Threads aware before the first launch (web)
• 3 rounds of testing will take place on each platform before launch: Smoke testing, User testing, & Acceptance testing

Until we're using m.threads we will not launch or default Threads to 'on' in any environment. More info in comments

---

Rollout plan for Threads

Beta is opt-in for the first release to stable environments.
Why? We are confident in our solution but given the known limitations of our implementation at this time we want to continue to allow users to chose to use Threads. The biggest piece of this is the outstanding work on Notifications.

Step 1: Opt-in Beta

• On Mobile, Threads remains available in Labs as they are today
• On Web, we want to promote Threads out of Labs but disabled by default

Step 2: Opt-out Beta

• Once we have read receipts, notifications, sort ordering of the thread list, and confidence in the stability and reliability of threads we will move the Beta to opt-out (Fast follow issue complete)

Step 3: Out of Beta

• Polish and stability of Threads improved we’ll remove the Beta/Labs flags and promote Threads

[germain-gg]

Having a room level setting to toggle threads brings some a few questions from the tech point of view.

Historically all events were received by the SyncApi and dispatched to a room's timeline. Threads slightly changes that assumption and now create one timeline per thread and attaches it to the room. Which means that upon changing that room setting, all room members that currently have Element Web running, will need to re-parse all their event history for that room so that we can ensure that each event ends up being on the correct timeline.

When toggle the threads lab flag we are using the ReloadOnChangeController. It was first introduced by Spaces, as they needed to parse the rooms differently in the SyncApi

I can see two approaches to solve this problem

1. We need to put in some effort to reliably reparse the history of a room without refreshing the application.
2. We display a toast, prompting room members to restart their application. Failing to do so means that they will keep seeing threads as replies until they do restart Element

The former can easily become a mess and I would be worried forgetting to remove an event listener which could cause some oddities after the flip of that switch. Whereas the latter could become annoying if a lot of rooms change that setting in a quick succession

[clokep]

From a bit of discussion with @daniellekirkwood it seems that the hope of this is that a room admin is able to enable/disable threads for all users in a room.

I think the obvious way to do this is with some sort of state event, but I'm not sure if that's the plan? What happens to threaded events when it is disabled? (Or is it only a one-way flag?)

An alternative (which is much more involved to implement, but could be more useful long-term) would be to augment the power-levels system to include who can send relations (and what sort of relations they can send). This could allow for, e.g. disabling reactions in a room and such too. This wouldn't be something we'd want to do quickly and rip out though (it would require a room version upgrade, etc.) So I don't think it fits the bill, but is interesting to ponder!

[germain-gg]

I think the obvious way to do this is with some sort of state event, but I'm not sure if that's the plan? What happens to threaded events when it is disabled? (Or is it only a one-way flag?)

Given that we're building threads in a backwards compatible way, a client can still request all events for a room, and display those as replies.
All of this currently happens in the SyncApi in the js-sdk. All incoming events are analysed and they are partitioned between events that belong to a thread and those who don't

When doing that analysis we can read the room settings and decide on how those events should be triaged

[daniellekirkwood]

Launching with or without the stable prefix

Threads is currently using an unstable prefix. When we turn off support for that all messages sent with it will be moved from Threads to the timeline. While no messages will be lost (a principle for the Threads project), messages will not be where users ‘left’ them. Threads team think that it’s important to ship Threads to production when we have a version of Thread’s that will endure - when the thread messages will always live in a thread view.

It’s also been suggested that we default Threads to “on” in Develop environments which we are less reluctant to do but we at least want to wait until the Notifications bug has been fixed. When we know the timeline between the MSC landing and the fixed notification bug we might have negated the need to make a decision about defaulting Threads to “on” in Develop. TBD.

[novocaine]

Launch plan: https://docs.google.com/document/d/1AxbVXguZqJIRQGd6jYYKDrlt5148ZMqgLxBzt2CO_Ag/edit

We will not be implementing a room-level setting for launch as we believe the reply-chain fallback mechanism provides a good enough experience for bridged users.