I think time has come, for an AP update, after years. But no one wants to puts his hands on it. Too much time has passed cooking and now it's too hot. Should had happened already a few years ago. That's why of today's protocols proliferation and competition.
@Moon@alex the "push only" problem is such a colossal fuckup that the protocol should have never been published to begin with until that was fixed. "I love seeing threads full of missing responses and holes" said the crazy person.
@Moon okay @alex maybe you know why but is there a good reason that AP does not have a condition that says "if you read a post, request a list of replies to said post from OP's home server" because that would fix 99% of the issue. I don't need all posts from everywhere always but I do need all posts in that thread.
@RustyCrab@Moon When a server pushes, it already has the post in memory. When it pulls, it is requesting the remote server to get the post out of its database. The remote server should rate-limit that. And on the Nostr pull model it does, which is a challenge I'm facing in Ditto. If the CLIENT pulls, it has its own IP unique to the user. If the server pulls, it will quickly get rate-limited. In Ditto I will have to mostly rely on a push model, and perform pulls through a narrow pipe where I rate-limit myself in a batched queue type of thing. The client-relay model goes with the grain (what I'm doing goes against it), although it brings a different set of challenges.
ActivityPub does pull in some cases, mainly for fetching posts inside of threads, and for direct links pasted into search. The reason you're seeing broken threads is because of private accounts, deleted posts, domain/IP blocking, network failures, and other bugs. Nostr does improve the situation by making everything portable, and because the developers are more focused on public conversations and anti-censorship. But it's more about design choices of existing software in either protocol than a technical limitation of either protocol.
@alex@Moon mastodon is its own separate network as far as I'm concerned. I will take your word on the efficiency but I do not see why that would be a problem if the scope was limited to that one specific thread being requested.
@RustyCrab@Moon Check the network tab and see if it makes an API request when you hit reply. I'm not aware of any endpoint to do that. It just recursively fetches the inReplyTo for posts when the post first comes in.
@alex@Moon >ActivityPub does pull in some cases, mainly for fetching posts inside of threads my experience with this is odd on pleroma. Threads are usually missing a bunch of posts by default UNTIL I click on reply arrows from people I am already either following or someone else on my server is following. That tells me that they can be fetched but they aren't by default. If that's not intentional then that's a big implementation problem.
@RustyCrab@alex@Moon I think pleroma-fe doesn’t pull threads in real time, it loads your follows and adds the posts if they happen to be in the same thread