Change 891860 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Echo@master] IP masking: Disable Echo for temporary users

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

We could also think about disabling the "Preferences" button for temporary users.

We'd probably want to adjust the Echo milestone wording to encourage permanent account creation?

If we want to keep Echo for temporary users, then we need to consult with Data-Persistence about the number of additional rows this would result in; presumably enabling for temporary users would mean undoing the progress made in T308084: Reduce DB space used by Echo notifications.

cc @KStoller-WMF

Do we have some estimate of how many notifications will be added? you can basically assume each ip edit currently translates to a new user (worst case scenario). My query for edits done by ips in enwiki gives roughly .7M edits a month:

MariaDB [enwiki_p]> select count(*) from recentchanges join actor on rc_actor = actor_id where rc_source = 'mw.edit' and actor_user is null;
+----------+
| count(*) |
+----------+
|   673782 |
+----------+
1 row in set (35,075 sec)

If you double the number (enwiki is basically half of the traffic, it's a good rough estimate to get the global number). You'd get 1.4M edits/users a month. That dwarfs in comparison with T308084: Reduce DB space used by Echo notifications (last time I measured it was around 100M unneeded notification being sent every year) so I highly recommend doing it regardless and don't worry about its impact on x1 (and generally x1 is in rather healthy state).

I personally think we shouldn't enable a lot of echo features for temp users for the sake of usefulness but database-wise I wouldn't worry about it.

In T330509#8650501, @Ladsgroup wrote:

Do we have some estimate of how many notifications will be added? you can basically assume each ip edit currently translates to a new user (worst case scenario). My query for edits done by ips in enwiki gives roughly .7M edits a month:

MariaDB [enwiki_p]> select count(*) from recentchanges join actor on rc_actor = actor_id where rc_source = 'mw.edit' and actor_user is null;
+----------+
| count(*) |
+----------+
|   673782 |
+----------+
1 row in set (35,075 sec)

If you double the number (enwiki is basically half of the traffic, it's a good rough estimate to get the global number). You'd get 1.4M edits/users a month. That dwarfs in comparison with T308084: Reduce DB space used by Echo notifications (last time I measured it was around 100M unneeded notification being sent every year) so I highly recommend doing it regardless and don't worry about its impact on x1 (and generally x1 is in rather healthy state).

I personally think we shouldn't enable a lot of echo features for temp users for the sake of usefulness but database-wise I wouldn't worry about it.

Ack, thanks for checking that.

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

FWIW, Special:Preferences is in core (not Echo) but it shouldn't be enabled for temp users for database reasons, user_properties table is quite large (T54777)

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?

Yes, That's core.

Change 891860 abandoned by Jdlrobson:

[mediawiki/extensions/Echo@master] IP masking: Disable Echo for temporary users

Reason:

See discussion on ticket. Feel free to restore if this is needed.

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

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

Should we close this as a duplicate of T58828, in order to have a single place for discussion? (And maybe T58828 should be renamed to reference temporary users specifically.)

In T330509#8686997, @kostajh wrote:

Should we close this as a duplicate of T58828, in order to have a single place for discussion? (And maybe T58828 should be renamed to reference temporary users specifically.)

OTOH, if we are saying we want to do this for Temp users only as different from IP editors, should we keep this ticket open and leave T58828 alone? Since IP editors will continue to exist for many wikis whilst IP masking is being rolled out.

In T330509#8691929, @RHo wrote:

In T330509#8686997, @kostajh wrote:

Should we close this as a duplicate of T58828, in order to have a single place for discussion? (And maybe T58828 should be renamed to reference temporary users specifically.)

OTOH, if we are saying we want to do this for Temp users only as different from IP editors, should we keep this ticket open and leave T58828 alone? Since IP editors will continue to exist for many wikis whilst IP masking is being rolled out.

+1 to this suggestion. I renamed this task to make it clearer.

In T331058: Make Special:Mute only usable for named users we're discussing whether it should be possible to mute temporary users via Echo.

After discussion with @Niharika , the proposal is that we don't allow this, since we don't allow muting IP users. We've therefore been asked to disable muting temporary users on Special:Mute and via Special:Preferences (which will involve us updating the Echo hook that provides that preference). Once we do that work, Special:Preferences will be out of sync with the Echo API, which will still allow muting temporary users.

What are Growth-Team's views on muting temporary users?

It would be hugely beneficial for Apps users to get notifications, even when (especially?) using a temporary account. One of our long-standing pain points has been reaching out to anonymous users when there's a problem, e.g. their edit was reverted. Currently we use a few hacky workarounds to show an IP editor an alert if there's a message on their talk page (basically the equivalent of the Orange Bar). But if we're suddenly able to leverage Echo to send that user a proper push notification, that would be a big win.

Could there be some sort of compromise where we disable access to the Special:Preferences page, but keep the actual preferences settable via API, so that Echo notifications could be enabled programmatically? Or are there deeper reasons that Echo itself won't work with temporary accounts?

In T330509#8739183, @Tchanders wrote:

In T331058: Make Special:Mute only usable for named users we're discussing whether it should be possible to mute temporary users via Echo.

After discussion with @Niharika , the proposal is that we don't allow this, since we don't allow muting IP users. We've therefore been asked to disable muting temporary users on Special:Mute and via Special:Preferences (which will involve us updating the Echo hook that provides that preference). Once we do that work, Special:Preferences will be out of sync with the Echo API, which will still allow muting temporary users.

What are Growth-Team's views on muting temporary users?

I updated the task description to confirm that Echo will be made available to temp accounts, thought temp acc users will have no access to Special:Preferences. Bumping the above question about muting for @kostajh or perhaps @Tgr to weigh in .

In T330509#8740160, @RHo wrote:

In T330509#8739183, @Tchanders wrote:

What are Growth-Team's views on muting temporary users?

I updated the task description to confirm that Echo will be made available to temp accounts, thought temp acc users will have no access to Special:Preferences. Bumping the above question about muting for @kostajh or perhaps @Tgr to weigh in .

This is more of a product question; the engineering angle is well-covered by @Tchanders' comments in T331058#8708983 and T331058#8718662.

Personally I'd allow muting temporary users because there doesn't seem to be a clear product rationale not to, it's the minimum-effort approach and this is an MVP, and in the long term we'll probably want to treat temp users like named users (with access to preferences etc) which includes muteability. But denying muting temp users doesn't seem hard either (we'd have to do T332030: Update user name widgets config to accept or deny temporary user names, use it in the Special:Preferences form field, and add an extra error condition to the relevant Echo APIs).

In T330509#8739736, @Dbrant wrote:

It would be hugely beneficial for Apps users to get notifications, even when (especially?) using a temporary account. One of our long-standing pain points has been reaching out to anonymous users when there's a problem, e.g. their edit was reverted. Currently we use a few hacky workarounds to show an IP editor an alert if there's a message on their talk page (basically the equivalent of the Orange Bar). But if we're suddenly able to leverage Echo to send that user a proper push notification, that would be a big win.

👍🏻

Could there be some sort of compromise where we disable access to the Special:Preferences page, but keep the actual preferences settable via API, so that Echo notifications could be enabled programmatically? Or are there deeper reasons that Echo itself won't work with temporary accounts?

Hmm, that sounds like it might be complicated. As an alternative, could the iOS/Android apps use some local preferences hack, so if a temporary user wants to disable a particular type of notification, you keep track of that in the application's storage, and filter those out from the notifications that the user receives? Or does that not work easily with the push notification architecture? A non-technical solution would be something like "To adjust notification preferences, create an account" in the page of the app where you let users adjust their notification preferences.

In T330509#8740889, @Tgr wrote:

In T330509#8740160, @RHo wrote:

In T330509#8739183, @Tchanders wrote:

What are Growth-Team's views on muting temporary users?

I updated the task description to confirm that Echo will be made available to temp accounts, thought temp acc users will have no access to Special:Preferences. Bumping the above question about muting for @kostajh or perhaps @Tgr to weigh in .

This is more of a product question; the engineering angle is well-covered by @Tchanders' comments in T331058#8708983 and T331058#8718662.

Personally I'd allow muting temporary users because there doesn't seem to be a clear product rationale not to, it's the minimum-effort approach and this is an MVP, and in the long term we'll probably want to treat temp users like named users (with access to preferences etc) which includes muteability. But denying muting temp users doesn't seem hard either (we'd have to do T332030: Update user name widgets config to accept or deny temporary user names, use it in the Special:Preferences form field, and add an extra error condition to the relevant Echo APIs).

Just to clarify, are we talking about registered users being allowed to mute temporary users? Or temporary users being able to use the "mute" feature to mute other temporary or registered users?

Allowing registered users to mute temporary users doesn't seem hard. Allowing temporary users to use the "mute" feature doesn't seem easy given we are blocking access to preferences via Special:Preferences and the options save API.

In T330509#8740889, @Tgr wrote:

In T330509#8740160, @RHo wrote:

In T330509#8739183, @Tchanders wrote:

What are Growth-Team's views on muting temporary users?

I updated the task description to confirm that Echo will be made available to temp accounts, thought temp acc users will have no access to Special:Preferences. Bumping the above question about muting for @kostajh or perhaps @Tgr to weigh in .

This is more of a product question; the engineering angle is well-covered by @Tchanders' comments in T331058#8708983 and T331058#8718662.
Personally I'd allow muting temporary users because there doesn't seem to be a clear product rationale not to, it's the minimum-effort approach and this is an MVP, and in the long term we'll probably want to treat temp users like named users (with access to preferences etc) which includes muteability. But denying muting temp users doesn't seem hard either (we'd have to do T332030: Update user name widgets config to accept or deny temporary user names, use it in the Special:Preferences form field, and add an extra error condition to the relevant Echo APIs).

Adding in @KStoller-WMF for Product view. My take is also that it seems fine to allow muting of temp accounts since it probably doesn't make a difference in practice, as temp accounts are being given access to Echo notifications for receiving notifications and would not be able to access Special:Preferences to mute others. In the seemingly edge case that a user would want to mute a temp account, is there any harm in allowing this to happen?

Just to clarify, are we talking about registered users being allowed to mute temporary users? Or temporary users being able to use the "mute" feature to mute other temporary or registered users?

The first one: registered users being allowed to mute temporary users.

Muting temporary users works by default, but it was disabled for Special:Mute after this conversation with @Niharika: T331058#8711438

If we keep allowing it via Echo, I think we should allow it again for Special:Mute, since they should be consistent.

Change 897854 merged by jenkins-bot:

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

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

I think this can move to QA, correct?

Testing Echo notifications for temp users was done (and summarized) in T341839: [QA task] IP masking - temp users testing in production and in T333531: Temporary users should have default notification preferences. The scope of this task has been QAed, the results have been captured in the aforementioned tasks.
I tentatively move the task to Test in Production since the tasks in the descriptions are still open.