@TodePond
hello I have a patch that fixes this
#FetchAllReplies
https://github.com/NeuromatchAcademy/mastodon/pull/8

ok we've had a pull request hanging out re: #FetchAllReplies for like 2 months and I think I'm gonna merge it under the as yet undecided discretion of @techwg given the constantly recurring nature of the problem. most recently
https://mastodon.social/@waldoj/109965267135535869

my question is basically should that just happen automatically when you expand a post, because I want to say yes but I am always wrong about whether stuff is bad in a way I don't anticipate

@loke
@acdha @nelson @waldoj
totally right. I made a quick patch to #FetchAllReplies because it's imo extremely important to the dang thing actually working
https://github.com/NeuromatchAcademy/mastodon/pull/8

@waldoj
Yeah, it's SUPER annoying. Some clients, like #fedilab have built in functions to fix it. They all should.
#FetchAllReplies

@anderspuck
@n3xdp
Glemte at nævne den for mig vigtigste fordel:

I Fediverset ser man IKKE alle svar i diskussionerne. Kun svar fra dem, der har følgere på ens egen instans. Faktisk en ting, der modvirker små instanser. Ved ikke hvordan med relays, som vi bruger her i Danmark.

Fedilab har en knap, der henter alle svarene. Har hjulpet mig *meget*. Burde være standard på alle klienter...

#FetchAllReplies

@gpshead
And a button to #FetchAllReplies
@kissane

@r343l
If you're on Android, try #fedilab @apps
It has a button to #FetchAllReplies from originating instance (crosshairs top right)

@kissane

@Ciantic
@matt
#FetchAllReplies

@apps
#fetchallreplies

that feeling when an interesting thread is in your instance so you can see the whole thing ... that the fedi is vibrant and fascinating in its multitude ... we should make that always be the way it is. #FetchAllReplies .

Hooray, it works! Thank you @apps
#fetchallreplies
@jonny

@jonny

I love your work, it sometimes looks like you're the only person taking ux seriously here. Between this, #FetchAllReplies and all the other things I'm surely missing, these are all REALLY common sense improvements that would go a long way in making life more pleasant and for some ((strange)) reason seem to go completely off the radar in mainline mastodon.

@LeonDLotter @ryneches @x1l3f @MattHodges @icymi_law @Colarusso @Sho_Ishiguro

@elduvelle @maegul @Homebrewandhacking I think it would be really nice to do the same thing as I'm thinking with replies: when you search for a hashtag, go out and find more posts from other servers using that hashtag. the problem is "which servers" because even our instance knows about thousands.

Masto stores some notion of trending tags for both accounts and instances, which could be one way of doing it: go and grab posts from the top-n instances using the tag. or maybe even give a box to someone like "here are the servers you interact with the most and how many uses of this tag they have, select which we should go fetch"

it seems fine to me from a privacy POV because the act of using a hashtag is to make a post be discoverable, and followers only posts wouldn't show up in the search.

#FetchAllReplies #FetchAllTags

@jdp23 @liamsora @kichae @futurebird @stopthatgirl7
it certainly doesn't address the problem fully, but I'll be merging this into neuromatch.social to test soon enough: https://github.com/NeuromatchAcademy/mastodon/pull/8

It's relatively simple patch that's entirely frontend so hopefully easy to deploy on smaller instances.

Makes a button that lets you request the replies to a given post so you can see them even if no one on your instance follows the poster (ie. your instance wouldn't know about the post because of the pub/sub issues described above).

It works by using the search feature to fetch posts (as @liamsora also discovered):

• Ask OP server for the context that it knows about, replies and ancestors
• Submits the URLs for each of the replies to the search endpoint
• Inserts posts as they are received into the redux store -> into the React component displaying the thread

It currently inserts them in a disordered way because the React component holding a thread is a single-layer component that holds expanded post & ancestors & replies. that's also related to why a thread is completely unreadable (imo) because it's rendered as a flat list rather than as a tree - which is what a thread is. Will be working on making a properly recursive component next.

Once that's done, then it should be possible to iteratively request replies in a smarter way, but that will also require another change in the way the /context endpoint works, which currently takes no arguments for subsetting and has no pagination - so therefore has relatively low hardcoded limits on the amount of replies you can request without being logged in. That will need to change to be able to request a certain depth (currently it gets the entire reply tree and then flattens it into an array) and paginate through results so that eg. you can get all the top-level replies to the request you have open, and then as you open deeper replies you get the replies to that reply, and so on....

(sorry for wall of text sort of got away from me.)

#FetchAllReplies #NestedThreads #ContextAPI #MastoDev

btw i freaking made an implementation of this already and i am gonna try and pull it to glitch!!!!!

https://neuromatch.social/@jonny/109582537808504261

#FetchAllReplies

Seriously i am full tilt #FetchAllReplies evangelist at this point - the fact that everyone replying to a post can't see everyone else often turns into a series of people talking to the poster but not each other unless they already know each other, so instead of a fun spontaneous meeting ground we all look like assholes making the same joke

@futurebird
#fetchallreplies
@fraying

The more i think about the need for #FetchAllReplies the more i am like it is currently sort of impossible to start a new instance without already having connections with a larger instance right? if the only way ppl from your new instance get in other ppls feeds is to get boosted or followed by other large accounts, and that usually happens from the local timeline, then what happens if no one in the new instance has any followers? and then that still depends on accounts with more follows in a new instance actually doing the boosting, which is not great for autonomy.

the current system of nobody being able to see newbies replies, esp if we really want to move away from large instances, makes them borderline impossible to discover. So they feel like they're talking to no one and then probably just leave.

It seems totally critical to be able to be seen replying in threads to meet people on here, esp if you're on a less established instance, and esp before anyone from a handful of active servers follows you.

really huge huge huge missing functionality - that and you miss most of the actual conversation and get a bunch of unintentional reply guys as ppl were describing in the several threads on this in the past few days.

one of the major reasons I'm seeing masto be very difficult to scale functionality because basic things would be expensive is that it seems to do a bad job with knowing how eagerly to rehydrate a data model- like most API endpoints should have the option of just returning an ID or be able to subselect fields - it would probably be way more lightweight to #FetchAllReplies if you could subscribe to a stream of just post urls to expand later, rather than full on `Status` objects with no pagination

@anton_hilado see this is why we need the ability to #FetchAllReplies because when I go to the original post on mathstodon there are a ton of interesting replies but I only see four atm