
Alias = anonym or pseudonym
-----------------------

Intro:

- Anonyms are per page. [one_anon_per_page] This is safer — can't track a single anonym
  accross different conversations. And more social? In that, if you want, you can show
  who you actually are, in one discussion, while remaining anonymous in all others.
  And good for ideation: Anonymous, temporarily. See the Ideation section.
- Pseduonyms (a.k.a pen names) can be reused accross pages and categories.
  They are more social, but less "safe". (Not implemented.)
- Both anonyms and pseudonyms inherit (some of) the permissions of the underlying
  true user. (Later, this will be more configurable? But not initially?)
  See [pseudonym_types] below.
- Depending on the community, one can have just one pseudonym at a time, or <= N,
  or maybe only one in a specific category (per-category pseudonyms)?
  (Can in rare cases make sense to disallow posting & interacting w others using one's
  true account — instead, must always be via a pseudonym.)
- When logged in to your real account, you can see notifications to your
  anonyms and pseudonyms, and things you've posted anonymously.
  (Not yet impl, see [list_alias_things]).
- Talkyard remembers & helps you continue using the same anonym or pseudonym in
  the same discussion (less risk that you accidentally reveal who you are).

If you think anonymous mode is just "flip a bool and they're anonymous",
then, this is a big box of butterflies!


Think about
-----------------------

[spam_check_true_user]
Maybe in publicly visible categories, mods & anons can be expected to have ways to figure out
who an anonym is?  Might be a bit necessary, to be able to block spammers.
Still, can be good to, by default, not let moderators see [which posts got spam checked
and passed the spam check] — because then they could better know which posts are by newer
members (maybe there's just one person who joined recently).
Only let them see which posts *failed* a spam check.
However, admins maybe must be able to see this, so they can decide if a spam check service
works ok well or not.

But in private categories and private communities, posts aren't sent to spam check
services, and maybe then anonymity can be stronger? So by default more than one
admin / mod need to agree, [joint_decisions]
before looking at people's trust or threat levels which they could then try to correlate
with an anonymous user having gotten blocked just recently because of writing something
not-alloowed.

Details: Banning an anonymous user (let's say someone who posts angry toxic things),
is going to affect the underlying true user's threat level. (Not yet impl, [block_true_user].)
But if a moderator can look at all true users' levels, then clicks Ban, and then looks at
all true users' levels again and notices that for user X, the threat level is now
a bit higher — then, X is likely the anonym's true user. [deanon_risk]

Therefore, maybe in private communities, peolpe's threat levels should be secret?
Only the software knows, by default? And to have a look, [joint_decisions] are needed?


Left to do
-----------------------

Now:
  - Save persona mode in ... localStorage? Cookie? [remember_persona_mode]
  - [hide_peoples_dates]  [deanon_risk]
  - Notifications: List notifications to all one's aliases (anonyms & pseudonyms),
    not just to oneself. [list_alias_things] [posts3_true_id]
  - Actions: List comments & pages by one's aliases, on one's recent comment page
    (but of course others, not even mods or admins, can see this). [list_by_alias]
  - Bind anonForPatId to ... Unknown user id? for now, in json dumps. [export_privid]


Later, quick:
  - RENAME // to ...ByTrueId?
    val anonsByRealId = anons.groupBy(_.anonForPatId)
  - Rename def getAliasOrTruePat()  to getPersona()?  And "nnnMaybeAnon" to "nnnPersona"?

Minor & medium:
  - Even more hidden user profiles? See: ../priv-prefs/priv-prefs-wip.txt  [hidden_profile]

  - Remember post-as-oneself in drafts3, use post_as_id_c, and,
  - Remember anon status, also when reusing anons, in drafts3.
  - Verify anonStatus is correct, when reusing an anon or resuming a draft  [chk_alias_status]

  - Button title: "Post as yourself", "Post anonymously]",  in >= anon-allowed cats.
  - Require 2 clicks to choose anon, but not at the same coordinates? [deanon_risk] [mouse_slip]

  - If subscribing to a page, use one's true id?  [pub_or_true_id_notf_prefs]
    But, some time later, don't show what one has subscribed to, if impersonated,
    by default? [safer_imp] [deanon_risk]
  - Let aliases edit wikis [alias_ed_wiki] (normally, editing
      others' posts anonymously isn't allowed)
  - wikify-dialog.more.ts  choose persona  (if posted as anon, should wikify as same anon)
  - Flag (report) things anonymously? [anon_flags]
  - Search for all ANON_UNIMPL
  - Better error messages: [alias_ux] [dif_anon_status]
  - All audit log  doerTrueId   should be like:  doingAs.trueId2  not  reqr.trueId2
  - Let mods & admins edit their own anon posts as themselves?  See [true_0_ed_alias]
    and [mods_ed_own_anon] in _checkDeanonRiskOfEdit().

  - An optional intro guide that explains anon comments? [anon_comts_guide]
    Like the admin intro tour, but about anon comments & votes, and for everyone.
    See  `staffTours: StaffTours`  in ../../client/app-staff/admin/staff-tours.staff.ts.

  - Also maybe show a dialog if a mod or admin edits group settings or helps someone
    configure their settings: Clarify that such changes aren't anonymous.
    Basically any changes on the user and group profile pages.

Even later:
  - Let [admins_see_presence] if needed, although disabled if sensitive anon comts enabled.
  - If disabling and later enabling the Presence feature, then, remember when it was enabled,
    and continue hiding presence up until then.  E.g. show  Last-seen-at  only if
    it's after the point in time when Presence got reenabled. [see_presence_start_date]
  - A [see_alias] permission, so can choose to see who an anonym is,
       or can vote to see who an anon is.
  - Ask the server which alias to use, instead of deriving client side [fetch_alias]
    e.g. if the page is big?
  - Incl true id in json dumps, depending on site sensitivity settings  [export_privid]
    Maybe add sth like talkyard.server.parser.JsonConf that says if any doerId.privId
    should be included or not?  SensitiveConf or PrivacyConf maybe?
    (Currently not included.)
  - Suspending: If an anonym posts say toxic comments and gets reported,  [block_true_user]
    then, can't suspend the underlying true user — that'd leak info about who the
    anonym is?  Instead, the anonym would get banned, and the true user
    prevented from creating new anonyms. Likewise, with pseudonyms?
    Or maybe: A new threat level!  Each true user has two threat levels:
    One for hanself, when han post as hanself. And another not yet existing
    anonThreatLevel, which is affected by how hans anonyms behave. And if
    hans anonThreatLevel becomes too high, han is prevented from posting anonymously
    any more. But no one can see others' anonThreatLevels (except for admins maybe
    after [joint_decisions]), so, there's no [deanon_risk].
  - Think about anonymous votes and how many have read this-or-that comment,
    when the same person visits & comments sometimes as hanself, sometimes
    using an alias.  See: PagePopularityCalculator  [alias_vote_stats]
    Answer: If sensitive discussions, each anonym has the same weight (doesn't matter who
    the true user is).  And if ideation, and temporary anon comments: Then, votes might even
    be hidden (to prevent anchoring bias and social biases), and later, when showing
    people's votes, people aren't temp-anonymous any more anyway (so, can calculate
    page popularity as usual).
  - [pseudonyms_later] [pseudonyms_trust]
  - Later: Anonymous chat messages? [anon_chats]
  - [sql_true_id_eq]
    Look at later, realted to anonyms and pseudonyms (looking up on both true id & anon id).
  - Anonymous/pseudonymous direct messages [anon_priv_msgs]. (Disabled by default?)
  - Panic button
  - Ask which persona to use, if changing category when composing new topic. [ask_if_needed]
    (Not that important, now there's an info message.)
  - Pass doer (usually the author)  and  trueDoer  to NotificationGenerator,
    so won't need to lookup inside.    [notf_pass_doer]
  - Set an anon's trust level to min required to post in the relevant category  [anon_tr_lv]
    (if the true user has that level or higher, so is allowed to post).

Tests missing:
  /^alias/  in test-map.txt.

Large:
  - Alias selector (see below) ... Oh, now implemented alraedy.

  - Dim buttons  [_dim_buttons] (that you cannot click if in Anon mode — but this requires
    the client to somehow reproduce all can-do-what permission calculations the server does,
    and for both (!)  oneself (does a button appear at all),  and one's current persona
    (should the button be dimmed, that is, one can click it using one's real account,
    but not as one's current persona).

  - Anonymous moderator actions  [anon_mods]:  Let mods do things anonymously,
    but using different per-page-&-user anons, so no one can see if
    replies by an anon, are in fact by one of the mods (if that anon later did
    sth only mods can do). — Look at all `getAliasOrTruePat()`.
    Or maybe post-as-group is better, all that's needed? (see just below)

  - Group aliases / post as group?  [group_pseudonyms]
    So many people can post, using the same name.
    E.g. all teachers in a school might want to appear as "Teacher",
    or support staff as "Support" without any individual name.
    Is it better to "just" use the group's name & username,
    or should groups be able to have a pseudonyms?

Much later:
  - More anonymous modes, e.g. one that doesn't remember who an anonym is — not in email logs,
    audit logs, etc.

Skip?:
  - Anonymous embedded comments. Not that important — can comment as a guest instead?
    Would need to ask which persona to use, in the comments iframe, before opening editor,
    so can show dialog next to the reply/edit btns.
  - Optionally disallow moving a page with anonymous comments, to a category
    where anon comments aern't allowed.
    See:  mayEditPage(.., asAlias, ...) in PageTitleSettingsController  [move_anon_page]
  - One person with [many_anons_per_page].  (Except for anonymous moderation, but maybe
    a shared moderator pseudonym is better.)


For sensitive discussions
=======================


Alias selector  [persona_mode] [alias_mode]
-----------------------
A preferred-alias selector in one's upper right username menu, which determines
which of one's aliases gets used, in places where one can post as:
  - Oneself
  - A pseudonym
  - Anonymously

If you comment or vote on a page where you have used another alias that the one
currently selected (in the alias selector),  then, Talkyard asks:
  "You previously commented here as X,  but you've activated pseudonym Y.
    Continue commenting as:  X?   Y?  [Cancel]"

And, since Y is a somewhat unlikely answer, dobuble check:  (not impl)  [mouse_slip]
  "Ok, you'll appear as Y   [yes, fine  /  no, cancel]"

(Might seem as if this double check question is an extra step, but it'll almost
never happen that anyone replies as X and later on what to continue as Y in the
same discussion. — Maybe shouldn't even be allowed; could be a config setting.)

Or, if the current mode is Anonymous, and you visit a discussion where you've
replied as yourself previously, then the choose-persona dialog appears too.

Dim buttons  [_dim_buttons]
-----------------------
When a not-oneself alias has been selected, then, all buttons that don't work
with alias mode, could be dimmed a bit?  For example, if one is a moderator,
an Approve Comment button wouldn't be anonymous (unless anonymous moderator
actions have been implemented & activated)

so if you're a mod, and you've choosen Anonymous, then a Delete Page button
would be dimmed, because you cannot delete the page anonymously (unless
it's your page).

And if you click it, there'll be a modal popup?
    """You can't do this [anonymously / as Pseudonym-Name].
       Do using your true account? [y / N]"""
and a tips about switching back to one's true account.

Will need a PermsOnPage for both oneself, and any currently selected alias?
Buttons one can click oneself, but one's alias cannot, would be dimmed?
And if clicking, a dialog pop up, e.g.:
    "You cannot do that anonymously. Use your real account? [y / N]"
Buttons one cannot click at all, aren't shown. Buttons one can click as one's
alias, are displayed as usual (not dimmed).)


Think about
-----------------------
- Pseudonyms: [not_use_true_users], when deciding if they should get notified?
  But isn't that similar to deciding if it's risky for that same pseudonym to _post_
  something  in the relevant category?

- [pseudonym_types]
  Should a pseudonym inherit the permissions of the underlying true user?
  Pros: More user friendly, probably how people expect things to work.
        Can grant pseudonymous access to only higher trust level users, or users a specific group.
  Cons: Simpler for others to guess who a pseudonym is, based on what restricted categories
        han has access to. — If this is a problem, depends on e.g.:
        - How many [user groups with different category permission combinations] there are.
        - How many users and their activity.
  Can even make sense with different types of pseudonyms?
    - One "type" that has the same access permissions as one's true account?
    - Another that doesn't inherit anything from one's true account?
      But can optionally be granted permissions independently of one's true account.
      This, though, is more like a completely separate account, but you access it
      by first logging in to your true account, then switching accounts.


Guessing who is who?  [deanon_risk] [mod_deanon_risk]
-----------------------
- People's slightly unique writing style can be a "problem", can be mitigated by letting
  an AI transform all anon comments to a similar writing style.
- In a small forum: Sbd being active in the middle of the night, and some anonymous
  comments from the same time span, otherwise just silence the whole night. Repeated a few
  times, then, easy to make a good guess about who posted the anon comments. — Mitigated
  by hiding last-active-at & posted-at timestamps, or making timestamps coarse-grained,
  e.g. showing only day or week (but not hour and minute). [hide_peoples_dates]
- Inherits permissions — see [pseudonym_types] below.
    - Posting anonymously in a category few people have access too.
    - Anonymously moving a page from one access restricted cat to another.

- Count people with access: If doing things few others can do, e.g. posting anonymously
  in a category to which few people have access (especially if doing repeatedly
  using a pseudonym), then:
      Count how many have acces, and estimate total % likelihood
      that someone correctly guesses who the person is.

      For example, 1 / num-people-with-access.  Or, look at all past posts and actions
      of a pseudonym (can use AI and spend a bunch of lifetimes, researching this?).

      And if too easy to guess, show an info message to the user, maybe they
      then don't want to post. Or they might want to create a new pseudonym.
      If hard to guess (what's that? 1 in 20? 1 in 200? 2000?) then just
      show an info symbol somewhere, e.g. "Anonymity 99%" if 100 people have access?

  Also helpful in, say, a forum for a university, when in the beginning just a few
  peolpe have joined. Then, might want to wait with posting anonymously, until there's
  lots of people in the forum, so others can't guess who is who.

  This needs a way to calculate how many people can see the relevant category.
  And, turns out this is useful also if moving a (sub) category to somewhere else,
  or editing its permission settings:  Then it'd be nice if the admin could see
  how the changes affect who can/not see the category, thereafter.
  [direct_cat_perms] [cat_perm_inh_bug]

- When posting anonymously, sometimes safer to [not_use_true_users]' permissions.
  Maybe that could be an option somehow?


Lots of work
-----------------------
- Joint decisions  [joint_decisions]
- When about to do sth using an alias, count how many others in the forum that can do
  that same thing, and if it's less than X, then show a notice:
    """Only Y people can post a comment here. Others might guess who you are.
    Proceed anyway? [y / n]"""
- If admins configure categories so there's small groups with unique sets of permissions,
  and pseudonyms allowed: Maybe tell the admins that it's possible to make pretty
  good guesses about who the pseudonyms are?
- If an admin Alice impersonates Bob, then, even if Bob's list of aliases are hidden
  (so Alice can't see them),  it can still be partly possible for Alice to figure out
  which aliases are Bob's aliases — by looking at when Bob did *not* get notified about
  a comment, namely if one of Bob's aliases replied on one of Bob's pages, and
  Bob ought to have gotten notidied but didn't  (Talkyard won't currently notify
  sbd about *their own* anonymous comments.)  [notfs_trueid_check]

  However, it's better to restrict impersonation? So [joint_decisions] are needed
  to impersonate anyone  (say, >= 2 admins need to agree) combined with
  impersonation notifications  [imp_notfs].

  Or, hide notifications, if impersonating. Maybe could be different impersonation
  capabilities, e.g. see true user's comments / see anon comments. Can be nice if
  it's possible for an admin to help sbd out by impersonating their account and
  figure out why sth doesn't work, *without* any chance that the admin accidentally
  learns who that person are, anonymously.


For ideation
=======================


[auto_deanon]
[auto_show_replies]
Needs: [add_triggers_t]



