Deadnames and deadnaming

It does say it can be accidental, though. Unfortunately, a lot of deadnaming is more often than not deliberate and malicious. :sweat:

In any case, “deadname” was the term that was coined and isn’t likely to change any time soon. It’s pretty apt for old names you’d rather were buried as deep as possible. :coffin:

1 Like

i’m referring to either recordings or releases with deadnames in the “credited as” field. aliases are an unrelated field in these instances.

earlier in this thread i suggested adding display options to credited as, allowing for a variety of display modes

for example, let’s say fictional artist “Jane Doe” has historical releases under her deadname “John Doe”

  1. “replace” mode: this would work the same way “credited as” does now, the credit would be listed as “John Doe” with “Jane Doe” only visible when hovering over the link.
  2. “credited as” mode: this would display “Jane Doe (as John Doe)”
  3. “hidden” mode: not sure about this one, i figure either a spoiler tag or hidden behind a link kind of thing.

“replace” mode is already implemented, “credited as” mode seems like a pretty well defined thing and a small technical change, and “hidden” mode probably needs more discussion before any code is written

1 Like

This seems like a problem that could be solved with an enhancement to the aliases feature. If one could implement something like visibility “permission levels” on aliases, I think this could work well.

At first, I was just thinking, “What if we allow some alias additions to be write-only?” Then the database could say, like, “…and x many invisible aliases” when looking at an aliases page… but that seems like a crude solution.

Imagine an edit type that can be submitted to existing aliases which “locks” them as private. This edit type would always be votable, and could have special timespans, and conditions for closing (ex. you must always recieve at least one upvote). From there, privatized (‘locked’) alases cannot be viewed by anyone, or changed in any way, and the only valid operation on them would be to unlock them, with a similar style of edit type that locking them required.

This would add a sufficient, I think, amount of impedance towards abusing the feature, but still allow for all the stuff we’re talking about: having aliases that aid searchability, but which don’t lead to any discoverability of old names.

1 Like