Mastodon: Add note to toot detail view explaining that only parent toots are fetched

Created on 19 Nov 2018  Â·  4Comments  Â·  Source: tootsuite/mastodon

Pitch

In the detail view that opens when clicking a toot, there could be a short note (right below the clicked toot?) explaining that there might be more replies than are visible, because only the toots higher up in the conversation get fetched by the instance.

Motivation

I've been using Mastodon since before any additional toots were fetched at all, and I only learned this today, and only because I was worried about my single-user instance being broken because it was "missing" so many toots.

I think back when parent-toot-fetching got added, the message got a bit garbled, and a bunch of people, me included, ended up thinking that all toots in a conversation would be fetched. I guess it makes sense, my small instance would probably be overwhelmed by all the additional toots, but it is important to know.

The smaller the instance, the higher the chances that I am missing a lot of what happens downthread unless I open a toot on its origin instance. That means that I might be replying to questions that have long been answered, or giving super redundant answers, if I assume that I have most of the context – as I did until today.

suggestion

Most helpful comment

Unless the replies are known to the server via primary means (following the author):

  • All up-thread posts are fetched (as long as nothing is deleted in the middle, I guess)
  • Replies to people the server follows are received via a forward

So if I am a@s1, and I follow b@s2, b@s2 posts something, and c@s3 replies to b@s2, I will see c@s3's response. In many cases that's enough, especially on larger servers because more people are followed. In large conversations and small servers, some chains of the conversation may be missing. b@s2's page will always have the fullest conversation.

All 4 comments

I for one want to see all the reply toots.

To be honest i only have a vague idea what search searches too, that's just known-by-instance stuff? Would be nice if it were clearer. Here too prefer an option to search it all.. Sounds technically difficult..

Unless the replies are known to the server via primary means (following the author):

  • All up-thread posts are fetched (as long as nothing is deleted in the middle, I guess)
  • Replies to people the server follows are received via a forward

So if I am a@s1, and I follow b@s2, b@s2 posts something, and c@s3 replies to b@s2, I will see c@s3's response. In many cases that's enough, especially on larger servers because more people are followed. In large conversations and small servers, some chains of the conversation may be missing. b@s2's page will always have the fullest conversation.

Thank you for the details, @Gargron! My suggestion was to add a note explaining (or hinting at) exactly this to toot detail view. Reason:

In large conversations and small servers, some chains of the conversation may be missing.

On my small server (single-user), most replies to most toots that are boosted onto my timeline are missing, since I usually don't follow any of the people involved. On an instance of about 300 accounts that I also use, there is still enough missing to make it very likely that I miss important replies if I read only what the instance knows about. In both those situations, a note telling me that this might be the case would have prevented some confusion, and would have helped me to do the extra click, get the context, and not annoy people with redundant replies to their questions.

When I asked about these "missing" toots, the only people who replied to explain that it was supposed to be like this were people who are actively involved in the development of fediverse software, so I assume that the workings of thread fetching simply aren't common knowledge among other folks. It's just not an intuitive thing for someone who doesn't know the details of how Mastodon works, so being told about it explicitly is necessary :)

Expectation management is one thing, whether it should try get all the relevant comments another?

Still kindah think it should, to be honest. People can always go to the parent comment instance, and maybe clients do it automatically.. That would a rpc call for every user, instead of for every instance, and there are fewer for the latter.

Of course the toots only need requesting when someone views it. I am not sure how to best try avoid sending toots multiply, could list off the users the instance follows in the request, and upto-which-time this thread was already requested, that is basically everything the instance will already know, the rest can be sent? (Note: still not informed myself on how it works)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sorin-davidoi picture sorin-davidoi  Â·  3Comments

ghost picture ghost  Â·  3Comments

hidrarga picture hidrarga  Â·  3Comments

thomaskuntzz picture thomaskuntzz  Â·  3Comments

almafeta picture almafeta  Â·  3Comments