Requests for comment/Cross-wiki notifications
Appearance
(Redirected from Requests for comment/Global notifications)
This was implemented, but someone should update this with technical details. |
Cross-wiki notifications | |
---|---|
Component | General |
Creation date | |
Author(s) | Legoktm |
Document status | implemented See Phabricator. |
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...
- We currently purge if you have more than 2k notifications, but that may change in the future
- 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]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
- 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
- File:Athena-Wikimania-2012-Echo-BrandonHarris.png and File:Echo-Notifications-Basic.png
- Wikia accordion implementation [1]
- crosswatch has Project logo + language [2]
See also
[edit]- m:crosswatch "is a cross-wiki watchlist tool for Wikimedia projects" which also displays cross-wiki notifications
- 9 September 2015 RfC meeting notes