Terms

These are the terms for using dev3d.net — the documentation, the site and the plugin marketplace it serves. They are written to be read rather than skimmed, and where a clause would normally be buried in legal phrasing it is stated in the plainest form that is still accurate. Using the site means accepting them; if you do not, the remedy is simply not to use it.

Using this site

The site is provided as-is. The documentation describes real behaviour and tries hard to be accurate — it documents limits as readily as features — but it is prose written by people, and the source code is the authority. If a page here and the behaviour you observe disagree, the behaviour is right and the page needs fixing: say so through contact.

What you may do here without asking:

• Read everything, including the internals pages, the business pages, the marketplace listings and the raw manifests.
• Link to anything, including deep links into the documentation. URLs are stable by design: a page's path is its position in the tree, and changing it is treated as a breaking change.
• Quote and cite the documentation, with attribution, in articles, internal write-ups, course material and reviews.
• Fetch the marketplace catalog at /marketplace/catalog.json as often as a dev3d host needs to, and install anything in it. The endpoint sends an open CORS header and is cached for a minute precisely so this is cheap.

What is not permitted: republishing the documentation set wholesale as your own; presenting this site's text as the official documentation of a modified fork without saying that it is modified; scraping at a volume that degrades the site for people using it; and attempting to gain access to the console, the database or another account. The console is protected by accounts and roles, and probing it is not research.

The software's licence covers the software, not this site's prose. The site makes no separate licence grant over its own text — the fair uses above are the invitation, and nothing beyond them is implied.

The marketplace is a publishing contract

The marketplace exists so that a dev3d installation can be pointed at a URL, read a catalog, and install a plugin it trusts. That only works if the manifest means something, so publishing here is a set of promises rather than a file upload.

Publishing requires an account with the plugins.publish permission. It is not open self-service: listings and versions are created through the console by an account that has been granted that ability. By publishing a bundle here, you confirm all of the following:

1. You have the right to distribute it. The code, the text, the images and anything else inside the bundle are yours to publish, or you have permission from whoever holds the rights. You are not uploading somebody else's plugin under your name.
2. The manifest is accurate. The id, name, version and apiVersion are truthful; the author field names who actually wrote it; the license field names the licence you are actually granting.
3. entry is present if and only if the bundle ships code. A declarative plugin — data only — must not have an entry field, because its presence is what makes the host import a module. A plugin that ships JavaScript and omits entry is being published as something it is not.
4. The declared permissions describe what the plugin actually reaches for. Not the maximum it could theoretically do, and not a minimised list — what it does. If it opens outbound connections, it declares network. If it registers tools, it declares tools. If it adds a provider, it declares providers and names the environment variable its key comes from.
5. You will not knowingly publish a bundle that does something the manifest does not disclose. This is the clause that matters most, and it is deliberately stated as intent rather than as an exhaustive specification: a manifest cannot enumerate every line of a module, and the obligation is not to be clever about the gap.
6. You are responsible for your plugin's own legal position — its licence, its use of third-party code, and whatever it does with the data it reaches.

What the marketplace checks for you, and what it cannot

Being precise about this is the point of the section, because "we review plugins" is a claim that would be easy to make and false to keep.

Checked when a version is uploaded	Not checked, and cannot be by inspecting an archive
The archive is a readable .tar.gz; it has entries at all; it is not larger than 32 MB and does not contain more than 2048 entries	Whether the code inside behaves the way its description says
No absolute paths, no .. segments, no links, no device nodes — a structural rejection rather than a sanitisation	Whether the declared permissions understate what the module does when it runs
A plugin.json exists at the archive root or inside exactly one wrapping directory, and it is valid JSON	Whether the code ships without an entry field naming it — the site classifies a bundle as declarative when no entry is declared, and it cannot see code the manifest does not point at
The manifest shape: a lowercase reverse-dns id, a version, an apiVersion whose major is 1, an entry that stays inside the plugin directory	Whether the plugin duplicates another listing's ideas, or whether its name is confusingly similar
The published sha256 is computed from the stored bytes and shown on the listing, so a host can verify what it downloads	Anything about behaviour on a machine the site does not run

In short: the site enforces structure and publishes a checksum. It does not audit intent. Publishers are held to the promises above, and reports are handled as described in the marketplace policy.

What installation means for a user

The two plugin kinds are not a cosmetic distinction, and the difference is what you are agreeing to when you enable one.

Four consequences, stated without softening:

• The permission list is a disclosure, and a gate for two things only. It is shown to you before you enable the plugin — the listing renders each declared permission with a plain-language note about what it reaches — and it is what the publisher declared and you accepted. It is enforced where the host mediates a capability (registering a tool needs tools, subscribing to the event stream needs events) and declaratory for the rest. There is no gate that stops a module declaring models from opening a socket, because activate() runs as ordinary code with the orchestrator's authority.
• The manifest is published verbatim. The listing shows the full JSON of the current version, exactly as the catalog serves it and before the host validates it, together with the bundle's size and its sha256. Read it. That is the entire informed-consent mechanism, and it only works if you use it.
• Installing is off by default in dev3d. A host will refuse to install anything until its operator sets DEV3D_ALLOW_PLUGIN_INSTALL=true. The refusal is deliberate and comes with a message saying exactly that.
• Uninstalling is imperfect. Disabling a code plugin withdraws its contributions and calls deactivate(), but Node cannot unload an ES module, so the module stays resident in the process until it restarts. Do not treat "disabled" as "gone".

Declarative plugins are a different proposition. They ship no code: everything they contribute is validated data that the orchestrator reads and acts on itself. No module is imported and nothing of the publisher's runs in the process. That is the whole reason the two kinds exist, and it is why the permission list on a declarative listing reads as a summary of what the data asks for rather than a grant of authority. It is not no risk — a contributed model can be pointed at a provider the publisher runs, and a contributed pipeline can spend your budget — but the risk is in data you can read, not code you cannot.

Only install a code plugin from a publisher you trust, having read the manifest. If you are not going to read it, prefer a declarative one.

Removal, archiving and yanking

Three different things can happen to something published here, and they are not interchangeable:

• A listing can be archived. Its status stops being published, so it disappears from the marketplace and from the catalog document entirely. Nothing new can be installed from it.
• A single version can be yanked. The version stops being served: it is excluded from the catalog, and the marketplace skips it when choosing which version to offer. Other versions of the same plugin are unaffected.
• A version can be replaced by re-uploading the same version number deliberately, which recomputes the checksum and the size. That is an exceptional operation for fixing a mistake, not a normal publishing path — a new version number is almost always the right answer.

What none of these can do is reach into an installation that already has the bundle. The site serves bytes over HTTP; it has no channel into anyone's dev3d process. If a host already installed a version, yanking that version stops new hosts from getting it and stops the update check from offering it, and that is the complete extent of the effect. The site does not pretend otherwise, and no wording on a listing page implies a remote removal capability that does not exist.

This is also why the marketplace policy answers a bad release by disabling the plugin in the host rather than by a rollback: the host has no downgrade and no pinning, so the operator's real remedy is to turn the plugin off. That limitation is a property of the software, and it is documented as one rather than hidden.

Availability, changes, and what happens if this site stops

There is no service level here and no availability promise. The site may be unavailable, the catalog may briefly serve a stale document — it is cached for one minute with a long stale-while-revalidate, because a marketplace that is briefly stale is harmless and one that is down is not — and any part of it may change.

These terms may change. They are stored and versioned exactly like the rest of the documentation on this site: every save is a revision with a timestamp, and revisions are retained, so the version you agreed to is recoverable rather than overwritten. Continuing to use the site after a change means accepting the current version.

If the marketplace ever stops being operated, the practical consequence is limited by its design: the bundles you have already installed keep working, because a dev3d host needs the catalog only to discover and fetch new versions. Existing installations do not call home to stay running. What you would lose is the discovery channel, not the software.

No warranty

The site, the catalog and every bundle listed on it are provided as-is, without warranty of any kind, express or implied, including any warranty of merchantability, fitness for a particular purpose, or non-infringement. No one warrants that the site will be available, that a listing is accurate, that a plugin is safe, or that anything you install will work.

To the extent permitted by law, the operator of this site is not liable for any loss arising from your use of it or of anything you download from it — including lost data, lost work, lost spend on model providers, or damage caused by a plugin. You install code at your own risk, and the marketplace policy explains what the site can and cannot do about a bundle that turns out to be malicious.

Nothing in this section limits rights you have that cannot be limited by agreement, and nothing here overrides the AGPL's own warranty disclaimer for the software — which is in sections 15 and 16 of the licence and is, if anything, sterner than this paragraph.

If something goes wrong

Situation	What to do
You found a bundle that is malicious, or does something its manifest does not disclose	Report it through contact with the plugin id, the version and the sha256. A malicious bundle is acted on first and discussed afterwards.
A listing claims something false, or copies your work	Same route. Naming and description disputes are a conversation; include the evidence.
Your own plugin was yanked and you disagree	Ask. Yanking is reversible, and a version yanked for a fixable reason can be restored or replaced by a corrected version.
You want your listing removed entirely	Ask. A listing can be archived, which removes it from the catalog.
A page here contradicts the software's real behaviour	Tell us which page and what you observed. Documentation errors are treated as bugs, not as differences of opinion.

Related reading: Privacy, License, the marketplace policy, and the publishing guide if you intend to put a plugin here.