@BurungHantu @jonah FYI I'm having trouble finding some of the users on social.privacytools.io or their posts. There are some users I can see on here:
https://social.privacytools.io/public
... but can't find in a search. Others I can find, but I can't see their posts. Possible causes:
* folks using #Mastodon privacy settings to hide themselves or their posts from the wider #fediverse (fair 'nuff)
* bugs or configurations weirdness with your instance, the one I'm on, or the web client I use (#Pinafore.social)
@strypey @BurungHantu we currently use masto.host for this instance so I can’t really do much. We are going to migrate to our own servers today so we’ll see if that helps (it’ll have more resources most likely) and if it doesn’t, I should at least be able to investigate and fix it.
@strypey I just realized you’re on another instance. Another possibility is your instance just isn’t familiar with ours. When you search are you including the social.privacytools.io part of the username? Also not pulling in older posts is somewhat expected behavior, but posts from after you follow a user should work fine: https://github.com/tootsuite/mastodon/issues/34
@strypey yeah if you don’t include it, it only goes through users your instance is aware of, i.e. just users anyone on your instance already follows or has boosted before.
Also, that is exactly why that issue I linked exists, and has for years. Idk why they’re not fixing it, it’s easily the most annoying part of Mastodon for me personally 🙄
@strypey the post *count* on their profiles should still be accurate, so that’s what I use to judge if I should click to see their full profile or if I have all their posts already.
@jonah maybe it's a storage issue on the receiving instance? Although that could be solved by allowing admins to set a size limit for downloading user histories. Or maybe it's seen as a possible vector for attacking an instance:
1) set up troll instance X
2) have hundreds of bot users follow every user on instance Y
3) instance Y is hit with hundreds of requests to download its entire database
4) if you really want to be annoying, spin up multiple troll instances, do this, then shut them down
@strypey no idea, maybe. It should at least be a configurable option on both sides though for the admins.
[x] Download user history from remote instances on follow
[x] Send full user history to remote followers
I’d also imagine it’d be a low priority task. I’d even be fine with the posts taking an hour or so to completely populate. Or if they kinda loaded 5 at a time so more came in as you scrolled down until you reached the end, so it’s only the users you care about reading all their posts.
@jonah
> so more came in as you scrolled down until you reached the end
Of course! That solves both the problem of excessive storage/ bandwidth use (for posts that may never be read) and history fetching as a vector for attack. It seems obvious as soon as you suggest it, but it didn't occur to me. Great thinking! I wonder if it's been suggested in the issue discussion? If not, it might be just the thing to motivate someone to write a patch.
@jonah of course to solve the problem across the whole fediverse, a version of that logic would have to implemented on all the fediverse apps. I wonder if #ActivityPub addresses this, or if an extension could be written to the spec to standardize it?
@strypey not sure, I’ll take a look at the relevant issues later. It probably has though, I’m not that creative so I probably read it somewhere 😆
@jonah
> are you including the social.privacytools.io part of the username?
Nope. Gotcha. All the ones I tested worked when I do that. User error on my part ;)
> not pulling in older posts is somewhat expected behavior
Now that you mention it, I always wondered why some users seemed to have no older posts. It does seem like something that could be fixed (not by you). If a web browser can access the older posts from the remote instance (by navigating to its URL), why not a #fediverse client?