Email or username:

Password:

Forgot your password?
Evan Prodromou

Are there any Mastodon clients that use the `replies` collection to get the full list of replies from a remote server?

29 comments
DELETED

@oblomov @Uilebheist
please @evan, make peace with oblomov, i can't believe he did something so wrong with you that was enough to block him 🙂

DELETED

@Uilebheist @oblomov
Because we wrote about the problem of mastodon threads often not showing all the posts a user would have the right to see, when looked at from a different instance than the one their first post was posted through :)

Stu

@evan I *want* to say @trunksapp does this, but I can't find it in the app description. I may have been thinking of the reply threading and built-in OP unroll functionality. Perhaps they can comment!

In truth, I'm never quite sure if I'm seeing all of the replies, irrespective of client, and so tend to check the original profile for context.

trunks (Android, iOS & Web)

@tehstu @evan I'm assuming you mean retrieving both your local server and the remote server context about replies to a thread?

If so, not yet, it's something I want to support. It's just cumbersome and adds latency since there's no singular, simple API to do that with.

Tony Hoyle

@evan
Fedilab will do it. I just have a fedifetcher instance running though.

Aljoscha Rittner (beandev)

@evan
Fedilab supports a public API call to get a complete conversation (this is the small Target Icon on top of a conversation in the android client app). Fedilab then switches from the local server to the remote server, to see more responses. But I'm not sure if it similar to your question. I tried to find the API endpoint in the documentation. But I found only the `context` endpoint to get ancestors and descendants. 🤔

infinite love ⴳ

@evan this wouldn’t be the job of the mastodon client, no? it’s the job of the activitypub client / mastodon server. a mastodon client would use the mastodon api for fetching conversations, and may choose to fetch from the root’s origin instead of your local server (although this bypasses your local blocks and mutes)

Evan Prodromou

@trwnh yes, that's correct. But if you use the Mastodon API, it searches the local server for posts in the same conversation, so you get conversation fragmentation. Using AP to get the `replies` collection will get all direct replies (and you can get the full tree by getting the replies of each of those, and so on). It's a way to hack around fragmentation.

infinite love ⴳ

@evan i think most mastodon clients don’t want to parse “raw” activitystreams in addition to parsing mastodon api responses. the closest they’ll come to that is requesting the public mastodon api endpoint for the root statuses/:id/context (which is maybe “more complete” but not guaranteed to be “fully complete” either — if some downstream replies drop the root server, then they wont be included) (also the mastodon api limits context to 4096 total entries and gets inefficient long before then)

infinite love ⴳ

@evan i think anyone who wants a “complete” view ought to stop expecting that for replies (short of recursively crawling the whole web) and instead work toward a distribution model where conversations exist in some context and are managed by the server responsible for that context. (see fep-7888 for a description of how context could work normatively, but tldr: send your Create to the context.attributedTo and they’ll distribute an Add which you can forward to your followers)

Evan Prodromou

@trwnh I don't know what you're talking about. Every reply should include the original poster in their addressing, and the original poster's server should maintain the `replies` collection. Mastodon does this already. The `replies` collection should be an accurate record of the direct replies to a post.

infinite love ⴳ

@evan it's possible to drop someone from addressing when you reply to them. see the next reply.

infinite love ⴳ

this is a reply that drops evan from the addressing

Evan Prodromou

@trwnh Sorry, I meant the `to` property, not the `Mention` property. I'll check to see if that drops me from `to` also.

Evan Prodromou

@trwnh it does! Not a fan of that feature, but OK. So that wouldn't show up in `replies`.

Evan Prodromou

@trwnh `replies` is still the right place to look for direct replies to a content object or activity. If someone goes out of their way not to allow their reply to go there, that's fine.

Evan Prodromou

@trwnh I definitely like your suggestion that `Add` or maybe `Approve` would make sense for notifications to other addressees. Way better than just injecting the `Create` into the OP's outbox.

Григорий Клюшников

While not a "Mastodon client", Smithereen does use it to recursively load complete reply threads when you open a post using the search or when someone boosts a remote post at you.

There's also a problem: if there's a deleted reply somewhere in the thread, it will make the other part of the thread unreachable (up or down, depending on where you started traversing from). Smithereen solves this by not deleting such replies completely, but instead serving a Tombstone object that still has `id`, `replies` and `inReplyTo` fields.

While not a "Mastodon client", Smithereen does use it to recursively load complete reply threads when you open a post using the search or when someone boosts a remote post at you.

There's also a problem: if there's a deleted reply somewhere in the thread, it will make the other part of the thread unreachable (up or down, depending on where you started traversing from). Smithereen solves this by not deleting such replies completely, but instead serving a Tombstone object that still has `id`, `replies`...

Go Up