Repository navigation
intake plugin
An intake parser teaches the LinkGrabber a format it does not understand: a link list, a page layout, a container. It is shown pasted text and URLs, proposes the links it finds — grouped into packages where the text says so — and may tidy an address into its canonical form.
A parser that also knows every mirror of a file and its hashes is the intake parser with mirrors.
| Scaffold | rdownloader plugin new --type intake |
plugin_type |
intake |
| World | intake-plugin |
| Exports |
claims, parse, normalize
|
| Template | sdk/templates/intake |
| Contract | Interface intake |
- You propose; the application decides. Everything you return goes through the LinkGrabber review, the domain blocklist and the routing rules, exactly as a pasted link does, and a package hint is a suggestion, not a package. A parser cannot queue anything.
-
You are asked before you are shown anything.
claimsruns for every paste in the application, so it has to be cheap and claim narrowly. -
A rewrite from
normalizeis discarded if it changes the host or the scheme. A normaliser tidies an address; it cannot redirect one.
The scaffold asks for nothing: a parser reads the text it is handed. Add net_http with the exact
domains only if your parser has to fetch something to find the links.
Like every extension type it carries an [extension] section: its slug and claims, the domain
patterns it is offered for. Empty means it decides per input in claims.
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.
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 intake --out ../myparser
cd ../myparserWithout 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 intake --out ../myparser.
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.
-
src/lib.rsclaims, reads and normalises. The scaffold findshttps://files.example.com/d/<id>links anywhere in the text and groups them under a[Package name]line; replacePREFIXand the reading with your format's. -
src/guest.rstranslates the three calls into the contract's types. -
manifest.toml:[extension] slugandclaims. -
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.
cargo testThe 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.
cargo build --release --target wasm32-unknown-unknown
wasm-tools component new target/wasm32-unknown-unknown/release/myparser.wasm -o target/myparser.wasmThis 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.
rdownloader plugin package --manifest manifest.toml \
--component target/myparser.wasm \
--locales locales --key plugin-signing.key --output myparser.rdplug
rdownloader plugin conformance myparser.rdplug --jsonconformance 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.
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 myparser.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.
Paste text in your format into the LinkGrabber: your candidates appear for review like any other.
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.
- Intake parsers in the plugin reference — what the host does with each call, in full
-
Interface
intake— every function and type, generated from the contract - Developing a plugin — the tools, translations, errors and what every type shares
-
The
intaketemplate on GitHub
Getting started
- Installation
- Building from source
- Translating rDownloader
- First run
- Your first download
- The interface
Using rDownloader
- The download queue
- Download history
- The LinkGrabber
- Site rules
- Hosters and accounts
- Usenet and NZB
- BitTorrent
- Video and audio downloads
- Image galleries
- Livestream recording
- FTP, SFTP and WebDAV
- Object storage
- Subscriptions
- Remote jobs
- Storage, categories and rules
- Watched folders
- Post-processing
- Bandwidth and power
- Notifications
- Automation
- Statistics
- Keyboard and accessibility
Integrations
- Browser extension
- Desktop capture agent
- Command line client
- REST API
- MCP server
- Automation tool compatibility
Operating
- Docker and NAS
- Synology NAS
- Reverse proxy
- Accounts, sessions and permissions
- Sign in with an identity provider
- External tools
- Backup and restore
- Updates
- Security and privacy
- Diagnostics and maintenance
- Troubleshooting
- Defaults and limits
- Support matrix
Plugins
Plugin development
- Developing a plugin
- Resolver
- Transfer backend
- Intake parser
- Intake parser with mirrors
- Folder crawler
- Remote job
- Sign-in
- OAuth sign-in
- Metadata enricher
- Notification destination
- Post-processing step
- Upload destination
- Stream transform
- Plugin reference
- Packaging, signing and distribution
- Running a plugin repository
Reference