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.