julIDE plugin registry

The plugin registry for julIDE.

It stores a name, some metadata, and a pinned sha256 for each plugin version. The code itself lives in each author's own repository. Submissions arrive as pull requests; CI does the deterministic checks; a human looks at the rest.

Read docs/TRUST.md before installing anything from here. It says what being listed does and does not mean, plainly.

Using it

julIDE fetches one file:

https://raw.githubusercontent.com/Julideorg/julide-plugin-registry/master/registry/index.json

docs/CLIENT.md is the contract a client has to implement for the registry's guarantees to actually hold.

Publishing a plugin

bun run pack                                      # build a conformant tarball
bunx github:Julideorg/julide-plugin-registry \
  new-plugin --tarball <its published url>        # writes plugins/<name>.json
bun run submission                                # the same checks CI runs

Then open a pull request touching only plugins/. Full walkthrough in docs/PUBLISHING.md; the rules are in docs/POLICY.md.

Layout

plugins/<name>.json     one entry per plugin — the only files a contributor writes
registry/index.json     generated; the single file julIDE fetches
registry/revocations.json + .minisig
                        the signed advisory feed, and its detached signature
schema/                 generated JSON Schema, for editor autocomplete
src/                    pure logic — no network, no filesystem, exhaustively tested
vendor/                 byte-for-byte copies of julIDE source (see upstream.json)
scripts/                the CI gates and the submitter tooling
docs/                   trust model, policy, publishing, revocation, client contract

Development

bun install
bun test                # the pure core
bun run typecheck && bun run typecheck:test
bun run lint && bun run format:check
bun run check:upstream  # vendored files still match their recorded hashes
bun run check:drift     # julIDE has not moved out from under us
bun run submission      # everything a pull request is judged by
bun run publish         # rebuild + sign the index, after merging (needs the offline key)

src/ never touches the network or the filesystem — that is deliberate, and it is what lets the whole trust path be tested with no fixtures beyond bytes. The one impure module is src/download.ts.

Why this shape

An earlier attempt at a hosted marketplace — HTTP API, Postgres, publish CLI, sandboxed scanner — was scrapped because one person cannot maintain it. This is what survives that: the deterministic checks, which cost nothing to run, and none of the infrastructure, which cost everything to keep alive.

What was lost with the scanner is worth naming. There is no static analysis of submitted code beyond a pattern pre-gate, and no detonation. The registry's claim is narrower and more durable: the bytes you download are the bytes that were reviewed, pinned in public git history, with a signed kill switch that works even if this repository does not.

docs/UPSTREAM-FINDINGS.md is the security review that came out of that attempt. Its findings drove julIDE's plugin sandbox, and it is kept here because the reasoning is still the clearest statement of why a permission list is not a boundary until something enforces it.