The first one should truncate the offending user fields as Misskey allows a stupid amount which would cause a reject and a refetch The second makes the "refetch" jobs unique meaning it prevents a flood of requests in the future.
@i@dcc@sun It's also funny that they want to block Pleroma and Akkoma because of this, because they already mitigated this flood of requests issue months ago by sending 429s.
The issue they talked about a week or two ago as the reason is an increase in traffic when it comes to custom emojis. Which also makes complete sense as Pleroma and Akkoma are basically the only mainstream servers that support them. And Pleroma already stores the emojis in a media proxy cache.
Instead of fixing their own issues they themselves created (more custom emoji than there are kanji), they try to pin it on others.
@i@dcc@sun Also worth noting that they block it automatically by version number instead of activating the block only when they get flooded. Everyone that has it patched manually must apparently also change the version string.
@phnt@dcc@sun posts don't have the associated emoji included, but emoji can have dozens of tagged profiles that pleroma will try to pull if you're downstream of the thread
select count(*), jsonb_array_length(data->'tag') from activities where data->>'type' = 'EmojiReact' group by jsonb_array_length(data->'tag') order by jsonb_array_length(data->'tag') desc;
and yes the pinned post fetching is problematic too, because it's another area where you have a persistent retry loop whenever the profile caches out for a refetch
@i@dcc@sun I think it was the other way around. A profile got fetched, ReceiveWorker started to pull the pinned posts which included a stupid amount of custom emoji (usually the full post was made of them), it failed and added the job back to the oban queue, and repeated the same thing again until it got a 429 which still didn't kill the constantly adding jobs.
At least that's what I think happened when I ran into this months ago.
we could be syncing hundred of posts a time from a shared outbox with a cursor abstraction, but instead it's hope the other party knows they're on a federated network and honors your follow request and also never messes up anything
@i@dcc@phnt I wasn't aware Mastodon did this, I'm actually a little confused, it just bundles multiple sharedinbox posts into one post? what's the benefit if you're using http/2?
@i@dcc@phnt oh I see, so you suggest that there's one endpoint and an entire server subscribes to all its follows on the other server, which the remote server keeps track of and like batches up every request in the last 30 seconds or something and posts at once.