While implementing it in multiverse, I realized that sending a reply in a thread-focused timeline is kinda weird: one must use Timeline::send_reply() and enforce the thread relationship in there.

I would expect that, as a user of the threaded-timeline, all I need is use Timeline::send when I want to answer in that thread, and Timeline::send_reply when I want to send an explicit reply to another in-thread event. Now it means that Timeline::send would fill in the m.relates_to relationship field to the thread, if and only it's missing. This way, it's still possible to send other aggregations, notably edits, to an in-thread event (an edit sets m.relates_to to replace).

If we made the APIs like this, it would likely simplify Timeline::send_reply so it doesn't need the Reply parameters, and only take a simpler enum as it did before (enforce thread relationship or not — which would be ignored in the case of a thread timeline).

This means that to start a thread, one would need to open a thread-focused timeline, and then use that timeline's send() (vs what we have now: using the main timeline, use send_reply with a thread relationship in the Reply parameter).

I think it might be worth it, but I'm curious to get feedback about this idea; cc @stefanceriu @Johennes, what do you think of this?