Requests for comment/Notifications in core

T

Background
There was a successful RfC to implement a notifications framework, and the implementation happened in an extension (Echo). Since then there's been further work in the extension, and certain features of it have become integral in how editors use the wiki (mentions, userrights notifications, etc.).

Problem

 * Being in an extension, Echo has to use ugly hooks to suppress some core features and has generally weird interactions with some things.
 * AbortTalkPageEmailNotification hook to suppress core talk page notifications (hook introduced solely for Echo)
 * SendWatchlistEmailNotification similar thing (also introduced solely for Echo, bugzilla:53569)
 * GetNewMessagesAlert to suppress the orange bar while still allowing meta=userinfo&uiprop=hasmsg to work
 * enotifusertalkpages and echo-subscriptions-email-edit-user-talk preferences are the same thing (c.f. UserLoadOptions hook)
 * Furthermore, extensions that wish to use it have to do conditional checks everytime they'd like to trigger a notifications.
 * Finally, and most importantly,  is a reserved word in PHP, preventing us from using it as the namespace for a PHP class. ;-)
 * Finally, and most importantly,  is a reserved word in PHP, preventing us from using it as the namespace for a PHP class. ;-)

Proposal
Move the infrastructure of Echo and some notification types into MediaWiki core. Specifically:
 * flyout code
 * meta=notifications API module
 * Special:Notifications no-js page
 * formatter system for creating notification types
 * email notifications (HTML and plain text)
 * orange indicator thing for new talk notification (and get rid of OBOD, even for anons while we're at it)
 * underlying code for all of the above to work
 * Some notifications:
 * user-rights
 * welcome
 * edit-user-talk
 * reverted
 * emailuser
 * cross-wiki notifications

This would leave the following in Echo: EventLogging code would go into the WikimediaEvents extension, UserMerge hooks would go into the UserMerge extension.
 * page-linked
 * mention
 * thank-you-edit
 * A back-compat layer for things that haven't transitioned to core notifs yet

And while we do the migration of code, we should make sure that the code being newly introduced is architected as we'd like it. (i.e. maybe EchoEvent::create API would be different)

Open questions

 * Do we rename database tables to drop the "echo" name from them? (echo_event, echo_notification, echo_email_batch, echo_target_page)
 * Cross-wiki notifs are currently a beta feature. Do we need to wait for that to be no longer a BF to put this in core?
 * What do anonymous users get?
 * Can/should we be setting different preferences for new users (see onAccountCreated hook in Echo)?
 * Should mention notifications go into MediaWiki core eventually? Legoktm doesn't like the current alternate parser implementation stuff

Implementation plan
Echo is a pretty large extension with a lot of functionality, so we will need to do this in parts.
 * Create notifications tab in preferences in MediaWiki core (Phab:T65577)
 * Get rid of echo-show-alert preference and config global. Move into core, remove OBOD for anonymous users (223213)
 * Move thank-you-edit milestone notifications out of Echo into Thanks extension?

Note: This RfC intentionally avoids the question of. I think we do need to unify them somehow, but don't think it should block moving Echo into core.