My least favourite sharp edge of Mastodon is the fact that when you view someone else's post you only see replies to it that are known to your server - so there's actually a good chance there will be replies that are completely invisible to you, especially if you run your own instance

I'd love it if tapping a post kicked off a request back to the original server that fetched the current reply count and provided a "view all replies" button if there were replies not yet visible to me

My hunch here is that very few people see even aware of this Mastodon feature

So, a poll: prior to reading this thread, did you know that Mastodon by default will only show you public replies to a post if those replies have already been fetched into your server somehow?

(This only affects you when you view a post that originated on a server other than your home server - if the original post author is on the same server as you then you'll see all of the replies)

Yes I knew about that
24%
No, I didn't know about that
70%
I don't understand the question
6%
Poll ended at .

@simon I had assumed that replies would inherit the "reach" of the original post by default... Hmm...

*edit: typo

@AriaGrace yes! I think this is the normal intuition, where many have the intuition of a forum or threaded structure. But it seems the core idea here is it’s all about who you follow.
@maegul @AriaGrace Here's a great flow chart that shows the visibility of a toot on which timeline it will appear dependent on if it's on a local and federated instance & if you follow someone who interacted with it.

@chriszanf Yes, thank you! IMO, the main utility of the chart is in explaining what the "Local" and "Federated" timelines are. The complexity we're all talking about lies in the last node of the decision tree, which is not coincidentally also the most complex.

The simple intuition that started this thread could easily be added to this chart as "is a reply to a toot that someone you're following has also replied to". IE, a "reply cousin". OR, "part of a reply chain you follow".

@maegul Exactly. Post visibility in Local and Federated TLs is a no-brainer in comparison. Decentralization gets tricky looking at replies from other instances or even other apps/services (e.g. Friendica, PixelFed) with differing levels of interoperability. @chriszanf
@chriszanf @maegul @AriaGrace
Thank you for sharing this.
The diagram is enlightening and makes logical sense.
It also has kind of depressing implications for people following hashtags. Got to hope the people on your server share all your niche interests.

@xurble
Agree about hashtags. Inline with the comments around 21/22 Dec in this GitHub issue, I suspect there's some real room to grow for #Mastodon in providing a clean and powerful filtering and viewing system to users.
https://github.com/mastodon/mastodon/issues/20715

Like with this conversation about replies, I think there's some hunger to turn Mastodon into a wonderful content feed manager that will require connections or aggregating concepts beyond the social "x follows y" graph.

Add hashtag to list · Issue #20715 · mastodon/mastodon

Pitch As of 4.0 one can follow a hashtag so that it appears in one's home timeline. I suggest that one also be able to add a hashtag to a list, which would allow people to curate list composed of d...

GitHub
@xurble Inline with this, a vague idea sticking around in my head is whether #Mastodon (however viable) could benefit from the idea of a "board", which would essentially be a thread or chat room like a #reddit post. But it would be owned, moderated and controlled by the creator, like a mini instance within an instance, and could have a fixed duration of write openness and even read openness and of course configurable accessibility by user/instance etc, with instance based rules too

@xurble @chriszanf @maegul @AriaGrace They don't have to share your interests. They just have to reply/search/favorite/boost/follow etc. someone that happens to share your interest so that someone's toot will show in your Federated.

It's like a mutual connection that's not shared by the intermediate account between the 2 of you. So long as these other 2 accounts aren't blocked by your instance, it doesn't matter what others on your instance have.

@zecuse @xurble @chriszanf how much are people using their federated timeline? I find it overwhelming a lot of the time. Plus, speaking of the hashtags, is it not reasonable to want tagged posts to appear in one’s feed? Also, I’m not clear on how hashtags would work for some one on their own private instance … would you need to follow the poster to see the post?

@maegul @zecuse @xurble There's a seeing on the web interface to enable "slow mode" so all the feeds do not auto scroll. Makes the federated timeline readable.

Not sure about the hashtags / own instance but I follow one related to modular synths and I see posts by people from other instances.

Good questions though!

@maegul @zecuse @xurble @chriszanf (In an established instance) I last used it some in early November. I was more actively looking for accounts to follow.
@thematic that makes sense. Also, to go through it every so often just to allow for new things, people etc.
@chriszanf @maegul @AriaGrace any idea what would cause the scenario where I see the toots of someone on another instance whom I follow, but not the image(s) attached to their toots?
@chriszanf @maegul @AriaGrace I once ran a fido mailbox. This has commemoration potential
@chriszanf @maegul @AriaGrace how does this work with forwarded users? I've set up several accounts on other servers and redirected them to this one.
@Arrakis_Surfer No idea about forwarding!
@simon i know about that b/c of not seeing regular posts if my server is behind on federation :)
@simon
Fedilab app does a pretty good job fetching them for you
@kimschulz
Are you suggesting that this characteristic is app based and not protocol based?
@simon
@jrredho
More that fedilab has implemented functionality to fetch the remote messages in threads started locally (or something like that)
@simon
@jrredho @kimschulz @simon It definitely is app based, the ActivityPub 2.0 spec specifies pubs should retransmit any public replies they receive to all followers who could have seen what is being replied to, specifically to avoid this issue. It's not mandatory, but pretty much nothing is in the AP spec. Mastodon isn't following the spec, that's why you're seeing brokenness.

@phx @jrredho @kimschulz I don't think that's the case here - Mastodon does implement the thing where everyone who follows me gets sent any replies to my posts

The problem I'm describing occurs when I browse to a post by someone who I don't follow (eg because it was boosted into my timeline) and then can't see all of the replies to that post

I don't think the ActivityPub spec covers that particular case

@simon @jrredho @kimschulz Ooh right. There is a loosely specced functionality for activities to include a replies collection, so it is possible for AP servers to expose replies in this way and consume them from each other, and I think Mastodon usually does? from my own poking at server endpoints. But like mastodon not normally iterating and loading posts from remote user's profiles when you view them, it seems like it doesn't usually load the replies collection either. https://ryanatkn.github.io/corpus-activity-streams/#replies
corpus-activity-streams

@simon @kimschulz I don't think that's actually true, I'm on a single user instance and with fedilab I don't see any replies to this thread
@edzilla @simon @kimschulz I don't think they've actually implemented it yet. They just did the poll for the feature a couple of weeks ago.
@djohngo
@edzilla @simon @kimschulz
It's implemented, but not automatic : you have to tap the icon (circled in yellow in my screenshot) to switch to remote view. As I understand it, it uses the public (non authenticated) API to fetch the thread directly from the server on which it originated. @apps
@simon is this true? i saw this reply and we’re on different servers. it’s possible that someone else on my server fetched it in the 3 minutes between when you posted it and when i saw it but that seems tight
@sean @simon do you follow Simon? I think that might mean that his posts are pushed to your server.
@sminnee @simon oh, yes i do! that explains it, then.
@sean @simon at core it means that discussion participants are okay and drive-by drop-ins (like me, now 😆) are more at risk of not being seen. But is a social network that makes life harder for reply-guys all that bad? 😉

@sminnee @sean my problem with it is that I frequently reply to someone... and then find out that what I've said has already been said several times before by multiple other people in replies that weren't visible to me

Which makes me look rude, like I'm spraying replies around without even bothering to read the conversation first!

@simon @sminnee @sean

I think it's a feature that there's some value in 'aggregating' into instances (ideally organized by a community that is most likely to converse with each other) and not everyone having their own instance.

It's great that the fediverse can somewhat scale in reach for truly viral messages (incl. viral replies) -- but there are speed bumps for loners that might hack cross-instance moderation/blocking algorithms

@simon @sminnee @sean Oh goodness, I hadn’t thought about accidentally dogpiling because you can’t necessarily see if there are other replies or what they say. I did technically know about this issue, but I completely didn’t think about any of the implications other than the vague annoyance of not seeing all the cool things.

@simon @sminnee @sean that happened to me this morning. I replied to a post that had no replies. By the time I finished the reply, about a minute later there were others saying the same thing 5 minutes before!

Not an easy problem to solve. Not a huge problem though. I imagine most people don't get very many replies. It's mostly boosts and favourites, if that.

@simon @sminnee @sean this is a huge design failure

(Someone’s probably already said this to you, but as the first replier, I said it first)

@simon @sminnee @sean oh wait, yours was itself a reply?

I didn’t see that – it wasn’t apparent

@sminnee @sean @simon I don't follow any of you and are on a different server so I don't know what the rules are here.
@KorimakoEcology @sminnee @sean that could mean someone else on your server follows me - which would cause all replies to my posts to eventually make its way into your server's local cache of the fediverse

@sean @simon

sometimes when i view a post, no replies at all show up for a few seconds and there's a progress bar at the top of the page

i thought the replies were getting fetched from the server of author of the top post

then it seems like all those replies are cached on my server, because if i return to that post later, replies show up instantly

but those replies seem static, they don't update dynamically, and if i return to the post a minute later, the replies haven't changed

sometimes it takes a browser refresh, or even a shift-refresh to get new comments

exactly how and when does my server get updated with new replies?

@ares @sean my current understanding is that your server gets updated with replies:
1. Any time someone replies to a post when the author of that post lives in your server
2. Any time the reply is from someone followed by at least one user who lives on your server
3. Any time someone else on your server favorites or boosts or replies to that reply

@simon @sean

seems like 3 would never happen because someone else on my server can't favorite or boost or reply to a reply that doesn't exist on our server??

@ares @sean it's rare, but they can do it by pasting the URL to a post into the search box on their server (or search in one of the Mastodon mobile apps)

@simon A big part of the problem is that at scale, that would probably make existing performance issues even worse.

"George Takei posts, and the fediverse shuts down".

@ocdtrekkie yeah I guess that's always the catch with this - the home instances of high-follower accounts would have to be able to serve a HUGE spike of GET requests (which could be cached, but still a lot of incoming traffic)

I really, really want a fix for this though! It's a very real problem for me - I've found myself replying to someone with material that's already been covered in other invisible-to-me replies quite a few times at this point, which makes me look rude

@simon @ocdtrekkie (With the risk of repeating someone else's reply!) Isn't it like this though. There is a toot on instance 1, users on instances 2 to 50 are subscribers so they get the toot. User on instance 32 replies. How would instance 45 know about that reply to show its user. The app of user 45 can't ask every instance. Instance 32 would have to tell instance 1, and instance 1 keep track of all replies to tell other instances when they get the original toot.
@simon @ocdtrekkie So compared to how you described it works now, instance 1 now only knows about replies if there are users on instance 1 following those users. With your solution, instance 1 would have to be notified and keep track of every reply on any server and forward that information as needed. And instance 32 would do the same for the reply. Etc. Should work, but is probably quite a performance difference for servers with a lot of off instance replies.
@simon @ocdtrekkie And will you see this reply? Probably, because I'm on a big server?
@CubeThoughts @simon @ocdtrekkie ok, this is even more unexpected than I thought. Instance 32 doesn’t tell instance 1 about the reply?
Does that mean that UserA on instance 1 (who posts) might never see a reply from UserB on instance 32 (to their original post) UNLESS instance 1 happens to fetch that post for a different reason (e.g. UserC on instance 1 follows UserB)?
@yoz @CubeThoughts @ocdtrekkie you will always see all replies to something you yourself posted - where you might miss replies is if they are:
- from people you don't follow
- to people you don't follow
- where neither of those people are on the same server as you (or are followed by someone on your server)

@CubeThoughts @ocdtrekkie that hypothetical situation actually works OK

When the user on instance 32 replies, instance 1 will then re-broadcast that reply to instances 2-50 since those instances all host users who are following the author on instance 1

@CubeThoughts @simon @ocdtrekkie
If the thread-creating-instance could keep an index of replies (not the texts, just the links) then it could supply those on request. It should already have the data.
Issue then becomes who tracks the spin-off threads.