resolver plugin

Writing a resolver plugin

A resolver is what makes a one-click hoster, a multihoster or a debrid service downloadable. It turns a link of its provider into exactly one downloadable file — an address, a name, a size and headers — checks whether links are alive, and reports on the account: valid or not, premium or not, how much traffic is left. The bytes themselves are fetched by rDownloader's own transfer engine, not by the plugin.

Pick a crawler instead when one address stands for many files, a stream transform when the provider encrypts on the client, and a remote job when the provider works on a job for minutes or hours before there is a file.

Scaffold	rdownloader plugin new --type resolver
plugin_type	resolver
World	resolver-plugin
Exports	match-url, check-account, resolve, check, hosters
Template	sdk/templates/resolver
Contract	Interface resolver

What the host promises

• You are asked before you are handed a link. match-url reaches nothing, and the host also checks the link against match_domains in manifest.toml; a resolver that claims links belonging to nobody fails conformance.
• You never see a credential. {{secret:<reference>}} in a header or query value is expanded by the host on the way out, towards the domains the manifest grants, and only for the account the call is made for.
• An account check states findings, not hopes. premium is true only where the check actually read a subscription.

Permissions

The scaffold asks for secrets — the account's password slot, which requests reach only as {{secret:…}} — and net_http with the hoster's own domains. A resolver may also ask for cookies (the account's cookies for one address) and captcha (a challenge handed to the configured solver or the person), and nothing else.

A resolver carries a [provider] section: the provider row the account form is built from — its slug, kind, which credentials it takes and which hosts the secret may be sent to. Beside it, match_domains names the links it claims at intake and download_domains where a resolved file may be served from. The provider row explains every field.

Ask for exactly what you use: the install preview shows every grant, and a component importing an interface its manifest does not grant cannot be instantiated. Every capability is listed under Capabilities.

Step by step

1. Scaffold it

plugin new reads its templates from sdk/templates, so run it from a checkout of the repository:

git clone https://github.com/degoya/rDownloader.git
cd rDownloader
rdownloader plugin new --type resolver --out ../myhoster
cd ../myhoster

Without an installation of rDownloader, the packaging tool rd-pack — cargo build --profile release-test -p rd-pack in the checkout — takes the same arguments: target/release-test/rd-pack plugin new --type resolver --out ../myhoster.

The directory name becomes the crate name and the plugin's slug (--name sets another). The scaffold gets its own plugin id, its own copy of the contract in wit/rdownloader.wit and its own Ed25519 key pair: plugin-signing.key, whose public half is already in manifest.toml. Keep that file out of version control.

2. Make it yours

• src/lib.rs decides which links are yours. Replace HOSTS and keep it in step with match_domains; claim exact hosts and their sub-domains, never a host that merely ends in the same letters.
• src/guest.rs holds the four calls against your provider's API: the account check, resolve, the batch link check and hosters.
• manifest.toml: match_domains, download_domains, the [provider] row and [capabilities.net_http] domains — the narrowest list that works, including the CDN a download redirects to.
• locales/en.json: the English text of every failure code you report.

Change description and author under [metadata], and read the comment at the top of src/lib.rs: it states what the host promises this type.

3. Test it

cargo test

The unit tests need no WebAssembly toolchain: only src/guest.rs is wasm32-specific. Give every answer of your provider you read a test of its own.

4. Build the component

cargo build --release --target wasm32-unknown-unknown
wasm-tools component new target/wasm32-unknown-unknown/release/myhoster.wasm -o target/myhoster.wasm

This needs the wasm32-unknown-unknown target and wasm-tools 1.261.0, the version the bundled plugins are made with: cargo build makes a core module that carries the world src/guest.rs generates, and wasm-tools component new turns it into the component. The plugin is built without WASI: a component importing anything outside rdownloader:plugin is refused — see Building without WASI.

5. Package and sign it

rdownloader plugin package --manifest manifest.toml \
  --component target/myhoster.wasm \
  --locales locales --key plugin-signing.key --output myhoster.rdplug
rdownloader plugin conformance myhoster.rdplug --json

conformance answers whether this application would run the package; it has to be clean before you publish. For a key that outlives the scaffold, rdownloader plugin keygen --role plugin --output ./keys writes a pair: the Base64 in the .pub file goes into public_key, and key_id gets a name of your own. In CI, RDOWNLOADER_PLUGIN_SIGNING_KEY holding the private key's PEM text replaces --key. Details: Packaging, signing and distribution.

6. Install and trust it

For a first try without signing, package with --development instead of --key and start rdownloader serve --plugin-development-mode, the only mode that accepts an unsigned package.

Install a signed package under Settings → Plugins → Add as an upload, or with rdownloader plugin install myhoster.rdplug --root data/plugins. Review before installing shows every permission and the signing key; a key this installation has not seen asks to be trusted — compare its fingerprint. The message after installing says whether the plugin runs at once or after the next restart; see Installing and trust.

Add an account for your provider under Settings → Accounts (see Hosters and accounts), run its account check, then paste a link into the LinkGrabber: the online check and the download go through your plugin.

7. Publish it

Publish the .rdplug together with your key's fingerprint, or — so that people get your new versions in the Catalogue — in a plugin repository of your own: a signed index built with rdownloader plugin index build and a repository-role key. A repository only delivers: every package in it still needs your plugin key, approved by the person installing it. See A repository index and Running a plugin repository.

The SDK's reusable CI workflow, sdk/ci/plugin.yml, builds, checks the imports, packages and runs conformance on every push and pull request; it signs only on a push to the default branch or a tag, so a pull request never sees the key.

Read next

• Resolvers in the plugin reference — what the host does with each call, in full
• Interface resolver — every function and type, generated from the contract
• Developing a plugin — the tools, translations, errors and what every type shares
• The resolver template on GitHub