Marketplace trust model
What a signature actually proves.
Signed, verified, reviewed and permissions are security words, and security words are worth nothing without their limits attached. This page is the limits. Where the honest answer is that something is not built yet, it says that.
Where this stands
Eight questions, answered before you ask them.
A trust model that only describes the finished parts is marketing. This is the whole board, including the empty squares.
What this means for you, concretely: this model covers plugins you install from the Quox store onto your own QuoxCORE.
The safe sequence today: read the plugin's permission list on its store page before buying; prefer first-party plugins while third-party review does not exist; after installing, watch what it actually does in the activity view; and treat any bundle you have not reviewed as code you are choosing to run.
- ShippedSigning keys and a signerAn Ed25519 keypair and a command that signs a package. Both ship in the SDK today.
- PartialSignature checked on installCryptographic verification runs only when the organisation has pinned at least one publisher key. With no pinned keys, the installer reads the signature file for shape and accepts unsigned packages.
- Not builtA publisher registry or trust rootThere is no certificate authority, no identity binding and no central key directory. Trust is a key an admin pasted into their own instance.
- Not builtKey revocation, expiry and rotationNo revocation list, no expiry date, no rotation endpoint. If a key is compromised, every admin who pinned it has to delete it by hand.
- PartialAutomated submission checksThe gate is written and runs on submission. Nothing has been submitted through it, because listings are not open.
- Not builtHuman review of submissionsThe approve and reject endpoints exist and belong to the instance administrator. There is no reviewer interface and no Quox review team reading submissions.
- Not builtMarketplace listings and paymentsNowhere to browse, nothing to list, no checkout. Paid plugins return a 402 by design.
- PartialPermissions enforced at runtimeThree of the seven declared permissions are enforced by the plugin API gate. The other four are declarations the runtime does not currently check.
Signing
Ed25519, over the manifest.
The SDK generates an Ed25519 keypair and signs a package with the private half. What gets signed is the manifest: the tool sorts it into a canonical form, drops any signature already in it, takes the SHA-256 of that, and signs those bytes. The result lands in the package as signature.json, alongside the key id, the digest and the algorithm.
So the signature covers the manifest, not the compiled bundle. That is a narrower guarantee than the word signed usually implies, and it is worth knowing before you rely on it.
The server-side verifier is stricter: it checks a signature against the hash of the package bundle itself. The two are not interchangeable today, which is a gap on our side rather than a choice, and it is on the list to close.
What a valid signature tells you: the package matches what the holder of that private key signed. What it does not tell you: who that holder is. There is no identity behind the key beyond the label whoever pinned it typed in. Treat a signature as tamper-evidence between a publisher you already decided to trust and your instance, not as proof of who the publisher is.
Key trust and revocation
Trust is a key your admin pinned.
How a key becomes trusted
An administrator adds a public key to their own organisation, with a label, from the dashboard or with quox plugin trusted-keys. That list is local to that organisation on that instance. There is no shared registry, no certificate chain and no vetting step between a developer generating a key and an admin pinning it.
The moment an organisation pins its first key, its policy tightens: from then on a package must carry a valid signature from a pinned key to install. Until then, unsigned packages are accepted, which is a deliberate compatibility default and one worth changing on any instance that installs third-party code.
Revocation: not built
There is no revocation list, no key expiry, and no rotation endpoint. The stored key record has no state to set: a key is either in an organisation’s list or it is not.
If a publisher’s signing key is compromised, the only remedy today is that every administrator who pinned that key deletes it, on every instance, by hand. Deleting it does not touch plugins already installed from it.
Until that changes, pin keys sparingly, and prefer publishers you can reach if something goes wrong.
Review
Who reviews submissions today: nobody.
The machinery exists in code. The process around it does not, because the marketplace is not open for listings. Saying otherwise would be the exact thing this page is for.
Automated checks · written and running
Submitting a package runs a gate that checks:
- The package is a valid ZIP
- Total size within 5MB, and no single JavaScript file over 100KB
- A manifest exists, parses, and carries its required fields
- The plugin id matches the required format and avoids reserved prefixes
- The version is valid semver
- The bundle is free of a blocked-pattern list
It does not verify a signature. The developers page used to say it did. That has been corrected.
Human review · not staffed
Approve, reject and request-changes endpoints exist, and they belong to the administrator of an instance rather than to a Quox reviewer. There is no reviewer interface, no queue anyone is working, and no submissions, because there are no listings to submit to.
What actually happens today: a developer hands a customer a .quoxplugin file, and an administrator installs it. Distribution is a direct agreement, not a storefront.
When listing does open, review will not become a security audit, and we will not describe it as one. The marketplace terms already say this: review is not an endorsement, a guarantee, or a substitute for your own assessment of code you are about to run. Marketplace terms →
Permissions
Seven declarations, three of them enforced.
A plugin lists the permissions it wants in its manifest, and the installer shows that list before you accept. Here is what each one opens, and whether the runtime currently holds it to that.
networkOutbound HTTP, routed through the QuoxCORE gateway rather than fired directly from the browser.EnforcedmemorySave to and search the memory service.Enforced, but the calls behind it return not-implemented today.aeeEmit an AEE envelope onto the evidence chain.Enforced, but the call behind it returns not-implemented today.storageBrowser storage on the viewer’s own machine, namespaced to the plugin.Not checked. The facet is handed over whether or not it was declared.notificationsRaise a notification in the dashboard.Not checked.sidebarA navigation entry and a route inside the dashboard.Not checked. Registration happens before any permission is read.toolsRegister an agent tool, which agents can then call.Not checked. Registration happens before any permission is read.Read this before you install anything
Treat the permission list as a statement of intent, not a sandbox. Four of the seven are not checked by the runtime, so a plugin that declares only sidebar can still reach the facets it did not ask for. Installing a plugin is best understood as granting it the whole plugin API surface, which is why installing is restricted to organisation administrators.
There are also two permission names the runtime gates that are missing from the documented seven: durable, a server-side store scoped to your organisation, and secrets, an encrypted secret store for the plugin.
They work, they are enforced, and the installer will show them as bare strings with no description because the documentation has not caught up. If you see either in a manifest, that plugin is asking for server-side persistence.
Making the declared list authoritative, so that a manifest is a real boundary rather than a description, is the change that matters most here. It is a platform fix, not a documentation fix, and until it lands this page will keep saying so.
What to do with this
Two short lists.
If you run an instance
- Pin a publisher key before you install third-party code, so unsigned packages stop being accepted
- Pin as few keys as you can, and know who is behind each one
- Read a plugin’s code, or trust the person who gave it to you. Neither the signature nor the review queue does that for you today
- Keep installing an administrator-only action
If you are publishing
- Generate a keypair and sign your packages now. The building blocks are real even though the storefront is not
- Declare the permissions you actually use, and expect that to start being enforced
- Distribution today is a direct conversation with us and with your customer, not a self-serve listing
- Start with the SDK →
This page is maintained against the code, not against the roadmap. When one of the not-built rows above becomes shipped, it changes here first. Back to developers →