What PluralBridge is building
A browser-based home for preserved Simply Plural data.
PluralBridge is building the first public release around one practical goal: give users a safe place to land preserved Simply Plural data and keep using it.
Current work covers account setup, import preview before save, member profiles, fronting/history, and recovery support for users without exports, including a confirmed Samsung S24+ path while Pixel 10a and iPhone 16 recovery paths remain in active investigation.
What the first release includes
Legend: ✅ done, 🟨 in progress (basic parts working), ⬜ planned / not started
- ✅ Recovery documentation and scripts: published for local recovery workflows.
- ✅ Public schema and recovery docs: published for outside developer use.
- ⬜ Account and sign-in: identify who is using PluralBridge.
- ✅ Systems membership boundary: resolve which Systems an account can access.
- ✅ Roles and permissions: enforce role-based access for private System data actions.
- ⬜ Import preview: review preserved data before writing anything.
- ✅ Member profiles: view, add, and update profiles in the browser.
- ⬜ Fronting and history: view and update fronting status with usable history.
- ⬜ Custom fields: preserve and edit custom field data from imported records.
- 🟨 Consent and audit trails: basic tracking is in place; fuller coverage is still being built.
- ⬜ Privacy controls: keep private System data under user control.
Recovery progress
Legend: ✅ done, 🟨 in progress (basic parts working), ⬜ planned / not started
- ✅ Samsung Galaxy S24+ structured extraction: confirmed and documented.
- 🟨 Samsung Galaxy S24+ avatar mapping: extraction evidence exists; full member-to-avatar mapping is still being built.
- ⬜ Google Pixel 10a recovery path: investigation in progress.
- ⬜ Apple iPhone 16 recovery path: investigation in progress.
- ✅ Public recovery references: recovery docs and schema references are published for outside developers.
How recovery work affects app development
Data recovery work has consumed meaningful engineering time that would otherwise be spent only on app features. That work is still necessary because users without exports need a realistic path to keep their data.
Current active recovery investigation includes Pixel 10a and iPhone 16, while Samsung S24+ structured extraction is already confirmed. Recovery and app development are moving in parallel, but the split effort affects pace.
Systems and head-mates
Systems, Memberships, Roles, and Privileges
PluralBridge separates structure from authority.
🧩 System describes how plurals are organized.
👪 Membership describes which headmates and subsystems belong to a System.
🪪 Roles describe what system(s) and/or headmate(s) are allowed to do.
🔑 Privileges grant specific exceptions that allow designated System(s) and/or headmate(s) to perform otherwise denied actions (such as add, edit, or delete) on a target System or headmate, based on the roles assigned to those System(s) and/or headmate(s).
For this release, one account works in one active System at a time, while still supporting broader multi-System access over time.
Fronting, profile updates, and contribution actions are controlled by membership, role, and privilege rules, not by structure labels alone.
We currently support the following models:
A person signs in and has one System.
Account
└── System: The Harbor
├── Member: A
├── Member: B
├── Member: C
├── Groups
├── Notes
└── Front historyThis is the default model: one account, one System, members inside it, and one focused System context.
A person has more than one root-level System. Neither root owns the other.
Account
├── System: The Harbor
│ ├── Members
│ └── Front history
└── System: The Observatory
├── Members
└── NotesThis supports a user who experiences two distinct top-level structures. The app treats both as root Systems because neither has a parent relationship.
One System contains or relates to a smaller child System.
Account
└── System: Main House
├── Member: Rowan
├── Member: Tess
└── Child System: The Workshop
├── Member: Kit
└── Member: LarkThe parent/child relationship describes structure. Access and privacy remain governed by membership, consent, and policy.
Two Systems share a common relationship, but neither controls the other.
Account
├── System: Day Team
└── System: Night TeamThis is useful for Systems that see themselves as parallel, cooperative, or operationally separate.
Two Systems are associated without a parent/child shape.
Account
├── System: The Harbor
└── System: The Archive
relationship to The Harbor: "related"This can represent shared history, partial overlap, a past structure, or a loosely connected internal organization.
A member, group, or internal cluster may have its own structure.
System: The Harbor
├── Member: Alex
├── Member: Morgan
│ └── Subsystem: Morgan's Room
│ ├── Member: M1
│ └── Member: M2
└── Member: RaeThis is one model where a strict flat member list starts to run out of descriptive power.
The user knows two structures are connected, and the exact relationship is still forming.
Account
├── System: The Harbor
└── System: North Wing
relationship to The Harbor: "unknown" or "evolving"This preserves reality-in-progress without prematurely naming a relationship.
A System or structure still matters historically, but is no longer active.
Account
├── System: Current System
└── System: Old Map
status: archivedThis helps preserve migration meaning, old fronting records, old notes, and past organization.
Some Systems may have overlapping or cross-linked relationships.
Account
├── System: A
├── System: B
└── System: C
Relationships:
A related to B
B sibling of C
C associated with AThis breaks the ordinary tree assumption and treats structure as a relationship graph.
What still needs to be done
- Finish end-to-end wiring between account, import preview, roles, profile editing, and fronting.
- Expand device recovery coverage beyond the currently confirmed Samsung path.
- Complete avatar recovery mapping where feasible.
- Finalize consent and audit trail behavior before broader preview access.
- Increase test coverage and contributor onboarding for sustainable delivery.
Why browser-based
A browser-based release works across Windows, Mac, Linux, phones, and tablets without requiring one device type.
Cross-platform access still requires strict privacy boundaries, deliberate import review, and clear user control.
How to help
PluralBridge needs developers, reviewers, testers, documentation helpers, accessibility reviewers, security-minded contributors, and privacy-minded contributors.
Use synthetic data for public project work. Do not send or publish real exports, tokens, screenshots, notes, member records, avatars, fronting history, logs, database files, or private System data.