Requests for comment/Notification framework
Status: This RFC has been closed and accepted. We're doing this as Echo (Notifications).
... work in progress ...
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.
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 
- 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)
- 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?
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.
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!)
- bugzilla: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.
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.)
- bugzilla:32283 API point for polling notification data
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.
- bugzilla:32288 Android cloud-to-device messaging server-side
- bugzilla:32289 Android app support
- bugzilla:32287 iOS push notifications server-side
- bugzilla:32291 iOS app support
Data sources 
User-to-user messaging 
- user talk (traditional)
- Extension:LiquidThreads replies
- Extension:CodeReview reply notifications
- Special:Emailuser generalization?
- proposed bugzilla:30750 notification when @<User name> in edit summary / talk?
System-to-user messaging 
- upload-by-URL backgrounding
- Extension:TimedMediaHandler transcode completion
- bugzilla:29857 Welcome back email notification after renewed account activity
- bugzilla:29856 Email notification when verified email address is changed or removed
User activity 
- new user welcome
- bugzilla: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