Since Simply Plural first shut down, it has become impossible to ignore how much personal information users entrust to plurality applications, and just how devastating the consequences can be when that information suddenly becomes inaccessible.

For some systems, that can mean months or years of work documenting headmates, relationships, memories, fronting history, and other deeply personal information being irretrievably and irreversibly lost, potentially leaving them in a state of crisis.

A recent Reddit post brought this concern sharply into focus. A user described returning to Ourcana after months away, only to discover that the system information they had painstakingly entered appeared to have vanished.

We do not know whether their data was actually deleted, whether an application change made it inaccessible, or whether a recovery mechanism could restore it. Those distinctions matter when diagnosing a particular incident. They also illustrate a broader engineering concern: the same apparent loss of data can result from several entirely different failures, and users may have no reliable means of determining which one occurred.

The incident prompted us to consider several fundamental responsibilities shared by developers of plurality applications. These apply to locally installed software, cloud-hosted services, and applications that combine both approaches.

We believe the community would benefit from considering five areas: routine backups, independent storage, auditing, interoperability, and the allocation of responsibility between developers and users.

1. Backup should be an integral part of the application lifecycle

Most users are concentrating on the information they are entering, organizing, and maintaining. They should be able to work without continually considering the possibility of losing that information.

An application should therefore incorporate backup into its normal operating behavior.

One longstanding example comes from personal finance software. Quicken has historically offered periodic backup reminders based on application usage. The principle is straightforward: after a reasonable number of sessions, the application reminds the user that their information should be protected.

Plurality applications could adopt a similar approach, with reminders based on elapsed time, application usage, or the amount of information changed since the last successful backup.

The exact mechanism matters less than its reliability and its ability to avoid becoming intrusive. A reminder presented at every opportunity will eventually become background noise. One presented too infrequently may leave weeks or months of work at risk.

A more sophisticated implementation might consider:

• When the last successful backup occurred.

• How much information has changed since then.

• Whether the application has completed a recent backup successfully.

• Whether the user has deliberately disabled or postponed reminders.

For applications that support automatic backups, these same considerations could govern backup frequency rather than user prompts.

The objective is to establish a predictable recovery point, limiting the amount of work that could be lost following an unexpected failure.

A backup mechanism that users rarely invoke offers limited practical protection. Backup needs to become part of the application’s ordinary behavior.

2. Data must be preserved independently of the device

Creating a backup is only one part of the problem. Its location determines which failures it can survive.

Consider a locally installed application that creates backups in its own application storage. Those backups may be helpful when recovering from accidental deletion or certain application failures.

However, if the device is stolen, physically damaged, or rendered completely inoperable, the original information and its backups may disappear together.

That creates a common point of failure.

A stronger approach gives users the option of maintaining backup copies in storage independent of the original device.

For example, an application might support destinations such as Google Drive, another cloud storage provider, removable USB storage, or a network drive. The destination should be chosen by the user according to their requirements.

This is particularly important for plurality applications because privacy concerns can be substantial. Some users deliberately choose local applications to avoid sharing their information with an application’s developers or infrastructure.

Their choice deserves respect.

Off-device preservation does not have to mean developer-hosted preservation.

An application can provide the ability to save information to a user’s independently controlled storage without requiring the application developer to receive, host, or manage that information.

Where appropriate, encryption can further protect backup contents, particularly when storage providers or physical media could be accessed by others. Of course, encryption also introduces a responsibility to preserve the keys or credentials required for recovery.

There is another important consideration: users must understand the consequences of declining off-device backups.

Whether protection is enabled by default or offered through an explicit opt-in process is a design choice. What matters is that the application communicates the implications clearly.

A user may reasonably decide that keeping all information confined to one device is worth the risk. That choice should remain theirs.

But if that device subsequently becomes unrecoverable, the application may have no means of reconstructing the lost information.

Developers should make the available protections and their limitations understandable before such an incident occurs.

3. Audit trails are essential to understanding failures

One aspect of data preservation that receives comparatively little attention is auditing.

When users report that their information has disappeared, developers need a means of determining what actually happened.

Was information deliberately deleted? Did an application update encounter a migration error? Did the software fail to locate an existing data store? Was a synchronization operation interrupted? Did an unexpected operation overwrite valid information?

Each represents a different failure mechanism and potentially requires a different recovery procedure.

Without adequate diagnostic history, developers are left attempting to reconstruct events from incomplete observations.

An audit trail provides a record of significant operations and changes that can help establish the sequence of events leading to a failure.

Depending on the application’s architecture, relevant information might include:

• Creation, modification, and deletion of records.

• Application and data-format version changes.

• Database migrations and their outcomes.

• Backup and restore operations.

• Import and export activity.

• Synchronization attempts, conflicts, and failures.

• Application errors affecting data persistence.

An effective audit trail should provide enough context to investigate problems while avoiding unnecessary collection of sensitive information. The design should distinguish operational metadata from the deeply personal content users maintain.

This is an architectural consideration we have been incorporating into PluralBridge from the beginning.

The audit trail itself must survive failure

There is an additional problem with audit trails maintained exclusively on a local device.

If the device becomes unusable, the diagnostic information may disappear along with the user data it was intended to help protect.

Consequently, locally installed applications should consider offering a means of preserving their audit history, or a condensed diagnostic version, independently of the device.

Importantly, the destination should be controlled by the user, using the same storage choices available for ordinary backups.

A person who chooses to operate entirely locally should be able to preserve diagnostic information on their own removable media or network storage. Someone comfortable with cloud storage might choose their own Google Drive account.

Neither arrangement requires transferring audit information to the application’s developer.

That preserves the privacy boundary established by the user’s choice of local operation.

This could become particularly relevant as PluralBridge eventually expands beyond its web architecture to mobile, tablet, and locally installed desktop clients.

A practical design would also consider how frequently audit information is preserved, how much history should be retained, and whether the records provide enough context to reconstruct meaningful events.

Audit trails cannot guarantee that every failure will be explained. A sudden hardware failure, for example, may prevent the final operations from being recorded.

Nevertheless, properly designed and preserved audit histories substantially improve the prospects of investigating failures, identifying defects, and preventing recurrence.

Protecting the data and protecting the evidence of what happened to the data are two related engineering responsibilities.

4. Immediate backup protection should not wait for universal interoperability

The plurality application ecosystem has another important challenge: the ability to move information between applications.

People may switch software because their needs change, development ceases, features become unavailable, or another application offers capabilities better suited to their system.

A universal import/export format would make these transitions considerably easier.

PluralPort is working toward a shared interchange specification for plurality applications. We strongly support that objective and have contributed to its development through our own interoperability work.

A common format offers the prospect of reducing duplicated engineering effort, minimizing information lost during transfers, and allowing users greater freedom to choose the applications that serve them.

But establishing a broadly accepted standard requires collaboration, careful specification, and consideration of the different data models used by existing applications.

That process takes time.

Meanwhile, users need dependable backup and recovery capabilities today.

Application-specific formats are a practical interim solution

An application does not need a universal interchange standard to implement reliable backup and restore.

It can initially preserve information using its own native format, including application-specific structures and metadata that may not yet have equivalents in other applications.

Such formats can provide meaningful recovery capabilities while broader standardization continues.

They also preserve opportunities for future migration.

If data is available in an application-specific format that can be understood, developers can create converters and adapters to translate it into other representations.

This approach has been used throughout software engineering for decades. It is often less convenient than a common interchange specification, and converters require maintenance as formats evolve, but it remains practical.

The crucial requirement is that the data survives in a form that can be recovered and interpreted.

If necessary, developers can later construct translation tools that bridge different application formats.

If the only copy of the data has been permanently destroyed, however, no converter or interchange specification can reconstruct it.

Moving toward a shared standard

We see application-specific backup formats as a transitional measure.

As the PluralPort specification matures and gains broad agreement among application developers, we would strongly encourage applications to adopt it for interoperable exchange and progressively reduce dependence on proprietary interchange formats.

Developers should also retain whatever additional mechanisms are necessary for complete, reliable recovery of application-specific information.

There is a useful distinction here between a backup designed to reconstruct an application’s complete working state and an interchange format designed to transfer information between different applications. The two functions overlap considerably, but they may have different requirements.

A shared standard should ultimately make portability easier, while reliable backup and restore remain essential responsibilities of each application.

This establishes a practical progression:

1. Protect user data immediately through reliable application-specific backup and restore.

2. Provide converters and adapters where feasible to support migration between existing formats.

3. Continue developing and refining a shared interchange specification.

4. Encourage broad developer adoption as that specification becomes sufficiently mature.

5. Make preservation, recovery, and migration increasingly straightforward for users.

The standards effort and application-specific backup development can proceed in parallel.

Preserve the information now. Improve its portability as the ecosystem develops.

5. The engineering burden belongs with application developers

Underlying all these recommendations is a question of responsibility.

Users of plurality applications should be able to concentrate on documenting their systems, maintaining their histories, and organizing information that may be deeply important to their daily lives.

They should not need expertise in database administration, storage architecture, backup formats, or data migration.

Application developers are better positioned to design the mechanisms that protect information, verify that backups can be restored, maintain useful diagnostic records, and provide straightforward recovery procedures.

This also raises an essential distinction between creating a backup and demonstrating that the backup is usable.

A file’s existence alone does not establish that the information within it can be successfully restored.

Reliable backup and restore systems should consider integrity checks, compatibility across application versions, interrupted operations, and testing against realistic datasets.

An application update should also be examined for its effect on existing data and recovery mechanisms. A migration that works with an empty test database may behave differently when confronted with years of actual user information, complex relationships, or unexpected historical records.

These are precisely the kinds of engineering concerns that benefit from representative test data, migration simulations, and collaboration among developers.

Our work with other plurality application developers has reinforced the value of exploring such problems collectively.

Users still retain important choices, particularly around privacy and where their backups are stored. An individual may decline remote storage entirely, accept a shorter recovery history, or choose to manage their own backup media.

Those decisions should be informed and respected.

The corresponding responsibility for developers is to make the protective mechanisms dependable, accessible, and understandable.

A broader opportunity for the plurality community

These concerns extend well beyond any single application or reported incident.

Every application that stores personal information faces questions about persistence, failure recovery, diagnosis, and the long-term accessibility of its data.

Within the plurality community, those questions carry particular weight because the information may represent years of personal history, relationships, identity, and experiences that cannot easily be recreated.

We have been exploring these principles through PluralBridge, but their usefulness is independent of our own software’s development or release.

They can be considered and adopted by developers of existing applications, future projects, and interoperability initiatives throughout the community.

That is increasingly central to the work of Needs of the Many: encouraging discussion, sharing engineering perspectives, learning from people’s experiences, and developing ideas that can improve the ecosystem as a whole.

We would welcome participation from users and developers alike.

For users, the questions are immediate: Do you know how your application protects your information? Can you restore a backup? Would that backup survive the loss of your device?

For developers, there are equally important questions: How are backups initiated and verified? What happens when upgrades or migrations fail? Can diagnostic information survive a catastrophic failure? How can users preserve their privacy while maintaining reliable recovery options? And how can we move toward shared interoperability without delaying the protections users need today?

We believe those conversations are worth having across the entire plurality application community.

The information people entrust to our applications deserves protection that reflects its importance to their lives.

Last time we asked a question that came out of an ordinary therapy session: When you look into the mirror, who do you see? We were looking to find answers in what we thought would be a small set of comments. What came back was a remarkable collection of experiences, and the more we read, the harder it became to describe the answers along any single axis.

Our hope was to glean some commonality to explain how we perceive the image each of our headmates sees when (or more accurately, if) they look at their reflection in the mirror. Instead, we find ourselves feeling more unsettled, less grounded and walking away with the feeling that this exercise left us with more questions than we have answers.

Here then is a sampling of what other Systems replied to our open-ended question:

Some people simply see the body; others see the body but don’t recognize it as themselves. They know intellectually whose reflection it is, yet the connection between that knowledge and a sense of “that’s me” just doesn’t land. Several people described the body as a vessel, an avatar, or something they inhabit and maintain. The reflection belongs to the body; the person looking at that reflection may have a very different understanding of what they themselves look like.

For some, the experience changes depending upon who is fronting. Different physical features can seem more prominent to some while more obfuscated to others. The face in the reflection can feel comfortable to some while dysphoric or alien to the others. Some described an internal appearance that becomes part of the visual experience itself. One person described seeing the face they perceive in their head overlaid onto the physical reflection, almost like an image at partial opacity. Another described sometimes seeing paws instead of hands.

Age appeared to influence what many saw. Some littles ‘know’ that the face in the mirror is the System’s while simultaneously seeing an adult who bears little resemblance to how they see themselves. Still others described expecting different heights, builds, faces, or other physical characteristics and being reminded by the mirror that the reflected image doesn’t match their expectation.

Gender added another fascinating dimension. Headmates whose lived gender differs from how they present described feelings ranging from discomfort and dysphoria to a profound lack of recognition. For some, transition had changed their relationship with the reflection, sometimes making it easier to recognize or accept while other times creating more confusion.

Some choose to avoid mirrors altogether. Some see a stranger looking back at them. Some see a body disconnected from ownership. Some recognize themselves intermittently. Some describe the reflection as uncanny or distant; some simply see themselves.

What struck us most reading these responses was how many found more questions than the one they set out to answer: Do we recognize the face staring back at us? Do we even feel like this body is ours? Does it even resemble us? Do we know what we really look like? Does what we see change depending on who is fronting? Does that reflection match our age, gender, species, size, or internal appearance? How do we feel about the person looking back at us?

Those aren’t necessarily different answers to the same question. They may be trying to answer different questions than what we originally tried to answer. It is not uncommon for a headmate or System to hold multiple truths. We hadn’t anticipated the complexity of answers to what felt like a simple question: “When you look into the mirror, who do you see?”

The uneasy feeling we are now left with has left an indelible mark, an additional facet that we now have to contend with. Seems more introspection is in our immediate future.

To be continued...

The last several days have yielded a surprising validation for some design choices we made for developing PluralBridge. The biggest challenge we struggle with is how to create an application that allows Systems to be modelled as a user’s lived experience, without falling into the deadly trap of overdesign, or worse, creeping featurism. With that background, let us regale you a tale of a happy accident in a design choice. In the beginning....

...when a developer is indoctrinated into developing software for clients, they tend to learn some hard lessons as they progress through their career. First and foremost is, make sure to get the design, use case, and growth projections. By no means does this mean you will walk away with everything you need. What you do get is a baseline, and as you accumulate experience, you learn to anticipate where to leave wiggle room on numbers, and where to drill down for the detail required to get a solid foundation that can withstand change without tearing out the support beams and starting over.

Early on in our career (very early on) we were asked to develop a “simple” inventory and cash management application for a small boutique store. The target hardware platform was a TRS-80 Model III with 48K RAM - that’s usable RAM, the rest went to DOS and BASIC ROM(s). To put that in perspective in today’s world where users typically traffic in gigabytes or even terabytes, the task was tantamount to fitting the entire Declaration of Independence onto a postage stamp.

Acquiring a customer can be a euphoric experience, especially when you are first starting out. We did our “due diligence” - according to the client there was a customer flow of about a couple dozen a day, and ~100 items in inventory. We had acquired enough development experience to know that our “database” on floppy would have to use a token as a unique ID. We reasoned to ourselves, ~100 items, even if it doubled, should fit nice and snug inside of a byte. Keep in mind, every byte mattered both in memory and on disk.

Not long after we got a frantic call. The Receivables, Payables and Inventory reports were just wrong! Items and their attributes were getting cross matched, and the reports were basically useless. It didn’t take long to ask the question we should have verified; exactly how many unique inventory items did the client input? Answer, over 400! yeah, not hard to see where a byte which can hold up to 255 unique items (we reserved ‘0’ for our app logic) would overflow on item #256. That wasn’t the worst of it - in 48K of RAM we could hold the inventory IDs in memory to speed up access. An array of 255 elements might not sound like much, but RAM was a precious resource - doubling it meant our program would no longer fit in memory.

In the end, we punted; we doubled the size as needed expanding the number of unique items to 65535, and rewrote chunks of the BASIC code in assembler. As a by-product, it actually sped up the program considerably. The cost? A week of sleepless nights and feeling very stupid for having not anticipated this. House said it best, “everybody lies”.

That leads to the second cardinal rule: When designing software for a client, reduce the number of choices to as few as possible to minimize surprise. For many problems developers face, that largely works. However, all choices have consequences, and when you limit the palette from which your client has to choose features, you can miss the bigger picture. Worse, you may be working under the pretext that you can confidently design something for users without ever cross checking if what you are building will serve the largest number of users while maintaining a sound foundation.

This is that tale...

Happy accidents are unintended events or apparent mistakes that produce unexpectedly useful (and often better) results than what the creator intended or expected. Modern music is littered with riffs or lyrics that became legendary, so much so that they enter the mainstream as if they were always meant to occupy that space. Engineers run into similar unanticipated results trying to solve an entirely different problem than what their discovery yielded.

Some notable examples yielding discoveries that anyone in this time cannot imagine living without:

In 1945, Raytheon engineer Percy Spencer was working near an active magnetron when he noticed that a chocolate bar in his pocket had melted, leading him to suspect that the microwave radiation was heating the food. He experimented with other foods, including popcorn and an egg, and the discovery ultimately led Raytheon to develop the first commercial microwave ovens.

In 1968, 3M scientist Spencer Silver was trying to develop a strong adhesive when he instead created an unusually weak, pressure-sensitive adhesive that could stick to surfaces and be removed repeatedly without leaving much residue. Years later, colleague Art Fry wanted bookmarks that would stay put in his church hymnal without damaging the pages, remembered Silver’s odd adhesive, and the combination eventually became the Post-it Note.

Our colleague Sharky Yellowfish cast a net yesterday after an intense session with their therapist asking a seemingly innocent question: “When you look into the mirror, who do you see?”. They were wrestling with how their System inhabitants ranging from age 4 to 40 literally see themselves and how others see them, depending on who is fronting.

That yielded a rich and frankly unexpected range of replies from real Systems and their lived experience. It also exposed a design flaw in our implementation of both how a headmate identifies, and how they express their pronouns.

Here is where our happy accident begins.

Up until now, we had been thinking about identity in much the same way most software designs do: give someone a field on a form to select an adjective that best describes how they identify. Provide them another field on a form for their pronouns. Perfectly reasonable, right up until real people start answering a question thrown out into the ether - when you look into the mirror, who do you see?

Contrary to the reply shape we constructed in our own head(s), user comments did not arrive in neat little buckets. One headmate might identify as a woman, a trans woman, plural and lesbian, with each of those words carrying useful information. Another might have an entirely different relationship with gender. Some Systems described headmates whose gender differed from the body, others whose age changed how they perceived the body, and still others described members who were animals, creatures, fictives or otherwise not human at all.

In what can only be described as a “D’oh” moment, our entire concept of “Identity” no longer inhabited the limited cage we gave it.

Our first instinct might have been to add more adjectives. Gender. Sexuality. Species. Fictive status. Perhaps a few more checkboxes for things we had not thought of yet. No, that won’t work. Maybe add a custom fields box to add more adjectives for Systems that don’t conform to our own limited lived experience. That road has a very familiar destination: every time somebody teaches us something new to describe themselves, we are forced to make a change. Maybe it’s software, maybe a database join table. This has a very distinctive code smell. Can’t ignore the battle scars of our creations we leave behind.

What if, instead of seeing identity as a ‘one size fits most’, we instead see it for how human beings actually move socially? If we were to describe ourselves, our composite might look like:

Identity: Trans woman, engineer, musician, mother, progressive, DID, curious, risk taker, tired.

A composite of otherwise potentially orthogonal adjectives that individually provide only a small glimpse into who we are. The whole is greater than the sum of the parts.

Sometimes the gods that provided the circumstances of a happy accident might also provide affirmation. We were already moving this idea around in multiple dimensions when we encountered the first response that said simply ‘wolf’. And just like that, we saw how our model could seamlessly provide the necessary parts to this new approach:

Identity: Animal, wolf.

Then we got to thinking, what if we could intuitively provide ranking based on which adjectives came first? Make a mistake, deselect choices until you reach the last known good point, and select new tokens in the order you perceive.

And what if we could make it intuitive and easy to add new choices? What if we then displayed this?

Identity: Animal, wolf, [+]

Like the defaults? Leave it as-is. Want to edit/add the identity tokens? Click the ‘+’ sign.

Sharky went looking for an answer to what plural people see when they look into a mirror. Instead, dozens of people describing their lived experience handed us a better abstraction for identity and pronouns.

That is what composability buys you. The pieces can remain small while their combinations describe something much richer, and the next person does not have to fit themselves into whatever collection of boxes we happened to think of first.

Sometimes a melted chocolate bar gives you a microwave oven. Sometimes a failed adhesive gives you a Post-it Note.

And sometimes you ask Reddit about mirrors and accidentally redesign Identity.

A peculiar question came up in therapy recently:

When one of us looks into a mirror, who does she see?

We’re a DID System of about 60 head mates, ranging in age from four to somewhere in our 40s. Our System turns 63 in a couple of weeks. We’re also post-op trans-female, which adds another interesting wrinkle to the question.

Some of our littles are what we call “time-locked.” A four-year-old head mate understands herself as four. She doesn’t understand why her mommy and daddy have disappeared (our older head mates know they passed away over 10 years ago). She acts age appropriate, and sees herself as four. Telling her that the body is nearly 63 doesn’t somehow make her 63. Her memories of what “we” look like also come from a body that existed decades before transition, including top and bottom surgery.

During a therapy session, one of our littles was working through knowing that she is a girl and some painful memories surrounding our parents’ response to that declaration. At one point, looking in the mirror entered the discussion.

And that left us with what initially sounded like a rather philosophical question. What does she actually see?

We then realized that this question might be physiological as well as psychological.

The obvious answer suddenly wasn’t so obvious

Our first instinct was essentially the conventional one: the mirror reflects the same light regardless of who’s fronting. Same body, same mirror, same eyes, same image. Except... there’s a rather large assumption buried in “same eyes.”

Our System already has some startling physiological differences between head mates. A few of us smoke heavily, up to two packs a day. Most of us are sickened by cigarette smoke. Stranger still, the smokers clearly experience nicotine addiction while the non-smokers experience no noticeable withdrawal when they’re fronting. Our DID therapist tells us that state-dependent physiological differences aren’t an unfamiliar phenomenon in DID.

So we started wondering: is vision physiologically different too? It turns out this question has already been raised.

Same eyes. Different measurements.

In 1996, optometrists Morton Birnbaum and Kathleen Thomann published Visual function in multiple personality disorder. “Multiple personality disorder,” of course, was the terminology then used for what we now call dissociative identity disorder.

Their paper reviewed reports of physiological and ocular differences between identity states and presented a patient they had followed for three years.

The list of reported visual differences is remarkable:

• visual acuity

• refraction

• oculomotor status

• visual fields

• color vision

• corneal curvature

• pupil size

• intraocular pressure

Those aren’t descriptions of somebody feeling that she looks different. They’re reported differences in measurable properties of the visual system. That changes the mirror question considerably.

The external scene hasn’t changed. Light still leaves the face, reflects from the mirror, and arrives at the eyes. But “the same optical scene reaching the same body” doesn’t establish that the visual system produces an identical physiological response to it.

Refraction affects how light is focused. Pupil size changes the optical system through which that light passes. Oculomotor differences can affect where and how the eyes fixate. Differences in color vision and visual fields concern the information ultimately available to perception.

So the chain actually looks something like this:

face → mirror → optics of the eye → retina → visual pathways → visual cortex → higher visual processing → self-recognition

And DID potentially enters that chain considerably earlier than we expected.

Then things get downright strange

A 2015 paper by Hans Strasburger and Bruno Waldvogel describes an extraordinary case involving a person with DID who had been diagnosed with cortical blindness for 15 years. During psychotherapy, some identity states gradually regained sight. Others remained blind. This presented researchers with a rare opportunity. They could measure visual evoked potentials, or VEPs: electrical responses generated by the nervous system following visual stimulation. In the identity states that could see, VEPs were normal and stable. In the identity states that were blind, the VEPs were absent. Switching between those states could occur within seconds.

Think about what that means for a moment. This wasn’t simply one head mate saying, “I don’t think I can see.” An electrophysiological measurement changed along with the identity state.

The authors proposed top-down modulation of the primary visual pathway, possibly involving the thalamus, and concluded that visual information appeared to be suppressed at an early neural stage. Their precise mechanism remains a hypothesis, but the measured phenomenon itself is fascinating.

Obviously, blindness is an extreme case. It doesn’t establish that my four-year-old and I literally see different faces when looking into the same mirror.

It does establish something much more useful for asking the question:

We cannot safely assume that visual processing remains physiologically identical when identity states change.

DID already has measurable psychobiology

Vision isn’t standing alone here.

A 2006 study led by A.A.T. Simone Reinders examined 11 people with DID while different identity states were exposed to neutral and trauma-related autobiographical memory scripts. Researchers measured subjective responses, cardiovascular responses including heart rate and blood pressure, and regional cerebral blood flow using PET. Different dissociative identity states showed different cardiovascular reactions and different patterns of cerebral activation. Other neuroimaging work has also reported differences in regional cerebral blood flow associated with DID.

None of this means every physiological difference that a plural System notices has been scientifically demonstrated to result from switching. DID research has historically involved small samples, difficult experimental designs, and phenomena that aren’t especially easy to drag into a laboratory. It does mean that “it’s all the same body” is an inadequate scientific answer to every question about state-dependent physiology. The same body can occupy measurably different physiological states.

So what happens in the mirror?

This is where we reach the boundary between what science has demonstrated and the answers we are seeking. We haven’t found an experiment in which researchers asked multiple head mates to look at their shared face in a mirror and then determined whether the resulting visual percept changed with whoever was fronting. That would be a fascinating experiment. There are also several different things we could mean by “seeing someone different,” and they’re easy to collapse into one another. A head mate might see the body’s face perfectly accurately while experiencing: ”That’s me.”

Another might experience: ”I know that’s our body, but that person doesn’t look like me.”

Still another might recognize the face intellectually while experiencing the person in the mirror as a stranger. Someone whose internal self-image differs strongly from the body might experience an immediate mismatch between the expected face and the reflected one. Perhaps some people experience something stranger still: the reflected face itself seems perceptually different depending upon who is looking.

Those experiences could arise at very different points in the perceptual chain. Some differences might concern self-recognition. Others might involve body representation and internal imagery. Still others could involve attention and higher-order visual processing. Given the published findings involving ocular measurements and visual electrophysiology, we don’t think we can automatically exclude state-dependent visual physiology from the possibilities.

That last possibility needs to remain a question. The research we’ve found doesn’t demonstrate that DID head mates literally perceive different facial geometry in a mirror. Neither does the available science justify assuming that every head mate receives an identical visual representation and differs only in how they psychologically interpret it. That’s what makes the question so interesting.

So we asked other Systems

We deliberately stripped most of this science out when we took the question to Reddit. There was a practical reason. We didn’t want to hand people a theory and then ask whether they experienced it. That’s a wonderful way to contaminate an interesting question.

Instead, we simply explained how the question arose and asked other Systems: Who do you see when you look in the mirror? Do you see the body’s face as it physically appears? Do you see yourself as you understand yourself internally? Does the reflection somehow look different depending upon who is fronting? Do you recognize the person in the mirror while simultaneously feeling that they don’t look like you?

The responses have only begun coming in, and we’re deliberately going to let those conversations percolate before writing about what other people report. For now, we’re left fascinated by the question itself.

A mirror seems like one of the simplest measuring instruments humanity ever invented. Put a person in front of it and light gives you an image of the person standing there. For a DID System, however, there is another instrument sitting between that mirror and conscious experience.

The brain.

And apparently, changing who is looking can change considerably more than we once thought.

Our responses on Reddit are already falling into several fascinating categories: recognition without ownership, altered feature salience, and reported visual overlays.

We’ll explore what people are telling us next time.

Sources / Further Reading

1. Birnbaum, M. H., & Thomann, K. (1996). “Visual function in multiple personality disorder.” Journal of the American Optometric Association, 67(6), 327–334. PMID: 8888853.

https://pubmed.ncbi.nlm.nih.gov/8888853/

2. Strasburger, H., & Waldvogel, B. (2015). “Sight and blindness in the same person: Gating in the visual system.” PsyCh Journal, 4(4), 178–185. DOI: 10.1002/pchj.109. This is the DID case in which VEPs were absent in blind identity states and normal in seeing states.

https://onlinelibrary.wiley.com/doi/10.1002/pchj.109

3. Reinders, A. A. T. S., Nijenhuis, E. R. S., Quak, J., Korf, J., Haaksma, J., Paans, A. M. J., Willemsen, A. T. M., & den Boer, J. A. (2006). “Psychobiological characteristics of dissociative identity disorder: A symptom provocation study.” Biological Psychiatry, 60(7), 730–740. DOI: 10.1016/j.biopsych.2005.12.019. This is the 11-person PET study measuring subjective, cardiovascular, and regional cerebral-blood-flow responses across identity states.

https://pubmed.ncbi.nlm.nih.gov/17008145/

4. Sar, V., Unal, S. N., & Ozturk, E. (2007). “Frontal and occipital perfusion changes in dissociative identity disorder.” Psychiatry Research: Neuroimaging, 156(3), 217–223. DOI: 10.1016/j.pscychresns.2006.12.017. The study included 21 medication-free participants with DID and nine healthy controls.

https://www.sciencedirect.com/science/article/abs/pii/S0925492707000030

If you’ve ever tried to move information from one plural app to another, you know how painful that can be. Without a standardized exchange format, you’ll have little luck getting the new app to understand and import the exported data.

Why would you want to switch apps? You might find that your app doesn’t provide the features you want, or constrains how your System is organized. Or sometimes, the app you are currently using suddenly goes dark along with your data. Either way, you are now faced with a choice: force a square peg into a round hole, or start from scratch.

What if you had a third option? What if all plural apps could standardize on one common format? One that allows each app to capture how it is organized without disrupting the common denominator. A format that lets any app import what it understands, and skips what it doesn’t, never transforming, modifying or changing the meaning that the source app intended.

Every app has its own way of organizing and exporting information. One may represent fronting, groups, member relationships, or privacy settings differently from another. So even when two apps seem to cover the same basics, an export from one may not carry over cleanly to the other. Sometimes information is left behind. Sometimes it arrives, but its meaning has changed.

Simply Plural shutting down made the stakes visible. People had built up years of information about their Systems: members, front history, groups, custom fields, notes, privacy settings, avatars, and the record of how they understood and organized themselves. That experience showed why a usable way to move data matters both when someone chooses a different app and when an app goes away.

A shared format can give apps a common way to exchange that information. The question is what the format can hold. If it only describes the simplest version of a System, then people who use richer structures may have to give something up to move their data.

We want simple apps to remain simple. A small tracker may only need Systems, members, groups, and fronting. It should be able to work with those parts without implementing every feature another app supports. At the same time, the format should leave room for richer information, so an app that can represent it can carry it forward.

That means a reader should be able to use what it understands and handle the rest responsibly. When practical, it should preserve unfamiliar information so another app can make sense of it later. It should tell the user when something was skipped, transformed, or kept in an archive. Quietly discarding information or flattening it into a different shape makes a move look successful while concealing what was lost.

Extensible formats such as TIFF offer a useful analogy. TIFF uses tags to describe properties of an image file. A TIFF reader can recognize the tags it understands and move past unfamiliar ones. The TIFF spec describes only how an image is stored; it does not impose a format that the image must conform to. In that same light, the plural spec should describe the data payload; it should not enforce a specific shape of that data payload. Apps can support different levels of complexity while giving information outside an app’s current model a place to go.

This matters in ordinary cases, not only unusual edge cases. Some people have more than one fronter at a time. A historical front entry may refer to a member who has since been deleted. Custom-field definitions and their values may be stored separately, and both pieces are needed to preserve what the field meant. An empty note title or object may still be valid data. Archived members may have information that explains why or when they were archived.

These examples came into view while working with real exported data and importer edge cases, including cases surfaced through Joshua Reid’s Lighthouse-DID Hub work. They are reminders that a format has to account for the records people actually have, including records that are incomplete, old, or connected to things that no longer exist.

There are also structures that some plural apps support and others may not. One account may contain multiple Systems. A member may belong to more than one System. A role may apply to a person’s membership in a particular System rather than to that member everywhere. Systems may be related as parent and child, siblings, or in other ways; those relationships may be uncertain, changing, archived, or better represented as a network than a single tree.

Structure, access, privacy, authority, focus, and fronting describe different things. A format should give them room to remain distinct, so an app does not have to squeeze one concept into a field meant for another.

No app needs to display or support every part of that model. The format’s job is to let apps exchange the information they do support, while giving unsupported information a safe way to survive the trip. A simpler app can read the common records and leave unfamiliar structures intact. A more capable app can use those structures. The user moving their information should be told what the receiving app did with it.

We see one shared, extensible format rather than a separate PluralBridge format layered beside it. The format should be useful and usable across apps, and it should be able to preserve the kinds of information PluralBridge already supports. We intend to support import from the shared format, and we want to support full export as well.

Good import and export also need examples that reflect real use. Test files should include multiple open front entries, unresolved historical member references, timestamp variations, empty-but-valid records, archived members and reasons, custom fields joined to their values, and group or folder mappings. Developers can use those examples to check that an importer handles difficult records consistently and explains its decisions to the person using it.

For plural people, the practical test is straightforward: can you take your information to another app and still recognize the System or Systems you brought with you? A shared format should make that more possible. It should let apps work at different levels of complexity without making the least complex app the limit of what everyone can keep.

Simple apps should be able to stay simple. The information people have built up about their Systems should still have room to travel.

Next time we’ll take a look at why shared standards need public governance.