The goal of the project is to use push technology to provide MediaWiki notifications to Wikimedia web and app users. The initial focus of the project is on providing push notifications for the apps.
The push notification system consists of two components:
- Push subscription management and notification request support in the Echo extension; and
- A standalone service (push-notifications) for batching requests for submission to third party push providers.
In the initial (apps-only) implementation, to mitigate the user privacy and security risks associated with sending potentially sensitive information to users via third-party systems, pushed messages will contain only a short descriptor (e.g., checkEchoV1) to prompt the apps to retrieve message content from Wikimedia servers (e.g., by request to the Action API's notifications module). Further, the push-notifications service will collect push notification requests and send them in periodic batches in order to increase the difficulty of drawing inferences between on-wiki actions and messages traversing the public internet.
TechCom RFC: T249065: RFC: Wikimedia Push Notification Service
Target deployment date: TBD
This code is deployed to the Beta Cluster. The push-specific additions to Echo are live on all Beta Cluster wikis, and the extension is configured to send push notification requests to the push-notifications service instance running on deployment-push-notifications01.
Which code to review
- https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/push-notifications (entire repo)
- Relevant files/directories:
- includes/EchoHooks.php (see onApiMainModuleManager())
- Relevant files/directories:
Additional work in progress:
- T257320: Implement a silent notification type -- add a no-op notification request type to be sent at a configurable frequency along with true notification requests
- T251445: Instrumentation for Push Notifications
- T251441: CI and test coverage
Please initiate the performance assessment by answering the below:
- What work has been done to ensure the best possible performance of the feature?
I would expect this feature to have little to no performance impact on the sites.
With these changes to Echo, if a site is configured to add a push notifier type, when an Echo event occurs, the push notifier's handler function determines whether the user to be notified has elected to be notified about events of that type by push, and if so, enqueues a job to asynchronously retrieve the user's stored push subscriptions and make a request to the push service. An index has been added to the push subscriptions table (echo_push_subscription) to ensure fast lookups of push subscriptions by a user's central ID.
The push service itself should have no impact on the performance of the sites.
- What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?
A primary reason for having a standalone service for forwarding push notification requests on to the push platform gateways, as opposed to a lighter-weight solution such as ChangeProp rules, is to implement custom batching behavior recommended during privacy review to help mitigate risks to user privacy. In brief, the goal is to add entropy to the system to make it more difficult for an attacker to infer connections between actions on-wiki and notifications sent to a particular device. These recommendations include sending requests on to push provider gateways in batches; introducing randomzied delays before batched request submission; and sending no-op requests to add additional noise.
As such, the service is essentially intended to slow down requests. A key question (and a potential weak point) is how the service will perform under load.
- Are there potential optimisations that haven't been performed yet?
A more aggressive optimization on the MediaWiki side would be to have the push notifier handler function immediately enqueue a job for each Echo event without doing any check for whether push notifications apply to the user and event type; that would instead be checked at the time the job is performed. This would likely eliminate any possibility of a direct performance impact arising from the feature, but at the cost of sharply increasing the number of jobs enqueued (which might have an indirect performance impact).
- Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: firstname.lastname@example.org.
No measurements are yet in place. We would appreciate guidance on what measurements are needed in this case, if any.