PluralPort - draft v0.1
A shared file format for plurality apps.
Most plurality apps store the same kinds of data: members, systems, fronting history, custom fields, and notes. The problem is that they don’t agree on the shape. PluralPort gives apps one common export and import format, instead of a pile of one-off converters.
{
"pluralport_version": "0.1",
"producer": { "app_id": "sheaf" },
"members": [
{
"id": "01J8Z9...",
"name": "wren",
"pronouns": "they/them",
"privacy": { "level": "trusted" },
"source_refs": [
{ "app": "sheaf", "id": "mem_4482" }
],
"extensions": { "sheaf": { "tint": 3 } }
}
],
"warnings": []
}Apps keep their own model
PluralPort is a format, not a schema rewrite. Apps keep their internal structure and agree on the export shape.
Modules can be partial
Importers don't have to support everything. capabilities.modules tells you what a file contains.
Nothing gets silently lost
Original IDs stay in source_refs, and app-specific fields live in namespaced extensions.
What the problem looks like
There are a lot of plurality apps, and most of them store the same basic things: systems, members, fronting history, custom fields, and notes. But they do not store them in the same shape. The result is a lot of one-off conversions, and a lot of places where data gets lost, guessed, or silently reshaped.
PluralPort is a common format for exports and imports. It is not a new app and not a service. It is a shared file shape that lets apps move data without rebuilding the same conversion logic over and over.
For apps that do not write PluralPort files yet, the PluralPort Converter turns their own export into one, in your browser, without an account. Its source mappings double as reference implementations of the spec.
Where it stands
A few app maintainers have expressed interest, and the draft is already being checked against real-world app data rather than abstract examples. The current version is draft v0.1: early enough to change, but concrete enough to test.
A few open questions still matter:
- Whether the fronting model covers the edge cases apps actually hit.
- Which optional modules belong in the first version and which should wait.
- Whether the extension namespaces are flexible enough for app-specific fields that haven’t been invented yet.