I have a #Fediverse #ActivityPub question:

treefit

I have a #Fediverse #ActivityPub question:
Why doesn't my client ( #mastodon or #pixelfed ) automatically load the comments from the original page so that all comments are visible?
Is there a technical reason?

BeAware :fediverse:

@treefit that would overload the server with too much information, unfortunately.

julian

@[email protected] @[email protected] yes and no. I'm working on a solution for this.

NodeBB for example will automatically do this (providing the other end supports it). When posts are retrieved from NodeBB to NodeBB the entire topic is visible.

BeAware :fediverse:

@julian @treefit well that's neat! but could you specifically address my comment? Wouldn't that cause DDOS type issues on servers with lots of posts/users?

eigenstil

@BeAware @treefit so this means, I only see "some" of the answers (unless I click on "view original in browser")?

If yes, how does my instance decide which answers in a thread to load, and which not to load?

BeAware :fediverse:

@eigenstil @treefit correct.

Fediverse works by follow relationships on an instance basis, meaning if a user on another server isn't followed by anyone on your server, none of their posts will show up. So it requires someone on your server to follow the "replier" on the other.

Hope that makes sense.

julian

@[email protected] no, I don't believe so. I agree that replicating replies and likes in their entirety to every server ever is an unscalable task, doing so on a conversation by conversation basis is perfectly fine and should be handled without issue by fediverse software.

freamon

@[email protected] @[email protected]

The individual replies would be fetched from their original server. I just tested a random Mastodon post with 12 replies, and it was split 3 on mstdn.social, 3 on mastodon.world, 2 on mastodon.social, and 1 each on mstdn.ca, social.esmarconf.org, infosec.exchange and todon.nl - so no one server should get too many requests (and the more replies from one server a post has, the more likely that server can cope with the traffic.

eigenstil

@BeAware @treefit Yes, that's easy to understand, thanks for the explanation.

Basically this means, I/my instance only sees comments in a thread, from people that are "known" to my instance (because someone on my instance is following them) or they have an account on my instance. Otherwise I have to take a look at the original post on the original instance.

Right?

PS: I suppose some apps (maybe #Fedilab) initially pull all comments together from all instances. But I'm not 100% sure.

BeAware :fediverse:

@eigenstil @treefit yep, that's 100% correct.

Some apps are able to see comments from original post, but that's because it's the client reaching out to the other server, not your server reaching out, if that makes sense.

BeAware :fediverse:

@freamon @treefit you're on nodebb, which supports this, mastodon doesn't support this yet as far as i can tell.

🍉 دانیال بهزادی

@treefit
AP works in a push nature, not pull. It may be related to overload on servers.

treefit

@danialbehzadi I'm just wondering why clients don't pull on demand to provide a complete view on the comments

wakest ⁂

@treefit @danialbehzadi some clients support this and some types of fediverse servers also support this. @jonny is currently working on a PR to add a "load more remote conversation" button into Mastodon if I understood right

julian

@[email protected] I'm not entirely sold on the replies collection traversal logic as penned by @[email protected]

It doubles down on the premise that individual notes are isolated entities whose connection to other notes is dictated solely by inReplyTo and replies.

7888 introduces the concept of a conversational context, which is maintained by the original conversation starter. When you have an ad-hoc source like this, you can just ask the context owner to supply the entire set of responses in one single call (or perhaps a few more if paginated.) No replies traversal needed.

wakest ⁂

@julian @treefit I personally don't have any "horses in this race" other then getting things to work better. I would imagine #fep7888* would need serious "buy in" from Mastodon for it to really take hold as the way forward so if the way @jonny implementing this for Mastodon has potentially more of a likelihood of getting merged this year then I welcome it...

* https://socialhub.activitypub.rocks/t/fep-7888-demystifying-the-context-property/3021/19

julian

@[email protected] you are not wrong about that. @[email protected]'s approach works now, but I'm not sure how well it will scale.

It could be perfectly fine. It might not, who knows.

But it's a good thing there's more to the fediverse than Mastodon.

jonny (good kind)

@julian
@liaizon
Yeah. That sounds cool but raises serious problems about trust, moderation, and implementation. Lmk when there is a working implementation of it anywhere, in the meantime I'm gonna try to get something that works deployed

julian

@[email protected] sure! NodeBB has it working now if you want to poke around on BrowserPub, just paste a topic URL into it.

v4.0.0 can pull entire topics in already (assuming the remote end supports it.)

When v4.1 drops you'll be able to do this via the topic URL itself.

jonny (good kind)

@julian
That looks basically the same as what I'm doing, just using a different collection name? https://github.com/NodeBB/NodeBB/blob/4caae7307cff28bce83294acc8e13f998f10d7b0/src/activitypub/contexts.js