Erase a person

Erasing a person answers a request to be forgotten. It is permanent, it is recorded with the reason you give, and only an owner or administrator can do it.

You start an erasure in the Console: open Privacy (/privacy), stay on the Requests tab, and find the person first. See Erase in the Console and the Console guide. Your agent can start the same erasure with the MCP tool or the CLI command in the sections below. The erasure always needs a reason and a confirmation, so a person decides.

What it removes

Read this before you tell someone their data is gone. The two lists below are complete: everything the platform stores about a person is in one of them.

Removed:

• the person's profile: every property your identify() calls attached, such as email, name and plan, and the history of those properties;
• the person's identity: the person record and every identifier linked to it, including the anonymous ones from before they signed in. What was recorded about them while they were still an anonymous visitor (a cohort membership, a survey they were shown or answered, a result that counted them, an agent session replay) is removed with the rest, once an identify() call has linked that visitor to them;
• the person's product events: every event captured under any of those identifiers, such as page views and the custom events you send;
• the person's errors, logs, traces and agent events: every error occurrence, log line, span and agent event that was recorded under any of those identifiers;
• what their log lines added to a log-based metric: the metric's values are calculated again without them, in the background, shortly after the erasure;
• the person's session recordings: every recording made under any of those identifiers, with all of its stored content. A screenshot attached to a problem report is part of the recording and goes with it;
• the masked page copies their browser captured for a heatmap. A copy holds your page's structure and no identifier of the visitor; it is removed because their browser produced it. A copy of the same page captured by another visitor's browser stays;
• the diagnostic capture requests made for the person, and the problem reports they submitted;
• the recorded agent session replays made from the person's agent sessions, with the text they hold;
• the person's account memberships: they are removed from every account (group) they belonged to, with the history of when they joined, left or moved. The account itself, its properties and its other members are not touched;
• the person's cohort memberships: they are removed from every cohort, including the earlier versions of a cohort's member list that are kept as history, and each member count is lowered to match;
• the person's experiment assignments, with the exposure and the outcomes recorded for them;
• the person's survey records: which surveys they were offered, shown, answered or dismissed. Their answers are product events and go with the rest of their events, and each survey's count of accepted responses is lowered by the responses they gave;
• the person's rows in results you have already measured, and the results themselves: a result that counted them, or that covered a time they were active and could have, is withdrawn. See Results that counted the person;
• the person's agent runs, whole, with the quality scores, the written explanations and the review notes about those runs. See Agent runs;
• an agent run of theirs that you promoted into an evaluation dataset. The frozen copy is deleted, and every dataset version that held it is retired. See Evaluation datasets that held their run;
• saved findings that reference them, or exactly name an identifier or name Anectico holds for them in a revision's title, conclusion or a measurement's name, unit, population or named read, including previous values still held in profile history. Their whole revision lineage is withdrawn and its content is deleted. Matching ignores case and normalizes Unicode, uses whole-token boundaries, and needs at least four letters or digits. A nickname, description, shorter name or original value of a redacted email is not matched; see Saved findings;
• matching text in every coverage declaration revision and fix declaration note becomes [withheld by erasure]. Reads say which content changed. A redacted coverage comparison key is withheld by erasure, never declared but not observed. Redacting a note does not change comparison or outcome counts. Shared declaration text stays out of person exports. The same held-name matching limits as saved findings apply. Software release/environment identifiers are not searched as prose;
• every archive made by exporting the person's data that is still stored, with the record of the export. A copy somebody already downloaded is theirs to delete.

Events and telemetry disappear from every chart, list, search and query first, and are then deleted from storage. A recording stops being listed and playable when its stored content has been deleted.

Which recordings are the person's. A recording belongs to a person when it was made under one of their identifiers. A recording that started before the visitor signed in was made under their anonymous identifier, and is removed when that identifier is linked to the person, which an identify() call does. A recording that carries no identifier at all, or only one that was never linked to the person, is not found. See "Not removed" below.

What "recorded under an identifier" means for telemetry. An error, a log line or a span belongs to a person when it carries one of their identifiers as its anectico.distinct_id attribute (the SDKs set it on everything they send). Those are the rows that are removed.

• A trace that is theirs alone is removed whole. See Agent runs.
• A trace that also names somebody else is removed span by span. Spans that carry the erased identifier go; every other span of it stays, including the spans that carry no identifier.
• An error group (the Issue) is not removed: it describes a kind of failure that other people may also have hit. Its counts no longer include the erased person.
• A row that carries no identifier is not found, even if it mentions the person some other way. See "Not removed" below.

Agent runs

An agent run is one trace. Only some of its spans carry the person's identifier: usually the one your application starts the run with. The spans underneath it (the model calls, the tool calls) usually carry none, and they are where the prompt and the answer are recorded.

A run is removed whole when it is theirs alone: at least one of its spans carries an identifier, and every span that carries one carries one of the erased person's. Then every span, agent event, log line and error of that run is removed, the ones that carry no identifier included. A session or a turn is treated the same way: when everything recorded under its key that names anyone names only the erased person, the runs of that session that name nobody go with it.

A run that also names somebody else is not removed whole. It is that person's run too. Only the spans, events, log lines and errors that carry the erased person's identifier are removed, and the rest of the run stays, including its spans that carry no identifier. If your agents serve two people in one run, erase both people to remove it.

The spans that carry the identifier disappear from every list and search at once. The rest of the run is deleted a few minutes later, with them, and can still be opened until then.

A run that is still in progress when you erase the person is removed when it ends. The span that carries the identifier is usually the last one your application sends. It is not stored, and the spans of that run that were stored before it, which carry no identifier, are then removed the same way, a few minutes after it arrives. Until it arrives nothing says whose those spans are, so they can still be opened; a run whose identifying span is never sent is not removed.

Quality scores, their written explanations and review notes about a run that was removed whole are removed with it, for the run itself and for its steps, session and turn. A score that was still on its way to being stored is discarded. A reviewer cannot add a note to the run afterwards: it is answered as a run that does not exist.

Evaluation datasets that held their run

A dataset item is a frozen copy of a run as it was when a reviewer promoted it, and that copy includes the identifier the run was recorded under and the run's content. When the run was the erased person's, the item is deleted from every version of every dataset that holds it, together with the review note that promoted it.

A dataset version is a fixed set of cases, so a version that lost a case is not the version anyone measured against. It is retired:

• it is listed with the state DATASET_VERSION_STATE_RETIRED, the cause DATASET_VERSION_RETIREMENT_CAUSE_PERSON_ERASED and the time. Its item count and content digest still describe the set as it was frozen;
• its cases can no longer be listed or replayed, and no experiment can be created over it;
• an experiment that was run over it is invalidated (EXPERIMENT_STATE_INVALIDATED, cause EXPERIMENT_INVALIDATION_CAUSE_PERSON_ERASED). It cannot be run, extended or compared, and a release gate that reads it does not evaluate. Do not cite the numbers it produced: they were measured over a set that no longer exists;
• every one of those calls is refused with the reason EVALUATION_DATASET_VERSION_RETIRED. The refusal is permanent; retrying does not help.

A version that did not hold their run is untouched, and so are the experiments over it, with one exception.

An experiment that scored one of their live runs is invalidated too. A trial can name a live run to score in place of the case's frozen copy. When that run was the erased person's, the score and its written explanation were computed from their run, whatever case the trial belongs to. They are removed, and the experiment is invalidated with the same state and cause, even though its dataset version is not retired: a comparison that lost one of its pairs is not the comparison you declared. It cannot be run, extended or compared, and a release gate that reads it does not evaluate; the calls are refused with the same reason. Create a new experiment over the same dataset version. The other trials' scores are kept, and a trial can no longer name that run.

To use the dataset again, cut a new version. Promote a run into the dataset, or remove a case from it; either produces a new version from the cases that are left. If you want exactly the remaining cases and nothing else changed, remove with an empty list of cases (anectico evals datasets remove <dataset> --yes with the body {"item_ids": []}), which is accepted only for a dataset whose current version is retired. Then create a new experiment over the new version. A dataset whose only case was the erased person's run needs a run promoted into it.

A release-gate verdict that was already recorded stays as it was written: it holds a decision and statistics, and names no run.

Action receipts that name them

An action receipt is an entry in a tamper-evident ledger: each entry is sealed together with the one before it. A checkpoint you keep independently detects changes to the history it covers. The platform removes old entries from the front under a signed retention statement; the check then covers the entries that remain. A receipt can say who an action was about: in its distinct_id, in its subject_refs, or as the subject of one of its resources.

Erasing the person removes what such an entry said about them, and keeps the entry:

• the entry's distinct_id, subject_refs, purpose, resource_uris, session and turn, and the three digests the recorder sent with it (arguments_sha256, intent_sha256, idempotency_key_sha256) are deleted. All nine go together, for every entry that names the person. That includes the receipts of actions your own staff took about the person through this platform, such as an earlier export of their data or an erasure that failed;
• the entry itself stays in its place, with its sequence number, its time, the action and tool it records, and who performed, requested and approved it. Those are your staff, credentials and agents, not the person the action was about, and they are the reason the ledger exists;
• the ledger still verifies, and a checkpoint you retained before the erasure still matches. An entry holds a fingerprint of each of those values that can only be checked against the value while a per-entry secret exists. The erasure deletes that secret with the values, after which the fingerprint cannot be matched to the person even by someone who guesses their identifier;
• verify_receipt_chain counts such entries in redacted_entry_count, and a receipt read lists the withheld fields in redacted_fields. An erased purpose is reported as withheld, not as an empty purpose;
• the erasure adds one or more statements to each affected ledger. They name the erasure operation and the positions of the entries they removed values from, and nobody. That is what lets the check tell an entry emptied by an erasure from one that was emptied some other way;
• the erasure waits for the searchable copy of those values to be verified absent. Already-published messages may hold values until they expire. Remembered digests and backups remain as described below.

Blocked from now on:

• every one of those identifiers is permanently blocked. An event, an error, a log line or a span sent later under one of them is dropped when it arrives: it is not stored and it never recreates the person. That includes an identify() or a group call that mentions a blocked identifier, so a blocked identifier is never added to an account again;
• a recording upload under one of those identifiers, or for a session whose recording was erased, stores nothing. Neither does a problem report submitted under one. Both are accepted and discarded, exactly like an event: your page gets the answer it gets for anyone else;
• a survey is never offered to one of those identifiers again, and a display, a response or a dismissal sent under one is answered as it is for any visitor the survey was not offered to (SURVEY_NOT_OFFERED), and records nothing;
• a new diagnostic capture request for one of those identifiers, which you make with your own credentials, is refused and says the identity was erased;
• the person cannot be added to a cohort or assigned to an experiment again. A request that still names them, because it looked them up a moment before the erasure, is refused or answered as it would be for someone unknown;
• an action receipt recorded later that names one of those identifiers is accepted, because the action it records did happen, and is stored without the nine values above. The answer to the request says so (redacted: true), and the entry itself records that it was stored that way.

Why your page is not told. The calls a visitor's browser or app makes (events, recordings, problem reports, survey displays and answers) use a key that is in your page for anyone to read. If those calls answered "this identifier was erased", anyone holding the key could ask, for any identifier, whether its owner had asked to be forgotten. So they answer the same way for an erased identifier as for any other, and store nothing. Calls made with your own credentials, such as a diagnostic capture request or an account membership change, do say that the identity was erased.

Not removed:

• Session recordings that carry none of their identifiers. A recording made with no identifier, or under an anonymous identifier that was never linked to the person, cannot be told apart from anyone else's. Delete such a recording from the recording itself.
• Errors, logs and spans that carry no identifier and name the person only through an email address or a user id your code attached (for example enduser.email or enduser.id). The erasure works from the person's identifiers and does not search other fields.
• An action receipt that mentions them only in free text. The erasure finds a receipt by the identifier in its distinct_id, in its subject_refs, and by a subject parameter in one of its resource URIs. A receipt that carries none of these, and mentions the person only inside the wording of its purpose, inside another part of a resource URI, or through a session or turn of theirs, is not found and is kept as it was written. So is one whose recorder put the identifier in its action_id. The receipts this platform writes itself do not do either.
• The people and credentials a receipt names as having acted. If the erased person is also someone who performed, requested or approved an action in your organization, receipts still name them in that role.
• The rest of an agent run that also names somebody else. A run on which another person's identifier appears is theirs too, so only the parts that carry the erased identifier are removed. See Agent runs.
• The other cases of a retired dataset version. They are kept, and are not listed or used, until you delete the dataset. Cutting a new version carries them forward.
• A release-gate verdict recorded before the erasure, as described above.
• A log-based metric's contribution from a log line that had already expired. The metric is recalculated from the person's stored log lines. A log line that had already passed your data retention when you erased the person can no longer be traced to them.
• Records of something you did to this person's data earlier. If, before erasing the person, you erased their recorded model and tool content or deleted their error occurrences, the record of that earlier action still names the identifier it was done for, and so does its entry in your audit log. These are the proof that those actions happened.
• Files an export already wrote to your own storage. Those are yours to remove.

The operation reporting Complete means everything under "Removed" above is gone. The items in this list are not removed by it at any point.

Erasing one person's error occurrences on an Issue, or with anectico persons erase-errors, still exists as a separate, narrower action: it hides and removes a person's errors without erasing the person, and keeps hiding errors recorded for them later. Erasing the person afterwards removes their errors as described above; the record that the earlier action happened is kept, as listed under "Not removed".

For anything else, write to privacy@anectico.com.

How long it takes

• The profile and identity are removed, and the identifiers blocked, before the request returns.
• The person's product events, errors, logs, traces and agent events stop appearing in every read within a few seconds, usually under a minute.
• Their diagnostic requests, problem reports, agent session replays and account memberships are removed within a few seconds. An account's member list stops showing them at once; analytics by account stops counting them a few seconds later.
• Their recordings are removed one by one, each as soon as its stored content is deleted; that is usually seconds, and longer for a person with many long recordings.
• Their cohort memberships, experiment assignments and survey records are removed within a few seconds, and the experiments and the results that list them among their people are withdrawn at the same time. A result that does not list its people, such as a trend total, is withdrawn a few minutes later, once the person's events are confirmed removed; if you open its people before then, it is withdrawn on the spot.
• The operation reports Complete a few minutes after the request. It waits about two minutes on purpose, so that anything that was already on its way in when you asked is removed too, and then confirms nothing is left in storage. A person with thousands of identifiers, or a busy system, takes longer. Until then the state is Pending and each part shows whether it has finished.

During the first few seconds an event or a piece of telemetry sent under one of the identifiers can still be accepted. It is hidden at once and removed with the rest before the operation completes.

What else stays

• The record of the erasure. Who asked, when, and the reason. It holds how many identifiers the person had, not what they were.
• Finding match fingerprints. The held-value snapshot is read completely before the person is deleted. A snapshot exceeding 2 MiB or 10,100 distinct history values, or a history read exceeding two seconds, refuses the erasure before deletion; a partial snapshot never completes it. A Unicode-normalized size limit also refuses the request, instead of silently dropping held terms. The erasure record keeps randomly salted fingerprints of held identifiers and names, with scan progress, until the project or workspace is deleted. No new copy of the name or identifier is stored. These fingerprints are private and excluded from APIs, agent tools and person exports; a privileged holder can test a guessed value against them.
• Your audit log. The erasure appears there under its operation id, without the person's identifiers. Entries written earlier by other actions on that person are not rewritten.
• What keeps the identifiers blocked. A blocked identifier is kept as a one-way fingerprint, which someone who guesses an identifier can confirm by computing the same fingerprint. It is not shown by any screen, API, export or agent tool. While the erasure is running, the identifiers are also held in the platform's own work records; those are deleted when the operation completes.
• Receipt messages and retry digests. Already-published receipt messages can contain values until the normal message retention period expires. For a receipt recorded after its subject was blocked, the digest used to recognise a retry remains for seven days; a guessed input can be confirmed against it. The remembered positions of redacted entries remain to refuse late writes.
• The internal notice of the erasure. The message that tells each part of the platform which identifiers to remove is kept for the platform's normal message retention period and then discarded.
• A malformed record that arrives afterwards. Data the platform cannot read at all is set aside for up to seven days so the fault can be diagnosed, and then discarded. Any such record that names one of the identifiers is cleared when the erasure runs. One that arrives after the erasure has completed is kept for those seven days; it is never stored as the person's data and never shown.
• Backups. A backup taken before the erasure still contains the person's data until the backup expires. Restores of telemetry and recording copies reapply recorded erasures before serving them. Restoring older identity, operation or receipt records is not yet covered by automatic replay.

Effect on product analytics

Counts no longer include the erased person, and results over the hours they were active stay complete: the platform records that those events were removed on purpose, so it does not report them as still on their way. For a minute or two while the erasure runs, a result over those hours can show its coverage as catching up.

Results that counted the person

A result you measured before the erasure is not recalculated. It is withdrawn and stops answering, in one of two ways:

• A result that lists the people behind it is withdrawn if the erased person is one of them, and their rows are deleted from it. Funnels, retention, paths, engagement, web, revenue, heatmap and survey results always list their people, and so does a trend once you have opened its people or filtered it by a person property. A result that lists its people and does not include the erased person is left alone, whatever time it covers.
• A result that does not list people is withdrawn if it could have counted them. A trend total nobody opened is measured without a list of people, and a result that counts accounts lists accounts, not the people in them, so nothing says who was counted. Such a result is withdrawn when the time it measured includes an hour in which the erased person had at least one product event. The time it measured means its range and its comparison range, plus any time the measurement reads beyond them, such as a funnel's conversion window. If the result is limited to one environment, only the person's events in that environment count.

A result that could not have counted them is not withdrawn: one in another project, one limited to an environment the person never had events in, and one over a time they had no events in. The check is by hour, on the clock rather than the calendar: a result that ends exactly when the hour starts did not measure that hour. It does not look at which events the result measured, so a trend of one event is withdrawn for an hour in which the person sent only a different one. It errs on the side of withdrawing.

• On the result's proof page the result shows Measurement withdrawn, and a panel on a live screen shows Withdrawn. Measure again: the new result does not count them.
• Through the API, an agent or the command line, the result's status is PRODUCT_RESULT_STATUS_INVALIDATED with no numbers, and reading its people, its evidence or an export of it is refused with details.reason: "ANALYTICS_RESULT_INVALIDATED" and a message that names the cause, person_erased. There is nothing to retry: run the query again.
• A saved insight, a dashboard widget, a scheduled report and a metric watch all measure again the next time they run, so they need nothing from you. A widget or an insight that is showing a withdrawn measurement says so, and never shows its old numbers. A metric watch's history shows the past run that used a withdrawn result as unavailable, never as its old number, and its next evaluation runs normally.
• An audience you saved from a result's people is withdrawn if the person was in it, the way an expired audience is, because it is a fixed list taken from that result. A flag, a survey or an experiment that targets that audience stops matching it. Save the audience again from a new measurement.
• A product experiment that had exposed the person is invalidated, with reason PERSON_ERASED, whether it is still running or already finished: its result counted someone who is no longer there. An experiment that had only assigned them, and never shown them anything, carries on.

One narrow case is not covered. Events are kept for a retention period and are no longer readable after it. If one of the person's events had already passed that period when you erased them, the hour it was in is not used to withdraw a result, although a result measured just before the event expired could have counted it. Such a result expires within an hour of being measured unless your deployment keeps results longer (a day at most).

A returning user needs a new identity

Blocking is by identifier. If someone you erased uses your product again, give them a fresh identity: call the SDK's reset() before identifying them, or identify them under a new id. An identify() that mentions an erased identifier, either as the user id or as the previous anonymous id, is ignored entirely.

Erase in the Console

1. In the Console, open Privacy (/privacy) and stay on the Requests tab.
2. In the A person card, enter the person's id or any one of their identifiers, then choose Find person. The page looks the person up first, and the erase control appears only for a person it finds. It is shown only to someone who is allowed to erase people.
3. Choose Erase this person and enter the reason. It is stored with the operation, so do not put the person's email or other identifiers in it; a ticket or request number is enough.
4. Type erase to confirm, then choose Erase permanently.

The result shows the operation id. The same tab lists every person erasure in the project with its state and what each part of the platform reports. The Console erases only a person it finds; an identifier that was never linked to a person can be erased from the command line, an agent or the API.

Erase from the command line

anectico persons erase user@example.com --reason "Request 4192" --yes

The argument is the person's id or any one of their identifiers; every identifier of that person is erased. It is matched exactly as you type it, including upper and lower case and any space at the start or end (quote it in your shell if it has one). The command prints an operation id before it sends the request. If the request is interrupted, run it again with --operation-id <that id>: you get the recorded operation back rather than a second erasure.

If the argument names nobody (it is not a person's id and not an identifier of any person in the project), the command is refused and nothing is blocked, so a typo costs nothing. To erase what was recorded under an identifier that was never linked to a person, say so:

anectico persons erase backend-user-7 --allow-unlinked-identity --reason "Request 4192" --yes

That identifier is then blocked for good, so check its spelling first.

anectico persons erasure get 649ebca1-0452-45b7-aad3-29411ad0f6cd
anectico persons erasures list

Erase with an agent

The MCP tool is erase_person. Its first call is a preview: it shows which person the id resolves to and how many identifiers the erasure reaches, and returns a confirmation token. Repeating the call with the token applies it. If the person's identifiers change between the preview and the confirmation, the token no longer matches and the agent has to preview again.

An id that names nobody is refused at the preview, with no token, unless the call sets allow_unlinked_identity: true. The preview then says that the identifier is linked to no person and will be blocked for good.

get_person_erasure and list_person_erasures read the result. None of the three ever prints an identifier you did not supply. The erasure has no proof page; the Requests tab of the Console shows its progress.

Erase through the API

DELETE /api/v1/projects/{projectId}/persons/{personId}

{"operation_id":"649ebca1-0452-45b7-aad3-29411ad0f6cd","reason":"Request 4192"}

Add "allow_unlinked_identity": true to erase an identifier that was never linked to a person. Without it, a personId that names nobody is 404 and nothing is blocked.

See the API reference for the response, the status reads and the error cases.

Reading the status

The Console, MCP summaries and CLI tables name the data each part removes, such as Product events, Action receipts and Searchable action receipts, so a pending or stalled result says which data still needs attention. JSON responses keep each part's stable store identifier for scripts.

Field	Meaning
state	PERSON_ERASURE_STATE_COMPLETE once every part that takes part in the erasure has finished; PERSON_ERASURE_STATE_PENDING while work continues, or PERSON_ERASURE_STATE_STALLED when required work is overdue or receipt delivery needs recovery.
stores	One entry per part: its name, whether the operation waits for it, its state and when it finished, or its stalled_at and fixed detail_code when recovery needs attention.
status_message	A readable explanation when the operation is stalled.
stalled_at, stalled_reason	The first active stall time and fixed reason code. Overdue work uses required_work_overdue.
distinct_id_count	How many identifiers were blocked.
person_id	The erased person's id. Empty when you erased an identifier that was never linked to a person.

The operation waits for twelve parts of the platform: profile and identity removal, intake and product data, technical telemetry, recordings, diagnostic requests and problem reports, agent session replays, account memberships, analytics results and assignments, evaluation records, person exports, receipt values, and the searchable receipt copy. A new operation starts Pending. Each part reports completion only after its dependencies and any writes already in flight have settled.

If a required part has not finished after the expected time (30 minutes by default), the operation shows Stalled, lists the unfinished parts, and keeps each completed part visible:

Erasure has not finished everywhere after the expected time. The person's profile and identity are already removed. Keep the operation id and contact support to finish the erasure.

A part added to the required removal scope later also needs to confirm older erasures. Until it confirms, an older operation is incomplete and becomes Stalled after its expected time. This never turns an unverified part into a completion. Retrying the same request returns the same operation; it does not restart the erasure or the clock. A later completion from the missing part can still finish that operation. The Console continues checking stalled operations.

If receipt delivery cannot finish within 20 attempts or 24 hours, automatic retries stop and the operation shows Stalled. The original notice remains available for recovery. Contact support with the operation id. A platform operator can repair a recoverable delivery and resume it; the operation becomes Complete only after every required part confirms removal.

Successful CLI status reads exit 0 even while work is Pending or Stalled. For automation, inspect state; a successful command does not mean removal has finished.

Permissions

Erasing, and reading erasure operations, requires persons:erase. Owners and administrators hold it. An API key must be given it explicitly, and a project-scoped key can erase only in its own project. The reads take the same permission because an operation shows the reason someone typed.

Limits

• The reason is required and at most 400 bytes.
• One erasure covers a person with at most 5,000 identifiers. A larger one is refused whole; write to support.
• An identifier that was never linked to a person can be erased too, when you ask for it explicitly (--allow-unlinked-identity, allow_unlinked_identity): it is blocked, and the product events, errors, logs, traces, agent events, session recordings, diagnostic requests, problem reports, account memberships and survey records under it are removed, and results that listed it, or that could have counted its events, are withdrawn. It can be any text, including one that looks like a person's id. Without the explicit request, an id that names nobody is refused and nothing is blocked: blocking is permanent, and a mistyped identifier must not be blocked by accident. The Console only erases people it finds, so it never needs this.
• Erasing an identifier that is already blocked is allowed, and needs no explicit request. It is a new operation and removes anything stored under it since.
• The id you give is matched exactly. alice and alice (with a space) are two identifiers.