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.

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.

Registered apps

Adoption status
prismsheafsimply_pluralpluralkitoctoconplural_starlighthouseopenselvesampersandpluralspace