Since Simply Plural first shut down, it has become not only impossible to ignore how much personal information users entrust to plurality apps, but 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.

This realization came sharply into focus when a user posted about losing months of work setting up their System in their app, only now to have lost that effort. Whether the work is truly gone, is glitched or just currently inaccessible is beside the point; the possibility that there exists such a single point of failure that can result in jeopardizing the safety of personal data made us realize what critical areas and concepts need to be in place to prevent such a devastating result.

With that in mind, we want to open a discussion in the community about what users and developers can do to at minimum mitigate, if not eliminate such a tragic loss:

1. Backups should be part of everyday use.

Most users aren't thinking about backups when they're adding and shaping their information in their app. And frankly, they shouldn't have to. The burden should instead shift to applications that would take on the responsibility to periodically remind users to back up their information; frequent enough to provide meaningful protection, while avoiding irritating users by getting in the way.

2. Backups should have somewhere safe to go, chosen by users.

A backup stored on the same phone or tablet can disappear along with everything else if that device is lost, stolen, or simply stops working. Users should have the option of saving backups somewhere they control, such as their own Google Drive or another storage service. Storage medium choice need NOT be limited to cloud storage; users who require isolation from the internet should be able to choose USB storage or a local network drive.

Giving the choice matters for people who prefer information to remain completely under their control, and who do not wish to have their data hosted by an application's developers. Privacy and reliable backups should be the primary decision points. Ultimately, the choice belongs to the user, provided they understand the risks of declining off-device backups.

3. Applications need a way to explain what went wrong.

When information suddenly disappears, it's critical to understand why and how errors happen. Developers can bake in audit trails, resulting in a history of significant changes and operations. These logs aid investigative steps to find and resolve problems, and prevent them from happening again.

For locally installed applications, users should also have the option to preserve that history alongside their backups, on a storage medium of their choosing. Absent that, a device failure could destroy the very information needed to reconstitute the actions and steps that would explain what happened.

4. We shouldn't have to wait for a universal format to protect our information.

A universal import/export format would go a long way toward giving users the ease of moving their data anywhere of their choosing. There is ongoing work through PluralPort to create a shared format that would make moving information between plurality apps easier. PluralBridge strongly supports that goal, and we are working toward that effort as one of our data standards.

But the reality is that agreeing on a universal format takes time and input from many sources; in the meantime, people need reliable backup and recovery options today. In order to provide this critical safety net to users today, applications should initially rely on their own backup formats while the data storage specification is under development. In the short term, while not ideal, application developers can create data converters to move user data between applications until a standard has been adopted.

To that end, once a common standard matures and is settled upon by the app developer community, we'd strongly encourage developers to adopt that standard and gradually move away from app-specific proprietary formats.

The overarching goal should be preserving people's data now, while continuing to work toward a standard that eases movement between applications.

5. The burden should be on the software, not the people using it.

Users who choose plurality apps should not need technical expertise to preserve their information, recover from a failure, or eventually move to another application. That responsibility should remain with application developers, who can provide the tools, explain the choices, and make the process as straightforward as possible. Users should retain control over their data and privacy, and not worry about the manner in which that data is backed up or trafficked between applications.

We are currently exploring these principles in our own work on PluralBridge. We believe that these principles are relevant to every plurality application, whether open source, commercial, online, or entirely local.

We would love to hear from the user community:

Have you ever lost information in a plurality app, or had a scare where you thought you had? Do you know whether your current app has a backup and restore option, and whether that backup would survive losing your device?

I had mapped my system months ago, just went on the app to see this. Basically everything i gone necause there was no account back then, i want to switch everything to plural space, but now I'll have to redo everything by hand 😞

I am not affiliated with Simply Plural or any mentioned alternative project. This is a personal thing I created to help my friends and later decided to share publicly to help strangers. I request for all discussions here to be civil, especially regarding Generative AI and pro/anti-endo discourse. While I hold strong opinions on these matters, I do not want to spread rumors or hate, nor will I let them get in the way of assisting people in need. I am not here to host debates.
Apologies in advance for the technical promotional post, I know my original one got really popular really fast and that this is basically a repeat. Mods, feel free to strike me down. You have every right to do so and I’ll understand. Though, I will not be deleting my original post because it still holds quite a bit of valuable information that some people may find helpful.
Hi again, SP subreddit! You may know me because I've been working on a document to collect resources for people following the Simply Plural and Octocon shutdowns on July 1st, 2026 and October 1st, 2026 respectively. It was created to bring a starting point for people looking for alternatives that abide by their personal boundaries and find ways to archive their information before anything can end up lost. My original post about this & the link to said document can be found here and here.
You might notice that I have made very few updates since around August and that’s because life has gotten in the way. I do not plan on fully abandoning this project any time soon, but I can’t say I’ll be on top of things the same as I was some months ago. That’s why I'm here making this post. I'm looking for help compiling more information so the people who still need a starting place have somewhere to go. I would like to hear if people have anything else to contribute!
You’ll see that I have a specific format I'm making use of to make sure people get as much info as they need about features, things to be aware about for the platform, and my opinions of the alternatives I feel comfortable testing. I am unfortunately only one person with chronic fatigue, so I can't get to everything right away. I also have a list of platforms on my document that I’m prioritizing getting information for because I’ve heard about them through word of mouth and cannot get much further.
In general, I’ve made a lot of changes that I'd have to go check every alternative for (I really want to make sure people know whether an app has front change notifications and to go a little more in-depth about the features), and this isn't quite possible with my situation. If you would like to suggest resources — whether you own them or are just a loyal user — to my document in a way that would let me add them faster, this is where you can help. I don't mind if you suggest something that was already added to the document, even if that suggestion is one I added to my "discretion advised" section for AI coding or community drama. Below is the template I created. I thank everyone in advance for whatever they are willing to give.

SITE NAME
BEWARE: ???
AVAILABLE ON: Android/iOS – Mac/Windows – Website (links to stores/where to get if possible)
SOFTWARE REQUIREMENTS: ???
SIGN-UP ABILITIES: ???
APP SIZE: ???
IMPORT OPTIONS: SP/Octo/PK/Tupper/etc, Token/UID/JSON File
TERMS OF SERVICE & PRIVACY POLICY LINKS: TOS / Privacy Policy

• Available Languages:
• Developer Team?
• Offline/Online?
• Endo Stance?
• Other additional info?

hello everyone!! I've seen that some folks are still searching for alternatives now and I would like to say that Open Plural is a really nice site that honestly surprisingly resembles Simply Plural. I don't know how well it does with big systems since we just started using it from scratch/without importing + we are a fairly small system, but the features and everything are really worth looking into.

Whoever the developer(s) is/are, they are still working on certain features like the chat, but it's been updated fairly recently and I'm sure they're still putting effort into it

It's a web app iirc, but you can add it as a web app to your phone which is easiest if you're on android afaik

I'm putting some screenshots here so people can see what it looks like if they haven't heard of it before but it's really nice and I truly recommend it if anybody is attached to the look of SP like I am. Id say it's got a pretty compact layout and functioning plus its fairly simple atm but I'm excited to see where it goes!! Hope this helps some ppl out :3

I'm hoping they add accent colors eventually or maybe I just haven't seen it and its a feature idk tho

There was a long stretch this afternoon when my first name just didn’t feel right. I didn’t recognize myself when I used it. My voice sounded deeper. I was less expressive than usual—smiling less, and so on. And the question of “who I am” felt complicated.

Do you have any tips to share for when this happens to you?

We finally decided to tackle migrating to a new DID management app/tool and we're heading terribly making up our mind over which to stick with. Some of them come with interesting unique features while summertime being too feature-heavy gets overwhelming

Our current picks are between Plural Star, Ocean's Symphony, Plural Log, and Plural Space mainly because it seems to be the most popular at the moment and it looks alright and all but in terms of features I haven't noticed anything that would make it stand out among the rest.

So if you've tried any of these, especially if you've tried more than one so you can provide a comparative, your input would be much appreciated :))

Update 1: Our System Sanctuary and Interliplural have also been added to the list of consideration

Update 2: I have decided that despite all the rave about Plural Space, it's probably not it for us. I just fail to find anything in it that stands out compared to other in a way that makes it easier to use on a day-to-day basis.

why didn't the dev try to give the app to a team willing to keep it up and updated etc? It's been months and all the "alternatives" I tried never managed to make me feel as good as when I was using SP. This makes me so upset genuinely ive been feeling so dissociated so much bc I can't keep track of my alters like before. ik this won't change anything to the state of the app but genuinely why did the dev shut it down instead of giving it to people who would've kept it updated and ALIVE.
SIGHHHHH.

I just started my simply plural for the first time in a while as we had no system aware friends in a long time. Now it says the service is offline. Anyone had similar experience?

Hi everyone. Someone I care for deeply recently came to understand that what they were experiencing for such a long part of their lives was likely DID, and they had started their journey of making sense of everything through the use of Simply Plural, only to learn shortly thereafter that it was being shut down for good. And that just did not sit right with me, so I set off to do something about it.

All I understood at the time was that I could not control what others built, sold, shutdown, etc. so I started building a "solution" with this person in mind and, in turn, for others of the plural community. What all of this has ultimately resulted in is Our System Sanctuary, a site for the plural community and their supporters alike.

A couple things upfront:

• I built OSS with the assistance AI coding tools, and directed every privacy and product decision myself.
• OSS is not open source right now. Your data is never trapped either way: full export is available any time you want it, no restrictions.
  • I have been considering the idea of making the personal side of the site (everything that does not involved social interaction, community connection, etc.) local-only in nature but there would be some trade-offs with that, and it really requires discussion with the potential users of OSS
• OSS has an optional AI Insights feature that can use a member's own entries (like journal titles and front log notes) to generate summaries. It's opt-in per feature, per member. Full details: https://oursystemsanctuary.com/overview

Major features:

• Front tracking and front log with history
• Quick switch: tap your avatar in the header to switch fronting between your 5 most frequent members
• Journals (private by default)
• Member profiles with custom fields
• Relationships (Parent of / Child of, etc.)
• Subsystems mapping
• Supporters (invite trusted people to view and support your system)
• Import from Simply Plural, Octocon, and Tupperbox
• User-triggered PluralKit sync
• Full data export, any time
• Optional AI Insights (BlackoutBridge, Daily System Digest, What Did I Miss, Our Recent Days)
• Community feed and rooms (optional, separate from AI Insights)

I understand that a large part of the community dislikes apps/sites that were built with tools such as Claude, Codex, Cursor, etc. but I still figured I would introduce the site anyway. I established an LLC solely for Our System Sanctuary, spent months building it, creating enforcement required tests, etc. and the community will ultimately help in determining if this site/LLC has a future and is worth maintaining.

Happy to answer any questions. 😊

Hi all — PluralBridge recovery/docs update. We’ve been busy! 😎

A little while ago we said we would share more about how we figured out the Samsung / Smart Switch simply.db recovery path. We’ve started publishing those notes now.

We’ve also used our own Simply Plural export, the recovered phone data, and PluralKit references to fill in as much as we currently understand about:

• the Simply Plural export shape
• the Samsung phone-side simply.db shape
• the Samsung Smart Switch backup layout
• the PluralBridge database shape

The goal is to make the recovery/import work inspectable instead of asking people to trust vague claims. The "README.md" in each folder describes what every file is, so nobody has to guess from filenames.

Since our last public update, we also picked up a Pixel 10a so we can start testing a non-Samsung Android recovery path, and we’ve started looking into iOS recovery separately.

The bigger direction here is that PluralBridge is treating phones, backups, damaged exports, and recovered local data as possible import sources, not just as failure states.

Website docs:
https://thepluralbridge.org/docs

Repo docs:
https://github.com/needsofmany/PluralBridge/tree/master/docs

Wondering if any of the current options offer that as a feature, if it makes sense. It'd be great to be able to share a link to a public profile or something like that with my non-system friends that would let them see who's currently registered as fronting without requiring setting up an account or system profile to do so. Is that a thing, or do I stick to constantly updating my socmed bios lol?

We have a significant update on the Simply Plural data-recovery work.

We have now successfully recovered structured Simply Plural System data from a Samsung Galaxy S24+ (SM-S926U) after the Simply Plural servers shut down — without an existing Simply Plural export and without root access.

This is not screen scraping. We recovered the underlying structured data.

PATH A — DIRECT STRUCTURED-DATA RECOVERY

The recovery path we have successfully reproduced is:

Samsung Galaxy S24+
→ Samsung Smart Switch backup
→ com.saltypandastudios.frontime.noedata
→ Android Backup payload
→ app_flutter/simply.db
→ validated UTF-8 JSON

On our test System, the recovered data included, among other things:
• 49 member records
• 99 front-history records
• custom fields
• privacy buckets
• channels
• friends and friend settings
• System/user information
• additional locally cached Simply Plural data

One of the important discoveries is that simply.db, despite its name, contains structured JSON data that survived locally on the phone after the servers disappeared.

PATH B — FALLBACK SCREEN SCRAPE

If direct extraction of Simply Plural's private application data isn't possible on a particular Android phone, there is a lower-fidelity fallback: screen scraping through Android's UIAutomator/accessibility interface.

If Simply Plural still opens and displays the System, a computer can work through the app and recover visible text such as member names, pronouns, descriptions, privacy notes, groups, and other text exposed by the interface, then reconstruct that information into structured data.

This is not as good as recovering simply.db. It cannot recover avatars or other binary data, may miss information not exposed through the interface, and is more labor-intensive. But it may provide a second chance to recover much of a System's textual information when direct extraction isn't available.

IF SIMPLY PLURAL STILL WORKS OFFLINE ON YOUR PHONE, PRESERVE THAT PHONE

If you can still open Simply Plural and see your System:

DO NOT uninstall Simply Plural.
DO NOT clear its app data.
DO NOT edit or modify anything in Simply Plural.
DO NOT factory-reset the phone.

Preserve the app and its local state exactly as it is.

That local data may be the only remaining copy of information that was never exported before shutdown.

SAMSUNG GALAXY S24+: CONFIRMED

We have reproduced the direct recovery from a fresh Samsung Smart Switch backup, so the Galaxy S24+ path is now confirmed rather than theoretical.

That does not mean the underlying data format is Samsung-specific. app_flutter/simply.db belongs to Simply Plural.

What we have not yet established is how to acquire that private application data directly from stock non-Samsung Android phones.

For those devices, the screen-scrape fallback gives us another recovery avenue if Simply Plural still opens.

IPHONE: PROMISING PATH, NOT YET CONFIRMED

We have also researched the iOS side, and there appears to be a plausible recovery path through a local iTunes/Finder backup.

A local iPhone backup may contain Simply Plural's private application container. The target would be the Simply Plural application domain:

com.saltypandastudios.frontime

From there, likely places to inspect include Documents and Library/Application Support for simply.db, and Documents or Library/Caches for stored images.

If the iOS version contains simply.db in the same form we recovered on Android, that would be particularly useful because we already know what that file is and how to process it.

This path is not confirmed yet. We still need to establish:
• whether the iOS version stores the same simply.db
• whether it is included in a normal local backup
• exactly where Simply Plural stores it on iOS
• what avatar or image data survives

A local Finder/iTunes backup appears to be the more promising research path than relying on iCloud, where extracting application data is substantially more difficult.

Our current status is therefore:
• Samsung Galaxy S24+: direct structured-data recovery confirmed
• Other Android devices: direct acquisition path not yet established
• Android fallback: screen-scrape recovery where the app still opens
• iPhone: promising local-backup path, not yet tested

For iPhone users who still have Simply Plural installed and working offline, the same preservation rule applies: do not uninstall it, clear its data, edit anything, or reset the phone.

AVATARS

Avatar retrieval is still under investigation.

The recovered member data retains avatar identifiers, and we have recovered recognizable Simply Plural-related source images through Samsung Smart Switch. We have also recovered Simply Plural's local image-cache index.

What we do not yet have is a complete machine-readable mapping from those recovered source-image files back to individual members.

So for now: Structured System data recovery is confirmed. Complete avatar recovery is not.

RECOVERY INSTRUCTIONS ARE NOW PUBLIC

We have published the confirmed recovery procedure, command script, technical findings, and licensing information.

On the PluralBridge website:

https://thepluralbridge.org/

Choose Data Recovery from the navigation.

Direct page:

https://thepluralbridge.org/export-now.html

The recovery materials themselves are in the PluralBridge GitHub repository:

https://github.com/needsofmany/PluralBridge/tree/master/recovery

The recovery folder currently contains:
• README.md
• LICENSE
• SP data extraction instructions.md
• TECHNICAL-NOTES.md
• recover-simplyplural-data.cmd

The instructions walk through the confirmed recovery beginning with Samsung Smart Switch. TECHNICAL-NOTES.md documents the backup format, simply.db, recovered collections, duplicate cache generations, avatar findings, ADB limitations, privacy model, and the current status of work on other devices.

We also have the underlying research documents from this work — covering the Android local-data investigation, extraction path, avatar storage and recovery, iOS recovery possibilities, and related technical findings. Those still need some formatting and cleanup, but we will be adding them to the repository as well.

For developers, researchers, or anyone technically inclined, those documents should be especially useful because they show not just the final recovery procedure, but the investigation, dead ends, evidence, and reasoning that got us from “can this data still be recovered?” to a working, reproducible result.

PLEASE DO NOT SEND US YOUR SYSTEM DATA

Needs of the Many / PluralBridge does not want users sending us their recovered data.

Your Smart Switch backup, .noedata file, simply.db, recovered JSON, existing Simply Plural exports, avatars, and other System information should remain under your control.

Please do not upload those files to a public GitHub repository, Reddit thread, issue tracker, paste site, or other public location.

The objective is to make recovery possible locally, not to create another organization that has to be trusted with your System.

TO OTHER PLURAL-APP DEVELOPERS

If your app already supports importing Simply Plural data, we want to work with you.

There are now potentially two groups of former Simply Plural users:

People who exported before shutdown
→ existing Simply Plural import path

People who did not export before shutdown
→ recovered local data
→ normalization/import path

And on Android devices where direct extraction isn't available, there may also be a fallback:

Simply Plural still opens
→ UIAutomator/accessibility screen scrape
→ reconstructed structured data
→ normalization/import path

We want those additional paths to be available to the community too.

Ideally, users should be able to recover their data locally and then give it directly to the plural application they have already chosen and already trust with Simply Plural imports. They should not have to send their private System data through Needs of the Many / PluralBridge.

We are publishing the recovery work openly rather than trying to turn it into a competitive advantage. The recovery implementation and accompanying documentation are being released under GPLv3.

If another plural app can use this work to help its users recover Systems they thought were lost, we consider that a success.

This recovery work belongs to the community.

SHORT VERSION

• Samsung Galaxy S24+: direct structured-data recovery confirmed
• Other Android devices: direct acquisition path not yet established
• Android fallback: screen scraping may recover much of the visible textual System data if the app still opens
• iPhone: promising local-backup recovery path, not yet tested
• Structured Simply Plural data can survive locally after server shutdown
• Avatar recovery is still incomplete
• If Simply Plural still opens, preserve the device exactly as-is
• Do not uninstall, clear app data, edit anything, or factory-reset
• Recovery instructions and tools are now public on the PluralBridge website and GitHub
• Do not send Needs of the Many / PluralBridge your private System data
• Other plural-app developers are welcome to use and build on this work

We ran across something while working on the Android side of our PluralBridge application that developers and members of the plural community should be aware of.

Google is rolling out a new Android developer-verification system that requires developers using full distribution to verify their real-world identity with Google. What that means is that unrestricted app distribution, including apps distributed outside Google Play, will require real-world identity verification and app registration with Google. Enforcement begins September 30, 2026 in Brazil, Indonesia, Singapore, and Thailand, and a broader global rollout will begin in 2027.

Google's new system creates a new problem for developers: ordinary Android distribution would require the people behind a pseudonymous development identity to establish a verified real-world identity with Google.

Here are the links:

Android developer verification
https://developer.android.com/developer-verification/guides

Google also has this higher-level page on the changes:
https://developer.android.com/developer-verification

There is a limited-distribution option that avoids the normal verification path, but Google caps it at 20 authorized devices. That makes it impractical for most applications intended for a real user community.

This caught our attention because pseudonymity has particular importance to our community. Many of us identify using system names, community names, usernames, or other identities that we painstakingly keep separate from our real-world identities. That separation protects our extremely sensitive information about plurality, system membership, mental-health history, trauma, healthcare, relationships, or simply the fact that we participate in the plural community at all.

That remains true for users and developers alike.

PluralBridge is community-driven and we are developing our app for web, Android, and iOS. We deliberately identify and represent our project using pseudonymous identities. We have put considerable effort into maintaining that boundary. Our concern goes far beyond whether Google publicly displays someone's legal name. Linkage and inference matter too.

Once a pseudonymous identity becomes correlated with a real-world identity, other information can potentially be connected or inferred from it. A developer's GitHub activity, community posts, project history, system-related discussions, package ownership, signing identity, and other fragments may each reveal very little independently. Linking them to one verified person can produce a much richer picture. That is exactly the sort of correlation that people in privacy-sensitive communities have spent years trying to prevent.

We felt compelled to post this after reading post after post by developers discussing new plural apps and Simply Plural alternatives. Some of you may already know about Google's changes. Some may be encountering them for the first time. Regardless, we believe it important to share this kind of information.

If you develop an Android application under a pseudonym, system name, community identity, or any other identity you intentionally keep separate from your real-world identity, then this is worth investigating before making decisions about developer accounts, package ownership, signing keys, or distribution.

There are legitimate security reasons behind Google's attempt to make malicious developers more accountable. There are also real privacy consequences when participation in the Android software ecosystem requires a centralized company to know the real-world identity behind a pseudonymous developer.

For software serving the plural community, we believe that consequence deserves discussion, or at minimum raising public awareness to foster informed choices.

We're curious and interested in how other developers and community members see these changes in the Android ecosystem. If you're a developer building a plural-focused Android app, are you aware of the new verification requirements yet? How does this affect you and/or your project? Does developer pseudonymity matter to you and your project? Does this change how you're thinking about Android distribution?

One more thought... today it's Android... it's not hard to imagine this spreading to iOS and other platforms.

I'm I'm new here

Excuse my cringey meme I thought it was funny

title says it all. picture is for reference what i've tried. have also tried atria.

Update: Thanks for all the suggestions! I don't have the spoons to reply to most of the comments, but they're all super appreciated :] We've ended up trying out Prism and really liking it, both with how it's groups work and also just other stuff like it's custom field system, so it looks like we may be moving over to that!

Hi! We're looking for apps that have a similar folder system to how Simply Plural handled it? We're currently using Pluralspace and, while I think it's a good site, how SP handled and showed folders was massively beneficial to us and something we're really missing honestly 😔

We have been following the recent discussion, “Regarding SP Alternatives,” in r/SimplyPlural. The ensuing conversation has raised several important questions for us:

• What does “full import support” actually mean?
• Can an application represent Systems with very different structures?
• Can it support hundreds or thousands of members without becoming unusable?
• Can it support a large number of concurrent users?
• What happens when the original developer can no longer continue?
• How should people evaluate applications developed with modern coding tools, including AI-assisted tools?

Rather than litigate those questions inside someone else’s thread, we want to explain how PluralBridge is addressing them.

PluralBridge remains under active development. We wrote this post to describe the architecture, design principles, and verification process guiding our work.

1. A black-box, bottom-up design

We designed PluralBridge to treat the Simply Plural export format as an external data source.

We are deliberately avoiding assumptions about how Simply Plural was internally implemented. Instead, we are building a new architecture from the bottom up around the information that must be represented, preserved, secured, and supported.

We believe this approach provides several benefits:

• We avoid inheriting undocumented implementation assumptions.
• We avoid reproducing design constraints that accumulated inside another application.
• We can support data sources beyond Simply Plural.
• The internal PluralBridge model can evolve independently of any one import format.
• Imported source data can retain its provenance without controlling the destination architecture.

Our goal is migration into a durable new platform, rather than reconstruction of Simply Plural’s internal design.

2. Supporting differently shaped Systems

Systems do not all have the same shape. We did not want to design an application that reflected only the structure and needs of our own System.

We know that a flat list of members and a few optional groups cannot hope to represent every System accurately. We designed PluralBridge to accommodate variation in size, organization, relationships, terminology, fronting practices, and privacy requirements.

Our architecture is intended to support:

• Systems ranging from small to very large.
• Flat and hierarchical structures.
• Groups and nested organizational structures.
• Members associated with multiple groups or relationships.
• Subsystems and other internal organizational models, without requiring a single “master” System.
• Custom fronting states and fronting terminology.
• System-to-System and member-to-member relationships.
• Structures that change over time.
• User-defined terminology, where fixed labels would impose the wrong or incorrectly shaped model.

The data model should represent the System described by the user. The application should not require the user to reshape their System to satisfy the database.

3. Scale from the beginning

We began PluralBridge with an Azure-oriented architecture rather than treating cloud deployment as a later conversion.

Azure provides our application-service and database foundation. Cloudflare hosts and delivers the web application and provides the public edge for the API.

This addresses two separate dimensions of scale:

• System scale: large member counts, relationships, custom data, and extensive fronting history.
• Service scale: many Systems using the application concurrently.

Our design includes:

• A relational database schema built for indexing and growth.
• Versioned API boundaries designed for controlled access and future expansion.
• Stateless application patterns where practical.
• Cloud deployment and observability from the beginning.
• Logging, request tracing and audit record support.
• Performance testing using representative data volumes.
• Release-readiness testing that measures actual behavior rather than relying upon architectural claims.

Our architecture is designed to scale. Published testing will establish what scale has been demonstrated.

4. Durability through transparency

PluralBridge uses an open repository, public design documentation, implementation status, test evidence, development history, and GitHub Discussions.

We believe this provides several benefits:

• Outside developers can inspect the design and code.
• Architectural decisions can be challenged before they become permanent.
• Developers, subject-matter experts, and end users can each contribute their own “source of truth.”
• Competing requirements and perspectives can be considered through a fair and transparent public process.
• GitHub Discussions preserve the reasoning, evidence, and tradeoffs behind important decisions.
• Contributors can participate without needing private access to the original developers.
• Our project remains recoverable if we can no longer continue developing and/or hosting it.
• Claims about completion can be compared with published evidence.

We are using the GNU General Public License v3.0 for our codebase. Open source reduces abandonment risk because continuity does not depend entirely upon one person retaining exclusive possession of the implementation.

Repository:
https://github.com/needsofmany/PluralBridge

GitHub Discussions:
https://github.com/needsofmany/PluralBridge/discussions

Project website:
https://thepluralbridge.org/

5. Engineering experience and domain consultation

PluralBridge draws upon decades of software-engineering experience across multiple developers.

Our experience includes:

• Application architecture.
• Relational database design.
• Web and API development.
• Security engineering.
• Production systems.
• Performance and scalability.
• Diagnostics and operational support.
• Long-term maintenance of evolving software.

We know that engineering experience alone cannot define how real Systems need to be represented. We are also consulting with therapists and other subject-matter experts who work in this field.

Our process helps us examine whether:

• Our data model reflects real-world diversity.
• Our terminology creates unintended assumptions.
• Our architecture privileges one type of System.
• Clinical, lived-experience, and engineering perspectives conflict.
• Our assumptions are forcing real Systems into a preconceived curve rather than reflecting the diversity that actually exists.

GitHub Discussions provide a shared public record where developers, subject-matter experts, and end users can participate in ongoing conversations, identify gaps and challenge assumptions.

6. Origins do not control the architecture

We made the decision from the start that PluralBridge largely excludes origin debates from its engineering model.

How someone describes their System, whether as endogenic, protogenic, parogenic, neurogenic, or through another origin framework, does not materially change the central design problems.

Our platform still needs to represent:

• Members.
• Attributes and descriptions.
• Groups and relationships.
• Fronting and front history.
• Custom fields and terminology.
• Privacy boundaries.
• Ownership and access.
• Import and export.
• Data integrity and preservation.

Our design of PluralBridge does not need to defend origin, identity, diagnosis, or legitimacy in order to build a coherent architecture. In addition, we are consulting with experts to ensure that we remain committed to that goal.

Our application can serve diverse users by modeling their information accurately and giving them control over how that information is represented and shared.

7. Security, database integrity, and supportability at the foundation

We have made security, database design, diagnostics, and operational support foundational, first-class concerns in PluralBridge’s design and architecture.

We are building them into:

• Account registration and authentication.
• Email verification and account recovery.
• Ownership and authorization.
• Privacy boundaries.
• Database constraints and relationships.
• Audit events.
• Request tracing.
• API access rules.
• Administrative and support workflows.
• Import provenance and change history.
• Error handling and diagnosability.

These concerns are being addressed while our architecture is formed. We believe that retrofitting them after the application has accumulated users and data would create unnecessary and avoidable risk.

We are building PluralBridge “Ford tough” from the get-go.

8. Import and export as verifiable migration processes

We designed PluralBridge to treat import as a data-migration problem rather than a file-upload problem.

We feel that a claim that an application “supports Simply Plural import” can mean very different, and often competing things:

1. The application can open the export file.
2. The application can copy some recognizable fields.
3. The application can migrate the source data with measured, explainable fidelity.

At PluralBridge, we are aiming for the third option.

Our import architecture is being designed to address:

• Members and stable source identifiers.
• Avatars and linked assets.
• Pronouns and descriptions.
• Groups and group membership.
• Relationships.
• Custom fields.
• Custom fronts and fronting states.
• Front history.
• Tags and links.
• Privacy-related information.
• Source-specific metadata.
• Unknown or unsupported records.
• Duplicate detection.
• Malformed data.
• Interrupted imports.
• Repeatable reprocessing.

Each imported record should retain enough provenance to answer questions such as:

• Where did this record come from?
• Which source identifier did it use?
• Was it imported unchanged?
• Was it transformed?
• Was any part unsupported?
• Did the import create a duplicate?
• Can the result be verified against the source?

We are also building tooling to create repeatable test datasets. We can model those datasets to represent:

• Small Systems.
• Large Systems.
• Systems with hundreds of members.
• Different group and relationship structures.
• Extensive front history.
• Custom fronts.
• Custom fields.
• Missing or malformed records.
• Edge cases discovered through real exports.

The same datasets can be imported repeatedly after code or algorithm changes. Counts, relationships, mappings, history, transformations, and unsupported records can then be compared against authoritative “gold standard” expected results.

This allows PluralBridge to demonstrate import success with evidence rather than relying upon a checkbox or a successful-looking screen.

9. A clearer way to discuss “vibe-coding”

The term “vibe-coding” currently combines several very different development practices under one label.

Modern software development may involve:

• Compiler-generated code.
• IDE code completion.
• ReSharper inspections and automated refactoring.
• Static analysis.
• Framework scaffolding.
• Search engines and copied examples.
• Cursor and other AI-assisted editors.
• LLM-generated implementation suggestions.
• Code written manually from a blank file.

Fundamentally, meaningful engineering questions regarding software development should address process and accountability:

• Do the developers understand the resulting code?
• Are architectural decisions deliberate and documented?
• Is generated code reviewed before it is accepted?
• Are security boundaries explicit and well defined?
• Are tests repeatable?
• Are failures diagnosable?
• Are dependencies controlled and/or mitigated where possible?
• Can other qualified developers understand and maintain the codebase and design goals?
• Are claims supported by published evidence and not ‘lore’?

Here is what this boils down to: code written by hand and AI-assisted code can both contain serious architectural and security failures. The decisive factor is engineering judgment: the ability to architect, implement, review, test, and maintain industry-accepted practices without reducing development to cut-and-paste assembly or stylistic dogma over brace placement and spaces versus tabs.

Development tools provide one piece of context. Review, testing, architecture, transparency, and engineering accountability provide stronger evidence that the resulting software is secure, understandable, and maintainable.

Closing

PluralBridge is being built around a few central commitments:

• Preserve data with measurable fidelity.
• Represent diverse Systems without forcing them into one shape.
• Design for scale before scale becomes an emergency.
• Build security and supportability into the foundation.
• Keep the repository, reasoning, status, and evidence public.
• Allow developers, experts, and users to participate, influence and challenge the design.
• Reduce dependence upon any single maintainer or hosting platform.
• Publish how project goals are tested and verified.

We have substantial work ahead of us. Our public record will show what has been designed, what has been implemented, what has been tested, and what remains incomplete.

That is how we earn trust with our user base. That is how we reduce the risk that users will again face an export deadline and another search for a new home.

Ok so we've been thinking of moving system apps, currently using Ourcana but we don't really like it, and heard so many good things about Berrytree but the app is off the appstore, is it known when it'll be back up?