Requests for comment/Notification framework

Proposal

 * 32281 - central tracking-ish bug
 * dependency tree

... work in progress ...

Background
MediaWiki's original discussion system was based on fairly ad-hoc editing conventions, breaking 'Talk:' namespaces out from their sibling pages. Edits to 'User talk:' pages trigger a single "You have new messages!" notification flag, but this system cannot show any more detail such as how many messages, who left them, or what they contain. It also can't be easily extended to other sources of notification.

Extension:LiquidThreads adds its own threaded discussion system with a sort of concept of subscriptions / reply routing, such that replies to you on any threaded discussion can get routed to a similar "You have N new messages!" notification.

This is a good start, but should be generalized and available in MediaWiki core.

Things like "welcome to the site!", "your background upload is complete", "transcode of your video is complete", "your page has been deleted", etc would be very useful to have available as notifications; today they tend to get done as user-talk page sections by bot or JavaScript tools, which is awkward.

Cross-wiki
It would make our lives much, much, MUCH simpler if we can make this a unified service that works across multiple wikis (with Extension:CentralAuth and friends), so you get a single set of notifications without having to jump around sites.

Notification format
Definitely:
 * localizable text w/ parameters - short-form (email subject, title of mobile notification, line in drop-down menu in web UI)
 * localizable text w/ parameters - long-form (email body, click-through details on mobile or web)

Possibly:
 * some sort of categorization for filtering?
 * some sort of urgency?
 * some sort of hookup to the source to make it easy to reply, followup, whatever appropriate?

Filtering
There's some high interest in being able to filter, so you don't get swamped with low-priority notifications. An example problem today is that turning on email notifications for your watchlist can be *extremely* ugly for a big watchlist, yet *extremely* helpful for a small one.

Being able to more granularly tweak what notifications you get sent would be helpful.

This could be done in a manner of "subscriptions". Users then actively subscribe to types of events. Adding a page to the watchlist could then ask if the user wishes to subscribe to it as well in one of many possible types: edits to page, edits to talk, page moves, page deletes. . .eventually even tagging for various things.

Similar Event Rollups
It would be nice to have a system of "roll ups" for notifications that are of a similar nature or affect the same object. For example, if four people edit your talk page, each firing a notification, instead of getting something like this:


 * Brion edited your talk page
 * Jorm edited your talk page
 * Eloquence edited your talk page
 * Kaldari edited your talk page

We'd get something like this:


 * Brion, Jorm, Eloquence and 1 other edited your talk page

or even this:


 * 4 users edited your talk page (expand)

Or any number of interesting variations.

Email
Some things can trigger email notifications, including the things that will trigger user-talk notifications today; but also other events may trigger emails such as Extension:CodeReview's followup notifications.

These should be brought into the common notification system so they're available over non-email channels, and so that the email channels include relevant information (such as the *content* of a message!)


 * 32285 Email backend for notifications to supplement/consolidate enotif with common notification infrastructure

Web UI
The existing new messages links in the dynamically-generated web UI of MediaWiki will need to be updated to read from the central whatsit.

API
An API interface to poll for new messages would be useful for extending the front-end web UI so that you still see notifications even if you're on a page for a long time (say you're editing long text, or using an AJAX-y interface for page patrolling).

This would also be a first step for mobile apps and other tools to hook into the same interface.

(Further enhancement could be done with WebSockets or long-polling techniques, but may require server-side support for long-running connections.)


 * 32283 API point for polling notification data
 * 32284 Show live talk & other notification updates in web UI
 * 32292 Show watchlist & talk notifications in MobileFrontend web UI

Mobile push notifications
Various mobile operating systems like Apple's iOS and Google's Android have message proxying systems that allow an application to register to efficiently listen for notifications sent through an intermediary service, even when the application has been closed to save memory & power.

Backends to set up the device subscriptions and send pings through the proxy will be a benefit here.


 * 32288 Android cloud-to-device messaging server-side
 * 32289 Android app support
 * 32287 iOS push notifications server-side
 * 32291 iOS app support

User-to-user messaging

 * user talk (traditional)
 * Extension:LiquidThreads replies
 * Extension:CodeReview reply notifications
 * Special:Emailuser generalization?
 * proposed 30750 notification when @ in edit summary / talk?

System-to-user messaging

 * upload-by-URL backgrounding
 * Extension:TimedMediaHandler transcode completion
 * 29857 Welcome back email notification after renewed account activity
 * 29856 Email notification when verified email address is changed or removed

User activity

 * new user welcome
 * 27829: welcome users without relying on talk edition [See dependency tree for bug 27829]
 * Extension:CodeReview followup notifications
 * other users' edits: watchlist or watchlist supplement (high-priority items?)
 * someone deletes or marks your page for deletion
 * someone uses / removes your image