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 through the personal tools flyout as well as Special:Notifications (no-JS and archive).

Request for comment (RFC)
Cross-wiki notifications
Component General
Creation date
Author(s) Legoktm
Document status implemented
See Phabricator.

Why do we need global notifications? edit

  • 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 yywiki via Wikidata

Backend approaches edit

The backend needs to be able to support:

  • One API endpoint for the client to request to get notifications across multiple wikis
    • Said endpoint should have similar response time as the current one (timing data on how long opening the flyout currently takes)
  • Cross-wiki notifications are mainly for active users, so we need to be able to handle odd cases where users are active on 700+ projects.
  • Respect local revision deletion & suppression
  • Mark notifications as read from the remote wiki, individual ones and "mark all as read"

Central database table edit

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 #Proposed database schema)

    • notifications would just do a join with event to get the context of the wiki they are on
    • This database might get pretty big quickly...
  • If Extension:Foo creates a notification, but isn't deployed to all wikis (e.g. EducationProgram), 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 (maybe we should do this anyways??)
  • What about local message overrides?
  • Most of our caches like LinkCache/UserCache only work for the local wiki (gerrit:177960 was a WIP)

Proposed database schema edit

current schema

CREATE TABLE /*_*/echo_event (
	event_id int unsigned not null primary key auto_increment,
	event_type varchar(64) binary not null,
	event_variant varchar(64) binary null,
	event_agent_id int unsigned null, -- The user who triggered it, if any
	event_agent_ip varchar(39) binary null, -- IP address who triggered it, if any
	event_page_namespace int unsigned null,
	event_page_title varchar(255) binary null,
	event_extra BLOB NULL,
	event_page_id int unsigned null,
	event_wiki varchar(255) binary not null -- This is the new column
);

The echo_notification table would stay the same.

Cross-wiki API requests edit

  • Have some database table or cache that keeps track of the wikis where users have unread notifications, which is updated whenever a new notification is created
  • Internally fire off API requests to those wikis to get the presentation model of those notifications (not an internal ApiMain function call, an actual HTTP request)
  • 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
  • Different perf impact? You take up (at least) two backend servers when serving the request

User interface edit

  • Design ideas are proposed and researched with users.
  • 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
  • Wikia accordion implementation [1]
  • crosswatch has Project logo + language [2]

See also edit