Introduction

Brokerr is a self-hosted synchronization broker. It translates observations from a media source into provider-neutral operations and lets a target plugin apply those operations to a connected account.

Brokerr is built around three independent resources:

1. A source instance connects to one provider account or server and reads data.
2. A target instance connects to one destination account and exposes writable capabilities.
3. A profile joins one source to one target, selects source scope, and stores every synchronization feature and rule.

Provider plugins do not import the database, web framework, or sync service. The engine discovers plugins from their folders, validates their public SDK contracts, resolves compatible features, and executes a generic pipeline.

Design goals

• Add a provider by adding one plugin folder, without adding provider branches to core sync.
• Keep provider credentials and connection settings separate from profile rules.
• Make every proposed remote mutation visible as a persisted operation.
• Keep ratings exact through canonical Decimal values rather than binary floats.
• Let provider-specific features such as Letterboxd diary or AniList rewatch live in the target plugin while still using generic UI and persistence.
• Keep inactive provider implementations isolated under deprecated; they are not imported by the active application.

What Brokerr is not

Brokerr is not a bidirectional database merger. The current direction is source to target. It reads target state to protect manual data, resolve conflicts, and produce exact Revert payloads, but target-to-source rating sync is not implemented.

Scheduled and webhook-triggered runs use the same engine as manual runs. Discord is currently the supported notification transport; it reports run outcomes and is not a media target.