Requests for comment/Cross-wiki notifications

Cross-wiki notifications would be added to the Echo extension. If a user's account is global (via CentralAuth/shared user table), all of their notifications would be accessible on all wikis they have an account on.

Why do we need global notifications?

 * Current cross-wiki integration for users sucks. [Expand on this]
 * Watchlist wishlist
 * Effectively becomes a global watchlist; users now "ping" to let a user know they've responded, rather than users checking their watchlist
 * This opens up new notification possibilities as well (well, at least theoretically):
 * An image you uploaded to commons was added to article XX on xxwiki
 * An article you started on xxwiki was linked to an article on xxwiki via Wikidata

Central database table

 * All events and notifications are stored in one central database, with the current schema plus one column for the event table indicating which wikiid it came from (see )
 * notifications would just do a join with event to get the context of the wiki they are on
 * This database would get very big, very fast...
 * We currently purge if you have more than 2k notifications...
 * API (meta=notifications) will return global notifications if the user preference is to do so by default. There will be an optional parameter to force or suppress global notifications.
 * Check whether the user is globalized with CentralAuth OR if using a shared user table:
 * Only users with a global account can have global notifications
 * If a user doesn't have a global account, they get echo notifications in the standard manner, split across all wikis
 * If Extension:Foo creates a notification, but isn't deployed to all wikis, how do we format and display that notification on a wiki where it isn't deployed?
 * Maybe also add a event_deleted column to make revdel/hiduser lookups faster

Proposed database schema
current schema

Cross-wiki API requests

 * Have some database table or cache that keeps track of the wikis where users have unread notifications
 * Internally fire off API requests to those wikis to get the presentation model of those notifications
 * Combine and sort them and send to the user.
 * Nicely handles extensions that create notifications not being deployed on all wikis since we wouldn't be able to access those formatters or info
 * Potentially slow? You take up (at least) two backend servers when serving the request

User interface

 * User has a preference on each wiki whether to see global notifications in the flyout.
 * User options on which notifications are delivered globally. For example, the user could choose to have 'mentions' delivered globally, 'reverts' only delivered locally, and 'thanks' not delivered at all.
 * It might look something like this?
 * This would help with users active on many wikis getting bombed by notifications which may be not as important
 * There would be some kind of toggle on Special:Notifications to switch between displaying global and local notifications
 * Email notifications would be sent out based on the preferences on the wiki the notification was created on
 * Users can choose to receive a summary of notifications on a daily or weekly basis; those summaries should include all global notifications in one email.
 * Need some indicator in the flyout that a notification is not from this wiki
 * File:Athena-Wikimania-2012-Echo-BrandonHarris.png and File:Echo-Notifications-Basic.png
 * Doesn't scale well. This works for people active on 1-3 wikis, but not for people who might be active on a few hundred like SWMT members
 * Wikia accordion implementation [//vignette1.wikia.nocookie.net/central/images/9/98/Message_wall_notifications_1.png/revision/latest?cb=20150225081847]
 * crosswatch has Project logo + language