I'm planing on submitting a patch for this. This would be based on the following ideas:

• we don't really need persistent storage for anon notifications, so we can store them in the WAN object cache for say a month
• we can't notify all users using a given IP, so we need to know which ones to notify, for this we can use a cookie which is added when editing (and maybe in other circumstances).

Implementation-wise, we would have:

• a new class NotifAnon to handle cookies and marking as read, a new class AnonNotificationMapper to fetch notifications from cache
• two cookies storing the latest seen timestamp for alerts and notices.

Limitations:

• temporary
• will not notify if user clears cookies or changes browser/platform
• no crosswiki
• limited to say 10 notifications per type to quickly fetch from cache

Use cases: reviews, thanks, reverts, active deferrals

Change 329374 had a related patch set uploaded (by Matěj Suchánek):
Support limited anon notifications

https://gerrit.wikimedia.org/r/329374

In T58828#2908658, @gerritbot wrote:

Change 329374 had a related patch set uploaded (by Matěj Suchánek):

By @Cenarium, of course.

Change 331487 had a related patch set uploaded (by Cen.temp):
Support anon notifications

https://gerrit.wikimedia.org/r/331487

Thanks for your work, @Cenarium !

Some of this probably requires some design and product decisions; I'm pinging @jmatazzoni, @Pginer-WMF and @Catrope to make sure they're on it, and are chipping in if/when necessary.

Issues to discuss include:

• Random expiration when server caches expires
• Receiving notifications not intended for you
• Limited notification count (10 per type)
• UI (Should we hide notifications UI if there are no unread/cookies indicate no unread, as it currently does?)
  • Other UI questions, such as warning users they may receive notifications that are not intended for them
• Current patch says, “there is no page filtering, they are local only and can't be marked unread” (that means Special:Notifications has limitations) and “Initial support is provided for new messages, mentions and reverts.” (We’ve never limited an Echo UI/delivery method to one type of notification before).

The project we have in hand and for which this patch was presumably intended is Deferred Changes. One of the outstanding issues we have to deal with there is to provide anonymous users with feedback letting them know that the change they just saved is being actively deferred. Meaning it's not being published pending review.

While a notification would be one way to clue these IP users in, it's not clear that it's the most effective way, since new and IP users may not even know about notifications. And given some of the issues that have been raised about anonymous notifications (there's a reason someone assigned this the Epic tag), it's probably not the easiest way, either.

There are a number of good reasons I'm sure to extend Notifications to anon users. But, as I say, that's not the project we're working on now. I think we need to take a step back and consider what our goals for communicating with users impacted by Deferred Changes are, and how we can best achieve them. I've created a task for that at T156083. Input from all is welcome there.

In T58828#2963503, @Mattflaschen-WMF wrote:

Issues to discuss include:

• Random expiration when server caches expires

At first I only wanted this to cover the deferred changes case, but we might as well build a full fledged system. I think the cache would be enough in the vast majority of cases for the IP to get the notification. And having an archive of notifications for IPs is IMO not essential, but sure if we can, it would be preferable overall to use the db. My only concern is whether we can do so, as I was under the impression that some tables are too sensitive to be altered in some ways.

@jcrespo: Would it be possible to alter the echo_notification table this way:

ALTER TABLE echo_notification ADD COLUMN notification_anon_ip varchar(15) not null default '';

• Receiving notifications not intended for you

I believe this is largely addressed by the cookie. Users see the notification only if they have the cookie. The cookie is added when an IP edits. To get a notification not intended for you, one would need to have edited recently and inherit an IP that a previous unrelated user edited from. This is possible, but even then the new user should probably be made aware of the notification.

• UI (Should we hide notifications UI if there are no unread/cookies indicate no unread, as it currently does?)

It isn't the cookie that indicates no unread. The cookie indicates that the user is a contributor (has recently edited) and thus should be made aware of notifications on this IP (it also contains the last seen timestamps). I've done this for performance, to avoid having to needlessly query for notifications when the user isn't a contributor.

Assuming we can alter the db, I've modified the patch set to offer the same level of functionality than notifications for logged in users. They can be marked read / unread and filtered by titles, and cross wiki notifications are possible. The last one requires caching the IP address in a global key.

echo_notification table for enwiki:

CREATE TABLE `echo_notification` (
  `notification_event` int(10) unsigned NOT NULL,
  `notification_user` int(10) unsigned NOT NULL,
  `notification_timestamp` binary(14) NOT NULL,
  `notification_read_timestamp` binary(14) DEFAULT NULL,
  `notification_bundle_base` tinyint(1) NOT NULL DEFAULT '1',
  `notification_bundle_hash` varchar(32) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `notification_bundle_display_hash` varchar(32) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `notification_seen` tinyint(1) NOT NULL DEFAULT '0',
  UNIQUE KEY `user_event` (`notification_user`,`notification_event`),
  KEY `user_timestamp` (`notification_user`,`notification_timestamp`),
  KEY `echo_notification_user_base_read_timestamp` (`notification_user`,`notification_bundle_base`,`notification_read_timestamp`),
  KEY `echo_notification_user_base_timestamp` (`notification_user`,`notification_bundle_base`,`notification_timestamp`,`notification_event`),
  KEY `echo_notification_user_hash_timestamp` (`notification_user`,`notification_bundle_hash`,`notification_timestamp`),
  KEY `echo_notification_user_hash_base_timestamp` (`notification_user`,`notification_bundle_display_hash`,`notification_bundle_base`,`notification_t
  KEY `echo_notification_event` (`notification_event`),
  KEY `echo_notification_user_read_timestamp` (`notification_user`,`notification_read_timestamp`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

It has not primary key. All tables must have a primary key. T136428 is a blocker.

Aside from that, I do not see why not. Consider using a separate table with a key if most of those fields are going to be null and unused.

Change 331487 abandoned by Jdlrobson:
Add anon notifications

Reason:
This will need to be re-submitted against the MinervaNeue skin.

https://gerrit.wikimedia.org/r/331487

The way this needs to implemented (or not; we might get it for free) depends on T283177: Anonymous Contributors IP Masking. See especially T283177#7131249.

We might want to decline this task because of the work coming up in T324492: Temporary accounts - MVP (cc @Niharika).

In T58828#8533994, @kostajh wrote:

We might want to decline this task because of the work coming up in T324492: Temporary accounts - MVP (cc @Niharika).

The specific implementation proposals here are not relevant anymore, I think (with apologies to @Cenarium who put together a really impressive patch some years ago). We should figure out what to do about notifications to temp users (who'll essentially replace temp users) though, as part of T326877: [Epic] Update Growth Team-owned products that may be affected by IP Masking.
On one hand, I think we all want notifications for temp users to work like for normal users - the inability to notify anons has been a pain. On the other hand, they won't have access to preferences, so they can't opt out - will that require special consideration? (Or will that be only true for the MVP version?)

Will this task remain relevant for third-party wikis? I assume eventually everyone will switch over to temp users and it will become the default in MediaWiki, but maybe not?

Late to the party - I think it would be good to implement notifications for temp users as this would facilitate better communications with them. Communicating with unregistered editors has been a long-standing community pain point, having come up in various discussions over and over.
For the MVP, maybe we don't worry about giving them the ability to disable notifications? I don't have data about how frequently people disable notifications. That can be a consideration while making this decision.

CC @RHo @Prtksxna @KStoller-WMF

In T58828#8684545, @Niharika wrote:

Late to the party - I think it would be good to implement notifications for temp users as this would facilitate better communications with them. Communicating with unregistered editors has been a long-standing community pain point, having come up in various discussions over and over.
For the MVP, maybe we don't worry about giving them the ability to disable notifications? I don't have data about how frequently people disable notifications. That can be a consideration while making this decision.

CC @RHo @Prtksxna @KStoller-WMF

Hi @Niharika - quoting my comment from related ticket below. Perhaps something that requires more consultation with @KStoller-WMF and perhaps web team to make clearer the effort involved? It seems like it would mean enabling Echo alerts and notices drawers with an altered design that doesn't give access to Special:Preferences.

In T330509#8658191, @RHo wrote:

Hiya, adding @Niharika to confirm but I don't think we want to add extra functionality for temp accounts over IP editors in MVP, so temp accounts should not have access to Special:Preferences.
As for Echo, I think this is a no as well per status quo of Anons not receiving notifications (T58828 remains open and stalled).

However, I wanted to confirm that the orange bar of doom and equivalent mobile version when a message is posted on their Talk page is definitely something separate from Echo Notifications, is that right?
Relatedly - a page has been started here to populate differences between user account types that Growth may wish to start contributing to as well: https://www.mediawiki.org/wiki/User_account_types

In T58828#8684545, @Niharika wrote:

For the MVP, maybe we don't worry about giving them the ability to disable notifications? I don't have data about how frequently people disable notifications. That can be a consideration while making this decision.

T132977: Allow disabling a notification category from within the notifications popup is somewhat related.

Change 897854 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/Echo@master] Don't show preferences link to temporary users

https://gerrit.wikimedia.org/r/897854

In T58828#8684555, @RHo wrote:

In T58828#8684545, @Niharika wrote:

Late to the party - I think it would be good to implement notifications for temp users as this would facilitate better communications with them. Communicating with unregistered editors has been a long-standing community pain point, having come up in various discussions over and over.
For the MVP, maybe we don't worry about giving them the ability to disable notifications? I don't have data about how frequently people disable notifications. That can be a consideration while making this decision.

CC @RHo @Prtksxna @KStoller-WMF

Hi @Niharika - quoting my comment from related ticket below. Perhaps something that requires more consultation with @KStoller-WMF and perhaps web team to make clearer the effort involved? It seems like it would mean enabling Echo alerts and notices drawers with an altered design that doesn't give access to Special:Preferences.

In T330509#8658191, @RHo wrote:

Hiya, adding @Niharika to confirm but I don't think we want to add extra functionality for temp accounts over IP editors in MVP, so temp accounts should not have access to Special:Preferences.
As for Echo, I think this is a no as well per status quo of Anons not receiving notifications (T58828 remains open and stalled).

However, I wanted to confirm that the orange bar of doom and equivalent mobile version when a message is posted on their Talk page is definitely something separate from Echo Notifications, is that right?
Relatedly - a page has been started here to populate differences between user account types that Growth may wish to start contributing to as well: https://www.mediawiki.org/wiki/User_account_types

FWIW the UI related code changes are pretty small (see https://gerrit.wikimedia.org/r/897854)

Without a preferences link, "All notifications" button expands to fill the width of the container.

For the apps, I guess you would want to disable the "Types of notifications" section, because that uses an API to set the notification types, which would expect a registered user with the ability to set preferences.

What about email notifications? The link to preferences acts as an unsubscribe link there. Not having an unsubscribe link is bad form.

In T58828#8690545, @Tgr wrote:

What about email notifications? The link to preferences acts as an unsubscribe link there. Not having an unsubscribe link is bad form.

AIUI, temporary users do not have the opportunity to supply an email address, so they would not receive any email notices.

Temp users cannot have an email address. Email address is a "special" preference, stored in globaluser not user_properties. It can't be set by API action=options or action=globalpreferences. It can only be set by Special:ChangeEmail which is denied for temp users.

Hi folks - will update the task description as well, but per T330509#8695977 let's keep this task about providing Notifications to IP editors (Anons), and the move discussion on providing to temporary accounts in T330509