I see I got pinged once or twice for this (in 2023; I vaguely remember drafting a reply but obviously never got around to posting it).
I've been aware of this issue for some time, and my current thinking is that features like this one (the user-ignore feature) can actually happily exist almost entirely client-side (that is, right now this feature is implemented as a scattered pile of PHP supported by a teensy bit of JS, but, from a security perspective, it makes more sense for it to be implemented in the opposite way: as a pile of JS supported by a teensy bit of PHP [1]).
So, I'd like to rewrite the whole thing and kill a few birds with one (largish) stone:
(1) Fix the issue described in the OP [2].
(2) Fold in some other ignore-related improvements I've collected (see the second part of
this post).
(3) Convince theymos to remove the current implementation in favor of the new one, so that this whole exercise results in
discarding (rather than accumulating) attack surface.
But, there's some behind-the-scenes stuff that's yet to be solved: the above is just where my head's at, currently; no promises on when (or even if) I'll actually pursue any of this thinking.
[1] I mean, the security argument for shedding server-side complexity and preferring certain things to be client-side holds water on its own, but where it pulls so far ahead of the alternative that it's no longer even a contest is when you start to add fully fleshed-out features into the mix. The thing about a very server-side-centric system like SMF is that continued feature development will always butt up against the need to keep the amount of attack surface manageable, so that reasoning out the security consequences of each new change remains practical (both for theymos and for me). Really, I'd prefer for most of the feature to exist in the browser, and for only list/setting persistence to need any server-side support.
[2] This issue (lack of paginated UID <-> name conversion) actually gets fixed (mostly) by default when moving things to the browser: a local copy of the (entire) list is needed for client-side ignoring to even work (and there are a few ways I can think of to never have to
resolve UIDs into names, or vice versa). I have to imagine that
most users either have empty or small lists (mine only has two names on it, for example). For the people with
huge lists, the need for the client to retrieve the whole thing from the server once per session (ignoring
localStorage for now) might manifest as the feature only kicking in a few seconds after an authenticated session begins, but weighed against completely unburdening the server of the normal ignore-related processing it would otherwise have to perform, I'm all but certain that the very small (average) increase in session traffic won't take too much away from the whole idea.