Page MenuHomePhabricator

Prompt user to create a regular account after temp account creation rate limit trip
Open, Needs TriagePublic

Assigned To
None
Authored By
AAlhazwani-WMF
Nov 18 2025, 11:30 AM
Referenced Files
F70274217: image.png
Nov 18 2025, 11:32 AM
F70274175: Arc 2025-11-18 12.03.11.png
Nov 18 2025, 11:32 AM
F70274170: Arc 2025-11-18 12.03.09.png
Nov 18 2025, 11:32 AM
F70274178: image.png
Nov 18 2025, 11:32 AM
F70274149: Group 3.png
Nov 18 2025, 11:31 AM
F70274152: Group 2.png
Nov 18 2025, 11:31 AM
F70274381: image.png
Nov 18 2025, 11:30 AM

Description

User story & summary:

as a logged-out editor from an IP address that has hit the temp account creation rate limit, i want to be prompted to create a regular account or log in before i invest time editing so that i can successfully publish my changes without losing my work.

Background & research:

when this limit is hit, users cannot publish their edits via temp accounts, which creates a dead-end if we don't intervene early.

right now, the system allows users to edit, which means they may invest significant time making changes only to discover at publish time that they cannot proceed without creating a regular account. this creates frustration at a critical conversion moment.

additionally, the current implementation shows competing messages simultaneously (rate limit warnings alongside BLP notices and other article-specific communications), which creates visual clutter and makes it difficult for users to understand what action they need to take.

Design:

we suggest to introduce a modal that appears when the rate limit is hit, so that we can:

  • create a stronger separation of concerns between user-relevant authentication information and article-relevant notices
  • prevent users from investing time in edits they cannot publish
  • provide a clear path forward (create account or log in) at the moment when it's most actionable
  • reduce frustration by setting expectations upfront

design specs https://www.figma.com/design/3irzISNEYik483LXUreJf5/T357802-prompt-user-to-create-a-regular-account-after-temp-account-rate-limit?node-id=155-1662&t=UdQJcvyNvEuZHWkZ-1

image.png (1×750 px, 301 KB)

Acceptance Criteria:

Given a logged-out user from an IP address that has already created 6 temp accounts in the past 24 hours
When they click edit on an article
Then the system checks whether their IP has hit the temp account creation rate limit before loading the editor

Given a user has dismissed or bypassed the initial rate limit modal (if we implement the "show twice" approach)
When they attempt to publish their edit
Then the modal appears again before the publish dialog, preventing them from proceeding without creating an account or logging in

Open questions:
  • Should we should the modal once or twice?
  • Should we disclose additional information inside as an accordion or styled as caption and visible at all times?

Event Timeline

Should we should the modal once or twice?

we thought of two approaches where we present this modal potentially once (before the publish dialog) or twice (after the editor opens, and before the publish dialog).

show it once

Group 2.png (1×2 px, 636 KB)

show it twice

Group 3.png (1×3 px, 870 KB)

we can make a final decision on this during implementation to test this in a real environment. at the time of writing we're leaning towards showing the modal twice so that people are aware before they invest time in editing, but we still give them the ability to edit if they want to then save their changes somewhere else or if they are simply testing things out.

Should we disclose additional information inside as an accordion or styled as caption and visible at all times?

With accordionWithout accordion
image.png (1×750 px, 298 KB)
Arc 2025-11-18 12.03.09.png (1×750 px, 298 KB)
Arc 2025-11-18 12.03.11.png (1×750 px, 301 KB)

while making this decision we should keep in mind that english is usually much more concise compared to other languages like greek or malayalam (text has been translated with google translate, so take it with a grain of salt)

image.png (1×2 px, 772 KB)

Switching to my volunteer Steward Liason role: We should be extra careful here before we make it happen. Assuming the rate limit between named and temporary accounts is not shared, switching to regular accounts when temporary ones are exhausted (or vice-versa) is the quickest way to bypass Six Account Limit (and make it a Twelve-Account-Limit instead). I'm not 100% sure how to account for this, but we should consider this risk and incorporate it into the decisions we make here.

CC @EMill-WMF @Tchanders, as I'm fairly certain enwiki would consider this extra risk for their usage as well (that said, I'm not an enwiki user, so...).

Hope this makes sense!

Switching to my volunteer Steward Liason role: We should be extra careful here before we make it happen. Assuming the rate limit between named and temporary accounts is not shared, switching to regular accounts when temporary ones are exhausted (or vice-versa) is the quickest way to bypass Six Account Limit (and make it a Twelve-Account-Limit instead). I'm not 100% sure how to account for this, but we should consider this risk and incorporate it into the decisions we make here.

CC @EMill-WMF @Tchanders, as I'm fairly certain enwiki would consider this extra risk for their usage as well (that said, I'm not an enwiki user, so...).

Hope this makes sense!

This makes sense, I see what you're saying in terms of encouraging vandals to just switch to registered accounts. It is an option they already have available to them, but perhaps this would inspire more of them to do it.

However, I think we should accept this risk, especially since we are otherwise about to tighten the daily rate limit for temporary accounts even further, making it more important that we provide an easy avenue for users who hit this limit. I would prefer to see us try this and see if we observe any noticeable shifts in abusive temporary account behavior, though even then we would also need to weigh it against what we observe in terms of good-faith usage of this feature leading to more edits from registered accounts in the system.

@Urbanecm Please do feel welcome to discuss this further, here or elsewhere, if you think we're missing something here or have other concerns.