MSC2836: Twitter-style Threading

[kegsay]

Rendered

Implementation: https://cerulean.matrix.org/ Server: https://github.com/matrix-org/dendrite/tree/master/setup/mscs/msc2836 Client: https://github.com/matrix-org/cerulean/

[kegsay]

I think i'm being thick, but i still don't get how you know whether your result got clipped by max_depth or max_breadth and how you know whether to continue downwards or sideways to grab more of the tree or not?

There is no explicit return value to indicate that the max_depth or max_breadth was hit. If a request reaches the limit, events further away will be retrieved, if you want to walk down a specific path, you need to make an /event_relationships request with that new event ID.

---

              depth
   A           0
   |
   B           1
  / \
 C   D         2
 |  /|\
 E F G H       3
 |   | |
 I   J K       4
     |
     L         5

given event_id=A max_depth=4, max_breadth=2, limit=10, depth_first=false, recent_first=false (and earlier letters are earlier events) the following items are returned:

A,B,C,D,E,F,G,I,J - 9 items, no next_batch.

This is because the max_ params create a bounded window over the graph, and it is this graph that gets looped over.:

              depth
+-------+              
|   A   |       0
|   |   |
|   B   |       1
|  / \  |
| C    D|       2
| |  / || \
| E F G | H     3
| |   | | |
| I   J | K     4
+-----|-+           max_depth=4
      L         5

Changing the limit to be 5 just returns the first 5 elements in this graph (A,B,C,D,E), and the next_batch returns (F,G,I,J). It may be desirable to somehow encode the number of clipped items (for UIs which have "see all 97 comments") in the parent event (in this case D would say it has 3 children), however in practice a lot of UIs just have "see more" which can be easily accomplished by setting a max_breadth 1 greater than the number of items you wish to display so you know that there are in fact more items to see. Clicking on "see more" would do a new /event_relationships request to load that part of the DAG.

[nidico]

This is not related to the Threading MSC draft by @timokoesters, which was linked from This week in Matrix two weeks ago, right?

[cognifloyd]

This does not address defining "visibility" when creating a message with a relationship to a previous message. eg: Slack's threads (though limited to a breadth of 2: the main room, and one layer of offshoot coonversations) allow users to say: "show my message BOTH within the thread" (according to its relationship) "AND as a top-level message".

This sounds similar to Cerulean's "symlinks", but instead of being in multiple rooms, it would be: show this message in multiple places within the same room.

Would such a feature be something for a separate MSC? Would anything in this MSC prevent adding such a feature later?

[kegsay]

Such a feature isn't a hard requirement for threading fundamentals so would be best as a separate MSC. Nothing in this MSC prevents this being added: I would probably just define an extra key on the message e.g visibility: "top" (naming aside) which, if present, is interpreted by clients as being displayed in both places.

[gleachkr]

Perhaps this is out of scope, or clear to others who are more experienced---I'm new to this, so apologies if this is completely off base. But, here goes: I've found myself wondering how this relates to read receipts, or if it might require modifying how read receipts are handled.

From what I understand, receipts are required for all clients except embedded IoT. They indicate that the client has read everything "up to" the referenced event. It's not clear to me what "up to" necessarily means in the context of any of the models for threading (twitter, reddit, swimlane) under discussion, but if it means "up to this point in the linearized event stream coming from the server", then it seems like serious threading would make it difficult to guarantee that the user had read everything up to the referenced event - it would also make that information a bit less useful, since it's likely that what other users care about is what they've read "up to" in a given thread.

[SimonBrandner]

@gleachkr, I think there is a quite big chance that the read receipts will be reworked. Right now they are coupled with notifications. That is also a problem because if a user wants to disable read receipts (and some want) it breaks the notifications.

[hiredman]

Forgive me if this is hopelessly naive, but spaces have me thinking about rooms as a graph, and this MSC is creating DAGs of events in rooms, and I wonder those two graphs could be the same. Could a reply thread instead of being events with specific relationship attributes, instead just be a room whose parent is an event in another room?

[erkinalp]

Could a reply thread instead of being events with specific relationship attributes, instead just be a room whose parent is an event in another room?

Different usecases. Threads as relations for continuations, threads as rooms for detached and/or limited membership threads.

[kegsay]

@turt2live this has an implementation.

[sandstrom]

Just wanted to chime in and say that I think Twist-style threads would be a nice addition. Where the top-level of each room/channel must be a thread, and that each thread may only contain messages at one level (no nesting).

Preferably with some thought to different states of the topic/thread. For example open, closed, archived -- such that one can setup life-cycle rules like 'delete threads X months after they were closed' or UI filtering, show me only open and recently closed threads by default.

Something that looks like this:

    #office [room/channel]
       * Lunch [thread/topic]
         - Anyone wants to grab lunch today? [message]
         - Sure, I'll join! [message]
         - Me too! [message]
       * Printer doesn't work [thread/topic]
         - Anyone else having trouble with the printer? [message]
         - I fixed it an hour ago actually, try again [message]
         - Thanks, it works! [message]
         - (thread closed)
    #marketing [room/channel]
       * Website Update 2022 [thread/topic]
         - (posting images) [message]
         - Here is the new draft, let me know what you think! [message]
         - Looks good, but there are some spelling mistakes… [message]
         - Nice work! [message]
       * Adwords Campaign [thread/topic]
         - Here is a new adwords campaign structure. Let me know what you think! [message]
         - How about splitting by geografy and demographics? [message]
         - … [message]
         - … [message]
         - Alright, new campaign is live, thanks everyone! [message]
         - (thread closed)
         

[turt2live]

It appears we have settled on https://github.com/matrix-org/matrix-spec-proposals/pull/3440 for our threading implementation:

@mscbot fcp close

[mscbot]

Team member @turt2live has proposed to close this. The next step is review by the rest of the tagged people:

• [x] @dbkr
• [ ] @uhoreg
• [x] @turt2live
• [ ] @ara4n
• [x] @anoadragon453
• [x] @richvdh
• [x] @erikjohnston
• [x] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[mscbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[mscbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

[ara4n]

I'm not sure we should have closed this, ftr - it provides an entirely different set of threading semantics (i.e. twitter-style threads) to the slack-style ones we've ended up on in #3440, and could well still end up being useful - or as useful as many other open MSCs.

[Sieboldianus]

Does this mean the end of the awesome cerulean.matrix.org? (see Introducing Cerulean)

[ara4n]

I'm taking the liberty of unclosing this, as it's still completely relevant, especially with Twitter's current transformations. I'll rename it to differentiate it from the threading that Element currently implements.

[melroy89]

Still not merged!?

[filipesmedeiros]

Even more relevant when Dendrite (the newer generation of the Matrix server) implements MSC-2836 but not #3440.

Is anyone looking into this? :)

Thanks!