Requests for comment/Cross-wiki notifications

From MediaWiki.org
Jump to navigation Jump to search
Request for comment (RFC)
Cross-wiki notifications
Component General
Creation date 2013-10-14
Author(s) Legoktm
Document status implemented
See Phabricator.
2013-10-14LegoktmT67661

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

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]