Increasing the estimate after a discussion with @STran - we may need either a new API endpoint, or to alter an existing one a fair bit.

Blocking this on T333299: Stop API from returning excess IPs on user request, which should do some refactoring that enables this task to be done with fewer workarounds around existing architecture.

Revealing (temp user, IP) pairs is tricky, for a few different reasons.

Complexity
Revealing these pairs is more complicated than revealing all the IP addresses, because we need to do the work required to find all the IP addresses, and a filtering step, to only return the data for the original IP address (and also send information about which was the originally asked-for IP address).

Caching
It is more difficult to cache these requests.

Imagine a Special:Contributions page for a temporary user. For admins and checkusers, who can see all the IP addresses at once, each "show IP" button on the page sends all the revision IDs on the page, and fetches all the relevant IPs. In other words they are all asking for the same information, so all use the same query. After the first button is clicked on, any subsequent button clicks will hit the cache from the first click.

For patrollers, clicking on one button should only reveal instances of the IP address associated with the revision from that line. This means the query needs to identify what the clicked-on revision ID was. So every button has a different query (even if they return the same results), so clicking on a different button won't hit the cache.

Persisting reveal between page loads
Admins and checkusers can store which temporary users they have revealed recently, and on a new page load can request data for those users up-front, with no need for user interaction (clicking). Patrollers must store which (temp user, IP) pairs they know about, but they can't send their known IPs to the server (at least via the URL), because this is sensitive data. However, the server can't send the client all the IPs and ask the client to filter out only the known ones, because that would mean revealing IPs that the patroller doesn't already know. This could be solved e.g. by making a POST request (like Special:CheckUser) or encrypting the IPs (like Special:Investigate), but this is awkward and also makes caching more difficult.

Could we look into doing something different for patrollers? Some suggestions (after discussing with Niharika):

• IP reveal for patrollers works the same as for admins/checkusers
• Patrollers can just reveal one IP at a time by clicking on each button, and the reveal is not persisted between page loads
• Patrollers only have access to IP reveal on Special:Contributions (and it reveals all at once, and persists)
• Something else?

Change 904749 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/CheckUser@master] Allow for overrides in the ip reveal pub sub system

https://gerrit.wikimedia.org/r/904749

Thalia has outlined the issues with this workflow and since I just pushed up a patch that implements what's requested here, I thought I'd also pop by to confirm what she's mentioned:

1. Complexity - can be done (was done) but it added some patroller/not-checkuser specific code to the API. My implementation made it so that patrollers can no longer bulk access rev ids. This is fragile logic since there are now multiple states of permissions that might need to be managed (autoconfirmed, patroller, patroller + checkuser, etc). It could be argued that this needs to be done anyway, as no one besides checkusers should be able to bulk access rev ids no matter what.

2. Caching/Performance - in what I implemented, the caching we're able to do is reduced since the order in which the rev ids are passed to the API now matters (the first is the 'seed' rev id used to get the ip to filter against for non-checkuser users). Each click would represent a new call since that seed will change if the patroller is clicking to reveal multiple ips. Additionally, I had to do some technical rearranging which may have re-introduced a breaking performance bug noted by @dom_walden. I personally can't reproduce it but considering it crashed Chrome for Dom, I'm calling it out as a potential blocker to the current technical implementation.

Change 904749 abandoned by STran:

[mediawiki/extensions/CheckUser@master] Allow for overrides in the ip reveal pub sub system

Reason:

Product requirements have changed

https://gerrit.wikimedia.org/r/904749

Doing T334113: Enable IP multireveal for all users instead. Thanks for investigating this @STran