Mastodon: Add an indicator when a non-viewable toot is part of a thread

[joyeusenoelle]

Currently, if a user views a thread in which there are posts which the user doesn't have permission to view, those posts simply disappear from the thread.

This issue proposes adding an indication that the post exists, but none of the other information about the post.

For example, the current behavior looks like this:

noelle: I like pie
noelle: @/gargron I guess cake is good too
noelle: @/gargron I mean, carrot cake is great
noelle @/gargron No, I don't like coconut

The proposed behavior looks like this:

noelle: I like pie
--- You do not have permission to view this post. ---
noelle: @/gargron I guess cake is good too
noelle: @/gargron I mean, carrot cake is great
--- You do not have permission to view this post. ---
noelle @/gargron No, I don't like coconut

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[minego]

I have often wished for this. This would be a very welcome change in my opinion.

Are there other reasons some of the toots may be missing that this should cover but with a different message?

[joyeusenoelle]

The other situation that comes to mind is a toot that's been deleted, but I'm not sure if it's worth the effort to do the software interpolation there (since a. the toot is gone from the database, so the software has to figure out that it exists from references in the remaining thread, and b. I think when a toot is deleted it breaks whatever threads it's in anyway).

[trwnh]

Perhaps an alternative take:

The situation described in the OP is what results when you follow one person but not another, correct? In that example, the user is following @noelle but but @gargron. Thus, when the privacy is set to followers-only by @gargron, and by default all of @noelle's posts are also set to the same privacy level (followers-only), only half the conversation is visible.

One potential solution is to insert stubs into the conversation chain, saying something to the effect of "toot not available" or "toot hidden due to privacy settings". This would at least preserve the structure of the conversation and disambiguate it, so that the user doesn't think @noelle is replying to theirself multiple times. This is as the OP describes:

noelle: I like pie
--- You do not have permission to view this post. ---
noelle: @/gargron I guess cake is good too
noelle: @/gargron I mean, carrot cake is great
--- You do not have permission to view this post. ---
noelle @/gargron No, I don't like coconut

Another solution is to hide the entire conversation based on the privacy settings of the parent toot. It's also possible to only show a child toot if it's explicitly marked as public or unlisted, but in short, the proposal would be to make followers-only privacy settings cascade for the entire conversation as long as followers-only is set on all toots in the chain -- in other words, if the initial toot is invisible because the user doesn't follow @gargron, then @noelle's reply shouldn't be visible as long as it is set to followers-only. A user must follow every author of all parent toots marked followers-only in order to see a given child toot. Example where a user follows @noelle and @trwnh but not @gargron, with all toots marked followers-only and --- meaning the toot is not shown:

noelle: I like pie
--- >gargron: @noelle what about cake? ---
--- >noelle: @gargron I guess cake is good too ---
--- >noelle: @gargron I mean, carrot cake is great ---
--- >gargron: @noelle i like coconut cake, myself ---
--- >noelle: @gargron No, I don't like coconut ---
--- >> trwnh: @noelle @gargron i'll take the coconut cake if you don't want it ---
> trwnh: @noelle who doesn't like pie?

As can be seen: the user can only see two toots because the followers-only permission would cascade instead of only being applied for the individual toot's author. The entire block encased within --- could be collapsed into a single statement saying "replies hidden" or something similar.

[nightpool]

twitter had a very small "..." that shows up in situations like these…
maybe that's better then a heavyweight whole status thing?

On Thu, Apr 26, 2018, 10:30 PM trwnh [e-mail] wrote:

Perhaps an alternative take:

The situation described in the OP is what results when you follow one
person but not another, correct? In that example, the user is following
@noelle but but @gargron. Thus, when the privacy is set to followers-only
by @gargron, and by default all of @noelle's posts are also set to the
same privacy level (followers-only), only half the conversation is visible.

One potential solution is to insert stubs into the conversation chain,
saying something to the effect of "toot not available" or "toot hidden due
to privacy settings". This would at least preserve the structure of the
conversation and disambiguate it, so that the user doesn't think @noelle
is replying to theirself multiple times. This is as the OP describes:

noelle: I like pie
--- You do not have permission to view this post. ---
noelle: @/gargron I guess cake is good too
noelle: @/gargron I mean, carrot cake is great
--- You do not have permission to view this post. ---
noelle @/gargron No, I don't like coconut

Another solution is to hide the entire conversation based on the privacy
settings of the parent toot. It's also possible to only show a child toot
if it's explicitly marked as public or unlisted, but in short, the proposal
would be to make "followers-only" privacy settings cascade for the entire
conversation as long as "followers-only" is set on all toots in the chain
-- in other words, if the initial toot is invisible because the user
doesn't follow @gargron, then @noelle's reply shouldn't be visible as
long as it is set to "followers-only". A user must follow every author of
all parent toots marked "followers-only" in order to see a given child toot.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/7274#issuecomment-384845342,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV8GbtQPPZuJ9nfesrf0bEH_WFjGaks5tsoKsgaJpZM4TnqcM
.

[trwnh]

Twitter's "tweet not available" actually looks something like this, iirc? Context: one of my old twitter accounts stopped showing up in replies back in early 2017 or possibly late 2016. That wasn't a matter of privacy or locked account, though -- possibly a shadowban. It looked like this when logged in from a different account

[nightpool]

yeah that's the thing I mean (the ... is along the side and the text is
very short and minimal)

On Thu, Apr 26, 2018, 10:43 PM trwnh [e-mail] wrote:

Twitter's "tweet not available" actually looks something like this, iirc?
Context: one of my old twitter accounts stopped showing up in replies back
in early 2017 or possibly late 2016. That wasn't a matter of privacy or
locked account, though -- possibly a shadowban.
[image: chrome_2017-03-19_23-37-56]
https://user-images.githubusercontent.com/10606431/39341854-affedfd0-499a-11e8-9501-eceadae2289d.png

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/7274#issuecomment-384847216,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV48HmHG2NzXvXvsy0xir35wyd4h_ks5tsoXLgaJpZM4TnqcM
.

[joyeusenoelle]

Twitter's version is actually what I was envisioning, not a full status block.

[minego]

I would personally prefer a bit more information about why. Twitter doesn't
want to say why because "Tweet not available because the user was
shadowbanned" doesn't look good. I think more detail is useful.

On Thu, Apr 26, 2018, 8:44 PM nightpool [e-mail] wrote:

yeah that's the thing I mean (the ... is along the side and the text is
very short and minimal)

On Thu, Apr 26, 2018, 10:43 PM trwnh [e-mail] wrote:

Twitter's "tweet not available" actually looks something like this, iirc?
Context: one of my old twitter accounts stopped showing up in replies
back
in early 2017 or possibly late 2016. That wasn't a matter of privacy or
locked account, though -- possibly a shadowban.
[image: chrome_2017-03-19_23-37-56]
<
https://user-images.githubusercontent.com/10606431/39341854-affedfd0-499a-11e8-9501-eceadae2289d.png

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
<
https://github.com/tootsuite/mastodon/issues/7274#issuecomment-384847216>,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAORV48HmHG2NzXvXvsy0xir35wyd4h_ks5tsoXLgaJpZM4TnqcM

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/7274#issuecomment-384847394,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcoiBwkMMelsDur9NyKr5UYxSDDiWzTks5tsoYkgaJpZM4TnqcM
.

[trwnh]

Agreed. The thing with Twitter's implementation is that it's technically incorrect and lying to the user -- instead of saying "tweet unavailable", it should really say "tweet hidden". A proper and forward-facing implementation in Mastodon should clarify along the lines of "replies hidden due to privacy settings", and if deleted statuses were to somehow be preserved in the chain, then "toot no longer available". It doesn't have to be a full status with an avatar / name / etc -- it can just be a tiny blurb 8px or 12px high.

[ThibG]

One issue is that the instance potentially doesn't have the toot at all. In this case, the instance can know that some toot was in reply to an unavailable one, but not that the unavailable one itself was a a reply to another one (since that's a property of the unavailable toot).

[mal0ki]

This is a good enhancement, I think it goes well with the overall idea of making the UX more intuitive.

[trwnh]

ThibG, I think that it wouldn't really make much of a difference if it's just one "..." parent? As in, if the toot on the instance is aware of its direct parent, and that's it, then the instance can show a blurb for any number of toots ("one or more toots are not visible") and then link to the toot URL on the originating server? That should make the problem less bad.

Alternatively, the server can try to fetch the entire conversation but still only display the visible toots. This would probably require some new API logic to authorize the transfer of certain toots, though.

[ThibG]

@trwnh having a link to a followers-only toot isn't of much use (but yeah, showing that it is a reply to something you can't see still has some value)

The issue I was thinking about is the following: imagine you are alone on your instance, following A and B, but not C. A, B and C talk in a long followers-only thread, so you can see toots from A and B (and they would should up in your TL if they are replies to one another), but not messages from C. For instance, let's say you have the following exchange (linear):

A: hello!
C: @A hello, how are you? Yesterday was so fun!
B: @C @A Yeah, right?!
A: @B @C Sure!

In this example, the instance would only get the messages from A and B, so it is missing the second message and thus cannot know that the third one is a descendant of the first one (it knows that it is a descendant of the second one, but doesn't know what the second one is). The instance cannot fetch it as those toots are followers-only and no followers are on the instance.

[SoniEx2]

would rather have "inherit"/"thread" option that makes reply visible whenever parent is also visible.

see also https://git.pleroma.social/pleroma/pleroma/issues/136

[Zatnosk]

Showing a placeholder as also relevant in cases where someone you've muted or blocked take part in a conversation.

Example:
A: hello!
C: @A hello, how are you? Yesterday was so fun!
B: @C @A Yeah, right?!
A: @B @C Sure!

If I have muted C, this would look like this, even when all posts are public:
A: hello!
B: @C @A Yeah, right?!
A: @B @C Sure!

[mal0ki]

I feel like this post is slightly relevant to this:

hey when the root of a thread is a follower only post from an account that I don't follow, can we just
not show me the rest of the thread in my feed?
like the buts from people I follow being visible in their profiles is fine. but i don't need out of co text replies to someone I don't know or follow in my timeline. it just confuses and worries me sometimes.
https://glitch.social/@Vann/99977469255590740

[bhtooefr]

Another thing, speaking of muting, is when your instance has a user or instance silenced.

I'd say in the muted/silenced case (especially the silenced case), allowing the user to display the hidden toots would be quite useful.

[BenLubar]

current behavior:

1. user A posts something
2. I start reading their message on my home timeline
3. they redraft the toot
4. the toot suddenly disappears from my timeline, leaving me very confused

proposed behavior:

1. user A posts something
2. I start reading their message on my home timeline
3. they redraft the toot
4. the toot I was reading is replaced with "this toot is unavailable" and animates to the correct size for just that message

---

current behavior:

1. user A replies to user B
2. I open the thread and begin reading from the start
3. user A redrafts their reply
4. the entire thread vanishes from my view

proposed behavior:

1. user A replies to user B
2. I open the thread and begin reading from the start
3. user A redrafts their reply
4. the reply is replaced with a "this toot is unavailable" placeholder and animates down to a smaller height. the remainder of the thread remains visible to me.

---

current behavior:

1. user A replies to user B
2. user B's post has not been picked up by my instance
3. my instance cannot show me user B's post, so user A's post is displayed as if it were not a reply

proposed behavior:

1. user A replies to user B
2. user B's post has not been picked up by my instance
3. my instance shows user A replying to a placeholder reading "this toot is unavailable"
4. my instance silently attempts to retrieve the post from user B in the background, and if successful, changes the "this toot is unavailable" message to something representing the toot now being available
5. clicking the message about the toot now being available loads the thread from that toot, exactly as if I had clicked on the background of the toot after it loaded normally

[Gargron]

For cases where statuses are filtered for a specific user, the solution is comparatively simple. But perhaps even more important is the case when statuses are removed in the middle of threads.

The question is how do we represent this in the database? We have a few options...

1. Fetch all posts in a thread using the conversation model (requires a new index on statuses table), then on the client side, add gaps when in_reply_to_id is null
2. Use soft-delete functionality more extensively: Remove post content and associations as much as possible, but leave the status record itself, and include those in the query

Any other approaches?

[trwnh]

AFAIK pleroma uses the conversation model to return all posts with the same context as a thread, regardless of which posts are in reply to which. the client is expected to do its own threading using in_reply_to_id, instead of based on ancestors and descendants. having clients handle gaps would therefore have some precedent, at least, if mastodon went with option 1.

on the other hand, misskey returns tombstone objects and keeps inReplyTo -- this keeps the thread constructed, but can leak information about the old status as you can likely assume who authored it based on embedded mentions of any replies. mastodon going with option 2 would have the same pitfalls most likely. it's also worth mentioning that the status in question doesn't have to be deleted -- it can simply be a status that you are not authorized to view. in some sense, mastodon already leaks the existence of private statuses given that you follow someone who has replied to one. (#3964)