Create Android screens for scenarios called out in general IP masking deck
Create iOS screens for scenarios called out in general IP Masking deck

I want to flag that the general IP Masking deck is not comprehensive. There are many more places where IP addresses show up and need to be replaced with temporary usernames. I don't have a full inventory of it. I would suggest that the apps teams conduct their own audit of where IP addresses are exposed through the apps.
I also want to flag that we will allow privileged users to retain access to IP addresses for patrolling purposes. Detail in T325238: [Epic] IP Address Reveal for Privileged Users.
For desktop and mobile web, we have designed a "Reveal" workflow for privileged editors to unmask IP addresses that they need access to. I imagine something similar would be needed for mobile? @Tchanders can maybe shed more light on how we are doing this for desktop and if that can help apps replicate the functionality easily.
Happy to talk this through in a meeting too.

Thanks @Niharika , We do have this deck from Prateek that is an audit of the apps. I'll ask @OTichonova to double check that it is exhaustive. @Dbrant is our technical point of contact for IP Masking on the apps, so pinging him here to read the comment above and decide if he should circle up with Thal again

A few random comments on some of the bullet points:

• How will we handle reading list account association after a user has made an edit without creating an account / how will temp account expiration affect this? What do we need to update when someone creates an account after previously having a temp account and saving articles?

We can handle this just like we do today with anonymous users. If you never create an account, you're still allowed to build a collection of reading lists locally inside the app; then once you create an account, those lists will be synced to your account. So we can now go on to say: you can start building reading lists if you're anonymous OR a temporary user, and then if you create a permanent account, your lists will be synced.

• How will we handle notice of temp account expiration in the apps?

We have access to the cookie that contains the expiry date of the temp account, so we would be able to show a message that notifies the user that their temp account will expire soon. But then, if the temp account expires, and they make another edit, they'll just get a new temp account. So I'm not sure how prominent this warning should actually be, especially considering that the account will last for a year, and we will surely show the user many other prompts and nudges along the way to create a permanent account. Also remember that nothing from the temp account gets "transferred over" to a permanent account (e.g. contribution history), so the only thing that would be "lost" is the user's ability to make edits under that temp account name.

• Notifications?

It's sounding like (T333531) notifications will be enabled in their default state for temp users, which is good for us because it means it should Just Work. The only outstanding question is whether push notifications will work, but I believe this can only be tested/answered when this is deployed to testwiki.

• Watchlist

Conversely, it's sounding like Watchlist functionality will be disabled for temp accounts on the server side, so this will need to be hidden from temp users.

• Contributions page

This need not be any different from what we have currently for logged-in users, except the user name will be the temp account. All the functionality can be the same.

@Dbrant thanks so much for reading through these!

We can handle this just like we do today with anonymous users. If you never create an account, you're still allowed to build a collection of reading lists locally inside the app; then once you create an account, those lists will be synced to your account. So we can now go on to say: you can start building reading lists if you're anonymous OR a temporary user, and then if you create a permanent account, your lists will be synced.

Perfect, thanks! I'll remove the bullet point

Conversely, it's sounding like Watchlist functionality will be disabled for temp accounts on the server side, so this will need to be hidden from temp users.

Great, I'll remove this from the bullet points but be sure to document that the feature should be hidden for temp accounts

This need not be any different from what we have currently for logged-in users, except the user name will be the temp account. All the functionality can be the same.

Just double checking though, when their temp account expires and a new temp account is made, their contributions stats will reset?

In T333473#8860612, @cmadeo wrote:

Just double checking though, when their temp account expires and a new temp account is made, their contributions stats will reset?

That's right - since they'll now be logged into a new account, their stats will reset.
And again, if they create a permanent account after making edits with a temp account, their stats will also reset.

Thanks for the clarifications @Dbrant !

We will prob also need to think about what people see for syncing reading lists right? @cmadeo @Dbrant

Huge thank you's to @OTichonova and @scblr for their input on mock ups and for updating with correct components!