Publishing a plugin

Who may publish

To publish, your arbastro account needs:

• to be signed in;
• a verified email address ("Verify your email address before publishing a plugin." otherwise);
• two-step sign-in or a passkey ("Add a passkey or two-step sign-in to your arbastro account before publishing a plugin." otherwise).

By submitting, you agree to the Plugin Developer Terms and the Review Guidelines. Read both before your first submission. You can submit up to 20 versions a day.

Before you start

• Give the plugin its real id. Templates start as local.my-plugin. Change id in manifest.json to something that is yours, like yourname.compound-numbers, before the first submission: the id is the plugin's identity for its whole life, and no other account can publish under it.
• Set the version. Plain MAJOR.MINOR.PATCH, such as 1.0.0. Every submission needs a version number you have not submitted before.
• One logic file, one window file. What is uploaded is the manifest, the main file and the ui file. Anything else in the folder is not. Put styles and scripts for the window inside ui.html.
• Keep it readable. Submit the code as written, not one minified line.

Open the Publish window

1. Turn on developer mode (see Build your first plugin) and import or create the plugin, so it runs as a Development plugin.
2. Open the Plugins window (Plugins in the top bar › Browse plugins…, or Main menu › Object › Plugins › Browse plugins…) and choose the Development tab.
3. Select Publish… on your plugin's row.

The Publish window shows a Listing preview on the left, exactly as the directory row will read, and the four steps on the right.

The four steps

1. Describe

Field	Rule
Name	At most 60 characters
Tagline	One line: what it does for a chemist. At most 100 characters
Description	At most 8,000 characters
Category	Export and import, Analysis, Teaching, Reference, Biochemistry, Spectroscopy, Productivity or Fun
Tags	Up to 8, separated by commas

2. Icon and images

Pick the plugin's icon from Athanor's own icon set. The listing preview updates as you choose.

A listing can also carry a gallery of up to 8 screenshots that show the plugin at work. You upload them as the developer, and they appear on the listing once the version is approved.

3. Permissions and data

For every permission in the manifest, say why the plugin needs it, in one line (up to 200 characters). The reason shows on the listing next to the permission. A submission with a permission and no reason cannot be sent.

Then answer the two data questions, which also show on the listing:

• Does it send any document content anywhere? Where?
• Does it store anything? For how long, and who can see it?

4. Details

Field	Rule
Support contact	Required: an email address or a URL, up to 200 characters
License	Up to 60 characters. Starts as MIT
Release notes	Up to 4,000 characters. What changed in this version

Select Submit for review. Until everything required is filled in, the footer says "Still needed:" and lists it.

Automatic screening

Every submission is screened on the server the moment it arrives, before anyone looks at it. The Publish window then shows the checklist, one line per check, and you can see it again later under Development.

Check	If it fails
The id looks like author.plugin-name	Refused
The version is like 1.0.0	Refused
Written for plugin API 1	Refused
It has a name of 60 characters or fewer	Refused
Every permission is one Athanor knows	Refused
The internet permission names its sites, with no *	Refused
The package is 5 MB at most	Refused
No structure in the code is one the safety screen refuses	Refused
The listing text passes the community filter	Refused
No eval or new Function in main.js	Goes to review with the finding
No reaching past the athanor API (importScripts, XMLHttpRequest, WebSocket, indexedDB, localStorage, document.cookie, window.parent, window.top)	Goes to review with the finding
Every http:// or https:// address in the code is a declared site	Goes to review with the finding
The code is readable (not one minified line)	Goes to review with the finding
Every permission says why it is needed	Goes to review with the finding
A support contact is given	Goes to review with the finding
The data questions are answered	Goes to review with the finding

A refused submission is not stored. Fix what the checklist names and submit again. The safety screen looks at every SMILES-like string in main.js and ui.html; a plugin may not ship structures the app itself refuses.

Human review

A first version, and any version that goes to review, waits for a moderator. The moderator sees the checklist, the permissions with your reasons, the data answers, your support contact and your release notes, and then:

• Approve: the version is signed and published.
• Request changes: with a note saying what to change.
• Reject: with a note saying why.

You get an email with the result, and the Development tab shows the status beside the version: In review, Published, Changes requested or Rejected, with the moderator's note. The Review Guidelines say what reviewers look for.

Updates

Submit a new version the same way, with a higher version number.

• A code-only update (the same permissions and sites, or fewer) of a published plugin that passes every automatic check goes live at once and is signed. The Publish window says "Version v is live: a code-only update that passed every automatic check. A moderator looks at it afterward."
• An update that adds a permission or a site waits for human review. After it is approved, each person who installed the plugin must also OK it before it runs for them; until then their approved version keeps running.
• An update with any failed check goes to review.
• A rejected update leaves the published version published.
• A plugin that was taken down cannot take new versions.

Signing

Every version Athanor publishes is signed with Athanor's plugin key, using Ed25519, at the moment it is approved. The signature covers the plugin id, the version, the SHA-256 hash of the uploaded package, and the permissions and sites the version declares. So a package cannot be swapped, renumbered or given more access without the signature failing.

When someone installs or updates your plugin, Athanor downloads the package from its own storage (never from your server), checks its hash against the version record, and verifies the signature with the public key built into the app. A package that fails either check is not loaded: "This version is not signed by Athanor, so it was not installed."

Development plugins, the ones you create or import on your own device, are unsigned. They run only on that device and are never synced or shared.

After publishing

• Your plugin appears in Discover and on athanor.arbastro.com/plugins, with Open in Athanor.
• People can rate and review it. Only you can reply to a review, and you can turn reviews off.
• People can report it. When three independent reports are open, it is hidden from Discover until a moderator looks. A moderator can delist a plugin (hidden from the directory) or take it down (turned off everywhere, checked when Athanor starts and every six hours).