Page MenuHomePhabricator

Determine approach for notifications for IP Editors on Android
Closed, ResolvedPublic


As mentioned in T278838, we do not presently display IP notifications.

This task is to determine possible approaches to display IP Notifications in a way optimized for mobile and make a decision on which approach to pursue.

Possible Approaches:

  1. If there is a notification for that IP, we check which article its for, and check if the device that has the app also edited the same article, and then expose the notification
  2. Give each device a Unique identifier and check notifications for anon users based on their device unique identifier
  3. Pipe the default MediaWiki notifications through the same API we’re getting echo notifications through.
  4. Bring anonymous/IP editor notifications into the Echo notification extension.
  5. Show old orange notifications for IP users at the top of articles, like web does.

Tradeoffs of approaches

Event Timeline

Dbrant renamed this task from Determine approach for IP Editing on Android to Determine approach for notifications for IP Editors on Android.Sep 21 2021, 2:25 PM

To flesh out approach #1 a bit further:

  • The app would maintain a local list of articles that the user has edited.
  • If the user is not logged in, and has edited an article within the last 7 days (can be adjusted), then:
    • Periodically check the Talk page of the user's IP address (e.g. every time a new article is loaded).
    • If the talk page contains a section where it mentions one of the articles that have been edited by the user (i.e. contains a link to it), then show a notification in the app. If the user taps the notification, it will take them to the Talk page for their IP.

This logic depends on the idea that when experienced editors revert undesirable changes by an anonymous user, they simultaneously leave a message on the Talk page of that IP address, explaining the reason for the revert. Crucially, such messages usually contain a link to the article that was edited.
For example:

Thanks Dmitry. Three points of clarification:

  1. We'd just show in-app notifications (and in the app's notification center), not system-level notifications, right?
  2. To be clear, we would track articles edited but not IP addresses used, right? So it's all based on the current IP address?
  3. Would these notifications persist? Let's say the triggers create a notification and it's in notification center - but at the next app launch, we're on a new IP address. Would the notification disappear?

Technical note: the IP address of the current user can be determined by looking at the x-client-ip header that is returned in most responses from the API. (Determining the IP address from the client network interface is not reliable since they could be communicating through a proxy)

Thanks @Dbrant for getting to this!

IMO a simpler approach would be better:

  • Any time the user saves (or tries to save) an edit while not logged in, locally record the timestamp of that edit.
  • If the most recent edit is less than t_1days ago, then:
    • On every logged-out page load, check (it might even be possible to "piggyback" this on another request)
    • If the messages flag is set, check the talk page history (the correct IP will come back in the name field in the previous request), and:
      • If the most recent edit to the IP's talk page was less than t_2 days ago, show an alert.
      • Otherwise, do nothing.

I'd think t_1 = t_2 = 7 days would be about right, but you can probably get away with lower values.

This doesn't bother non-editors at all (even with wasted bandwidth), and I suspect would run a fairly low risk of giving editors spurious messages. You'd need ''two'' reasonably active editors unlucky enough to get the same IP.

The problem with checking a list of articles is that it's often the important (I.E. hand-written) messages that don't contain such links. For example, "When you do <reasonable-seeming thing> you cause <this giant mess>. Please stop."

Thanks for the additional ideas, @suffusion_of_yellow
We'll do some initial mocking up of these concepts and report back.

I think it might also make sense to display revert notifications for edits remembered by the app similar to #1. Maybe just for reverts with an edit summary different from the default (the assumption being that a non-default revert summary might explain what's wrong with the reverted edit), if that's possible to determine.

As there’s no design work involved → moving this to QA signoff

Testing on 2.7.50388-beta-2021-12-02, I was not able to trigger any notification from reverting a change from a logged-out user. Details below:


  1. Installed the app on two devices and did not login on either
  2. Put the app on both devices into developer mode (by tapping Wikipedia logo within 'about' in settings)
  3. Added the 'test' language to both and removed all other languages
  4. Made edits on the article titled Tmtest/en -
  5. On my laptop, went to the same article and reverted both edits

A revert notification on both devices

No notifications were presented (waited and checked multiple times for over an hour)

Note - I am not sure if notifications work on I logged in on one device and edited this article ( On my laptop, I reverted the edit and a notification of the revert appeared soon thereafter.

@ABorbaWMF Here are some concrete notes for testing (this is a tricky one):

  • This only deals with receiving Talk notifications on the talk page of the IP address of the current user. It is not expected to receive revert notifications, or any other nontification type.
  • After making an edit as an anonymous user from the app, you should then write a message on the talk page of that IP, from a different IP than the one used for editing.
  • Open the app again (on the original IP), and navigate to any article (in the same wiki language as the edit was made), and you should see a notification.

@Dbrant - Thanks!

Using the steps above I was able to reproduce the situation and I was able to verify the message in notifications for the anonymous user. Tested on 2.7.50388-beta-2021-12-02