Requests for comment/Notification framework

From mediawiki.org
Request for comment (RFC)
Notification framework
Component General
Creation date
Author(s) Brion Vibber, Brandon Harris
Document status implemented

We're doing this as Echo (Notifications)!

Proposal[edit]

... work in progress ...

Background[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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.

Backends[edit]

Email[edit]

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[edit]

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[edit]

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.)

Mobile push notifications[edit]

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.

Data sources[edit]

User-to-user messaging[edit]

System-to-user messaging[edit]

User activity[edit]

  • 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
Retrieved from "https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Notification_framework&oldid=4901088"