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:
Protect user data immediately through reliable application-specific backup and restore.
Provide converters and adapters where feasible to support migration between existing formats.
Continue developing and refining a shared interchange specification.
Encourage broad developer adoption as that specification becomes sufficiently mature.
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.