27 Apr
2025
27 Apr
'25
1:26 a.m.
Hi,
Adding a few design notes from my experience with other platforms.
Hopefully this will help inform further discussion.
> I don't see that it's needed to check for
other replies. If two
> people start a
> reply at the same time, there will be two threads with the same
> parent, in the
> UI this appears like a tree, i stays readable. This is what happens
> on sites
> like Reddit on ActivityPub (but on Mastodon, the tree doesn't appear in
> comments, making it very confusing IMO).
ActivityPub uses the concept of "parent post" rather than "threads".
And
yes, it does get confusing when the replies branch out into a tree and
then get "flattened" out for display in interfaces like Mastodon's.
If I want to choose a single strand of the conversation, I would choose
the last post in that sequence, and then get presented with all direct
ancestors of that post (which is a single strand as each child can only
have one parent). I think this "single linear sequence, among possibly
many", is what originally became Twitter-style "threads" (now used by
Mastodon too).
In summary: AP "threads" are basically "a sequence of posts where each
post is a child of the immediately preceding one", but as each original
post can branch out into many "threads" I'd say it's more of a GUI
consideration than anything else.
Never used those services, but the normal flow i
imagine is, im in a
support channel, someone asks a question "How do i do X?", now 2
people start to type, and create two separate threads with the answer,
now a 4. person wants to join, then the client needs to decide to
reply to one of the threads.
Also from the GUI side its unclear how should handle this, should i
hide the fact that there are 2 threads? Should i show 2 threads? But
then obviously both users wanted to answer the same person, i would
say it would be the expectation that this conversation is wrapped in a
single thread and not multiple.
What happens in AP in practice is that the third commenter would make
another reply that is a direct child of the original post (yet another
"thread" if you will). People also use it in this way; if I wanted to
reply specifically to Commenter 1 I would reply to Commenter 1's post,
but if I wanted to make a general comment on the entire conversation I
would reply directly to the main thread.
This is very different from how I would approach interacting with a
conversation in a chat-oriented app (XMPP or otherwise): on ActivityPub
I'm more diligent about selecting the specific message I want to reply
to. I think that's partly because each reply is a "post" in its own
right that could be shared, boosted, etc. and show up on peoples'
timelines as an entry point to whatever they're going to see next.
Depending on which message I reply to, they'd be presented with a
different view of the conversation (which they could change, of course,
but it is their first view of the entire conversation).
Finally, with regard to moderation/retraction: with ActivityPub software
(including Akkoma and Mastodon), when I'm deleting a post I get a
warning that any replies to that post will be "orphaned", i.e. not have
a parent any more. I have also seen some posts where in place of a
parent all I get is "this post no longer exists". So it is arguably an
issue there as well (but see my next section with thoughts about threads).
------------------------------------------------------------------------
On a different note, since there was some debate about how to include
thread IDs: Discord, unlike AP, treats "threads" and "a sequence of
replies" as two different things. The default mode is to have all the
conversation inline (no threads/parents/etc.) but if there's a sequence
of replies (a message, to which there is a reply, to which there is
another reply) then it asks if I want to "convert that message to a
thread". (One can decide to make a message into a thread at any point,
but the UX explicitly suggests it when it thinks a sequence of replies
has gone on for long enough)
At that point, only the parent message will be shown in the main message
area and subsequent replies (which are all linear/sequential) show up
only when you click on that parent message to navigate into the thread.
Mattermost, on the other hand, does "both" which I suppose is somewhat
similar to Mastodon. Replies are internally a "tree of replies", but the
default view is to show only the first message and make the user click
through to see the other replies in a linear way (so, visually similar
to Discord "threads").
However, there is also an option to turn off "threads mode" at which
point all the child replies will show up along with the main messages
(visually similar to Discord "replies"). In this mode clicking on any of
the child messages will show up the entire "thread" (i.e. initial parent
message and all it's descendant replies).
In my opinion Mattermost is the most confusing as people experience the
messages differently depending on their settings. For XMPP, perhaps we
should first decide which of "linear threads" or "branching-out
replies"
is being defined? Even if we have both, in my opinion it would be better
to treat them as separate (if somewhat related) concepts. Linear threads
would be the ones with thread IDs whereas "branching out replies" don't
need to have anything to do with threads at all.
After typing the above, I realised that Goffi had outlined these
different modes of thinking too; I am pasting a quote for reference:
The way I got it, we have basically 2 ways to see
threads:
1. A series of replies to any message in a group chat, à la Slack (in Slack,
you see the replies hidden under parent message, with something like "X
replies", and when you click, a panel appear with the whole thread.
2. A side discussion explicitly started, that could be seen like a new chat
window (UI example: user clicks a "start a new thread button", and start a
blank window with it message, this message has a new thread ID, that will be
used by people replying to it).
As I said, I think it would be best to treat these as two separate
features, and either decide which we want or do as Discord does and
offer each as distinct options.
Best,
Badri