Operations

Plugins

Last updated 2026-08-14T06:58:49+00:00

Racinage plugins extend the hosted web app and compatible local Free editions through reviewed standalone bundles, explicit capabilities, and secure install controls.

Plugin library

The public library is served from plugins.racinage.com in production and from the local plugins/ folder in development. It has its own menu for Home, Plugins, Forum, Developers, Rules, Your Account, and a Main Website link back to racinage.com.

Family users can browse published plugins from the plugin site or from Manage > Plugins, then install, enable, disable, update, or uninstall plugins for the selected family account when they have the Manage Plugins permission. The plugin site install flow can select one or more family accounts.

Signed-in users can privately recommend a published plugin from its card or detail action menu. Recommendations appear only in the selected recipients' interface notifications and never reveal recipient email addresses. A plugin publisher cannot recommend their own plugin.

• Installs are scoped by family_long_id.
• Each plugin keeps its own manifest, versions, install rows, purchases, reviews, comments, issues, FAQs, and audit log entries.
• Every plugin ships as one standalone folder. Its runtime, endpoints, assets, translations, migrations, and dependency metadata must not be scattered through the core project.
• Uploaded packages stay in private quarantine; runtime hooks only load reviewed, manually deployed files through an allowlisted host contract.
• Paid plugin purchases use the shared commerce order flow. When configured, customers can use FastSpring hosted international checkout or pawaPay African Mobile Money; enabled manual references and private proof remain available as a fallback.

Developer access

Users must have Developer permission before publishing plugins. A super-admin can grant it manually from the user edit form by enabling Can publish plugins. Users can also request it from the developer access page.

Super-admins control the request mode from admin7839 > Plugins. The default is paid access at $5 USD. If the mode is free and auto-approval is enabled, requests grant developer permission immediately. If it is paid, the request waits for payment review and approval.

Bundle-first publishing and review

Publishing starts by uploading one ZIP from Manage > Plugins > Developer, without leaving the dashboard. On the public plugin website, the equivalent upload flow remains at plugins.racinage.com/submit. The ZIP root must contain plugin.json, the declared entrypoint, WebP logo, WebP cover image, WebP screenshots, and every file needed by the plugin. Racinage inspects the archive without executing it, then pre-fills the publishing form from plugin.json. The author can review or edit the detected name, version, description, features, capabilities, and catalog media before continuing to pricing, plan requirements, provider costs, support expectations, and refund terms.

Raster media stored by a plugin must be WebP. A plugin may accept JPEG, PNG, or WebP input where appropriate, but it must validate the real MIME type and dimensions, decode the image, strip metadata by re-encoding it server-side, and store WebP output rather than the original upload. Create a small preview for lists and dense cards plus a larger detail or lightbox variant. Private variants remain behind the same authorization checks as their source record. Non-WebP catalog or stored raster media may require changes or cause a release to be rejected during review.

Automated checks reject traversal paths, duplicate paths, symbolic links, unsafe binaries, excessive file counts, and compressed-size abuse. Each stored package keeps a SHA-256 checksum, review signature, compatibility bounds, and rollback notes. Source review, tenant-isolation testing, and super-admin approval are still required before activation.

Delisting removes a plugin from discovery and prevents new installs. It does not erase existing family data. A separate security revocation can disable an unsafe version while preserving the owner's export and deletion choices.

Plugin pages and their user and super-admin detail dialogs share asynchronous Overview, Screenshots, and How it works tabs. Publishers may add separate overview and tutorial videos, caption each interface screenshot, and publish a numbered user journey. Overview also includes comments, reviews with 1-5 star ratings, Issues with image/video attachments, and Forum FAQs. New thread activity appears live without interrupting a message being written. Issues can be marked solved and reopened; FAQ threads can be closed and reopened.

The Developers page lists approved publishers who have at least one published plugin. Each card shows the publisher's public identity, description or published-plugin summary, followers, published plugins, access-aware installs, package downloads, profile rating, and combined plugin rating. Install totals include every user who currently has access through an account-owned plugin, a selected family, or accepted family collaboration.

Collaboration API v1 contract

A plugin that owns shared resources must register each independently permissioned resource through the reviewed Core Collaboration API. The manifest declares API version 1, resource types, roles, capabilities, and reviewed transfer, export, and final-delete adapters. Public links alone do not create collaboration membership, and child records without independent grants inherit their parent resource.

Plugins must use typed access checks and grant methods rather than generic collaboration writes or direct ownership changes. During an account deletion grace period, eligible collaborators can request succession. Ownership moves only after explicit owner approval and a fresh permission, quota, subscription, and resource-revision check. If the owner instead chooses final deletion, the choice remains reversible until the account purge begins.

Optional AI and MCP contract

A plugin is never exposed to the Racinage assistant or MCP by default. A developer may opt in with an ai object in plugin.json. Racinage validates the declaration during upload and enables it only for a published, reviewed, currently enabled installation. Every operation must have an exact name, plain-language purpose, confirmation tier, and closed JSON input schema.

{
  "ai": {
    "enabled": true,
    "description": "Organize tasks in the selected workspace.",
    "mentions": ["workspace", "task"],
    "tools": [{
      "name": "tasks.update_status",
      "description": "Change one task status.",
      "confirmation_tier": 2,
      "input_schema": {
        "type": "object",
        "required": ["record_id", "status"],
        "properties": {
          "record_id": { "type": "string", "maxLength": 80 },
          "status": { "type": "string", "enum": ["open", "done"] }
        },
        "additionalProperties": false
      }
    }],
    "mcp": {
      "enabled": true,
      "server_url": "https://mcp.example.com/racinage",
      "transport": "streamable_http",
      "tool_allowlist": ["tasks.update_status"],
      "auth_mode": "plugin_bearer",
      "privacy_url": "https://example.com/privacy"
    }
  }
}

Reviewed first-party runtimes may implement the host callbacks ai_context and ai_execute. The runtime must recheck the selected family or account owner, current permission, subscription access, record revision, idempotency key, and confirmation before changing data. Results must be minimized and must not contain credentials or private provider payloads.

A developer-owned MCP server is a reviewed connector declaration, not permission to make arbitrary network requests. The URL must be an exact public HTTPS endpoint with no embedded credential, query, fragment, redirect, or private address. Declare an explicit tool allowlist and keep its credential in Racinage's encrypted integration storage, never in the manifest. Racinage activates an endpoint only after adapter review, MCP conformance tests, SSRF checks, privacy review, and tool-by-tool approval. Changing the endpoint or allowlist requires another review.

Developer profiles and interactions

Developer names on plugin cards and developer-directory cards link to public profiles at /dev_profile/{username}. Previous profile links continue to resolve after a username change. Details is the default view; Plugins, Reviews, Awards & Milestones, and Legal use asynchronous tabs with browser-history support and ordinary link fallbacks.

• Details shows the public identity, approval state, account date, about text, specialties, website and social links, current statistics, and recent plugins.
• Plugins supports search, category filtering, sorting, grid or list views, and pagination across all currently published plugins.
• Reviews keeps developer-profile ratings separate from plugin ratings while allowing visitors to search, filter, and sort a combined review feed. A signed-in user can maintain one developer review after receiving access to at least one published plugin from that developer. Self-reviews are not allowed.
• Awards & Milestones shows publishing, install, download, review, rating, category, and publishing-tenure progress alongside revocable team badges.
• Legal summarizes public copyright, approval and first-publication information, plugin licenses, and relevant policy links. Each release is reviewed separately; publication does not constitute blanket endorsement.

Signed-in users can follow a developer, review an eligible profile, start a private in-app conversation, visit a configured website, or report a profile. The plugin account area includes Following and Messages views. Marketplace notification preferences for new plugins, releases, and developer messages are available under personal Settings, independently of family-management permission. Interface and installed-app delivery default on while email defaults off, and retried events are deduplicated across channels.

Successful reviewed and portable package deliveries contribute to cumulative download totals. Retries are deduplicated by plugin version, delivery channel, and a private opaque client token. Racinage does not use a Windows device identifier or store a raw client token, device fingerprint, or IP address for these totals.

Shared feedback popup API

Transient plugin outcomes such as a successful save, warning, failed request, or informational confirmation should use Racinage's shared feedback_popup API. This keeps notifications visually consistent, accessible, and visible after an asynchronous content swap. The default popup appears at the centre-top, includes a close button, and disappears after 10 seconds.

Set plugin-wide defaults in plugin.json. Duration is measured in milliseconds and may be between 1 and 120 seconds. The only supported positions are center-top and center-bottom.

{
  "feedback": {
    "enabled": true,
    "duration": 10000,
    "position": "center-top",
    "show_close_button": true
  }
}

Use window.racinageFeedbackPopup.showForPlugin(source, message, type, options) in plugin JavaScript. Supported types are success, warning, error, and info. A message may be plain text or an object with a title and optional paragraph. Per-call options can override duration, position, close-button visibility, title, or paragraph.

window.racinageFeedbackPopup.showForPlugin(
  form,
  { title: "Changes saved", paragraph: "Your workspace preferences are up to date." },
  "success"
);

PHP endpoints may call feedback_popup($message, $type, $options). Server option names use duration, position, show_close_button, title, and paragraph. Plugin HTMX feedback sinks marked with data-feedback-popup-sink automatically preserve these response settings without rendering a custom inline notice.

feedback_popup(
  "Your workspace preferences are up to date.",
  "success",
  ["title" => "Changes saved", "duration" => 10000]
);

A developer may set feedback.enabled to false and provide a custom accessible notification system. The shared API remains recommended because it follows the interface design language and survives asynchronous plugin navigation. Inline field validation, loading progress, and persistent editor or synchronization state should remain next to the control they describe rather than becoming transient popups.

Persistent plugin notification API

Persistent alerts belong in the normal Racinage notification feed and may also be delivered by email and to every active installed-PWA device where the recipient is signed in. A reviewed runtime calls plugins_dispatch_notification() with its own slug, an authorized recipient user ID, an optional family ID, a declared category, localized content, a Racinage action URL, and the category definitions. The host resolves native device subscriptions, language, email address, and display name internally. Those private values are never returned to the plugin.

$categories = [
  "approval_requests" => [
    "interface_default" => true,
    "email_default" => true,
  ],
  "activity_digest" => [
    "interface_default" => false,
    "email_default" => false,
  ],
];

plugins_dispatch_notification(
  $con,
  "my-plugin",
  $authorizedRecipientUserId,
  $familyLongId,
  "approval_requests",
  ["en" => "Review requested", "fr" => "Validation demandée"],
  ["en" => "A record is ready to review.", "fr" => "Un dossier est prêt à être validé."],
  dash_url("manage/my-plugin"),
  $categories,
  [
    "actor_user_long_id" => $signedInActorUserId,
    "interaction_category" => "proposals_requests",
  ]
);

Category keys must be stable lowercase identifiers and each runtime may declare at most 40. Enable urgent access, security, deadline, or approval categories by default, using email only when the user is likely to need prompt attention. Optional activity, summaries, tips, and marketing categories must default off. Email is an additional channel: enabling it also keeps the interface notification enabled.

For user-generated notifications, pass a final context array containing the authenticated actor's user ID and exactly one validated interaction category: direct_notifications, collaboration_invites, plugin_recommendations, or proposals_requests. The host applies the recipient's account-wide social block before delivery. An empty actor is reserved for trusted system-generated notices, which bypass social blocks. Do not infer or report whether a recipient blocked the actor: batch endpoints must return generic sender feedback for blocked, duplicate, cooldown, or otherwise skipped recipients.

A plugin that uses this API must show every declared category in its own Settings or Configuration section with separate Interface and Email too controls. An enabled interface category is also eligible for installed-app delivery according to the recipient's device permission and per-device sound choice. Load choices with plugins_notification_preferences() and save only for the signed-in user with plugins_save_notification_preferences(). Determine recipient user IDs from an authorized plugin-owned relationship; never ask for, query, cache, log, or expose a Racinage user's email address or Push subscription merely to deliver a notification. Unregistered guest email workflows are separate from account notification preferences and must use validated addresses supplied for that guest workflow.

Pricing and earnings

Plugins can be free, one-time paid, or subscription-based with monthly or yearly billing. Each paid order records its list price, customer reduction, net amount, interval, service period, platform share, and publisher share. User-published paid plugins normally split earnings as 20% to platform owners and 80% to the plugin publisher. Plugins published directly by super-admins keep 100% of earnings for the platform owners.

Every active paid Racinage plan can access premium plugin features. Plugin publishers declare separate usage limits for Family, Max, and Lifetime, and the plugin runtime enforces the applicable limit for the owner of the selected family account.

Automatic reductions and coupon codes do not stack; the largest eligible saving applies. A user publisher can approve a maximum seller-funded reduction during review. Platform-funded reductions and affiliate commission use the platform share first, and a promotion is blocked if it cannot preserve the publisher's normal share and the full affiliate rate within the approved publisher contribution.

Subscription runtime remains active for a 21-day renewal grace period. After the grace period, paid execution is disabled until renewal, while plugin data and authorized exports remain retained.

User publishers must keep a verified payout profile with identity, payout, and tax details before paid plugins can be approved. Paid purchase payouts are held until the publisher profile is verified.

Developers can also maintain public profile details such as public name, description, contact fields, website, social links, profile photo, and cover photo.

Wedding Planner official plugin

Wedding Planner is the first official plugin. A client family owns each wedding workspace. The wedding owner always has every permission and is the only person who can assign or revoke collaborator access. Existing Racinage users can be invited as Planner, Finance manager, Guest manager, Designer, Check-in staff, or Viewer, and receive only the selected permissions after accepting.

Wedding quotas and paid provider usage count against the wedding owner. A collaborator can join any number of weddings, even on Lite, without consuming their own wedding quota. Lite includes one lifetime owner-created wedding, all manual planning tools, exports, and email delivery. Paid Racinage plans unlock additional owner-created weddings and configured AI, WhatsApp, and SMS allowances. Each collaborator can independently choose interface and additional email delivery for collaboration, approval, guest-comment, and contribution-pledge categories in the wedding Settings tab.

The plugin covers couple profiles, reusable and imported guest lists, RSVP review, event checklists and logistics, budgets, family and friend contributions, vendors, private documents, grouped invitations, autosaved invitation design, secure access codes, signed QR admission, partial party check-in, collaborative mood boards, planner profiles, proposals, immutable accepted contracts, installments, receipts, and manual payment confirmation. Projected Total Budget, Available Funds, Couple Budget, and Forecast Expenses are separate amounts entered manually by the planning team. Forecast Expenses is not generated from expense rows: reports compare it with net paid recorded expenses to show whether the wedding is under, on, or over forecast. Remaining funds are calculated as Available Funds plus received contributions minus net paid expenses, while pledges stay separate until received. Payment tracking records agreements and receipts only; Racinage does not hold or move funds.

Wedding covers, Groom and Bride portraits, organizer profile media, Mood Board uploads, invitation uploads, and AI-generated invitation artwork are decoded and stored as WebP. Small variants serve cards and lists, while large variants serve detail pages and large-view surfaces. Existing local media can be migrated with the idempotent WebP media migration; keep its private rollback backup until verification is complete.

Where it appears after installation

Open Manage > Weddings to use Wedding Planner. Home, Weddings, Invites, Templates, Organisers, Profile, and Help sit in the standard Manage header. Help provides searchable step-by-step guides, real interface previews, and direct links to each workflow. The Library opens full template previews with listing details and member reviews. Public wedding cards offer seven visibly distinct layouts, exact cover-aware template thumbnails, and a live preview that follows design, detail, visibility, and section-order changes. The wedding Settings tab edits every opt-in public-card detail while Share remains the preview and publishing surface. The verified publisher also receives a private All Weddings operations tab with live search and date filters, wedding and couple media, localized date states, countdown progress, operational highlights, and collapsed aggregate details. Reviewed Wedding Organizers can publish a directory profile with normalized locations and wedding types, structured services and prices, repeatable social links, profile media, visibility choices, and currency-aware packages. Couples can filter public organizers, compare successful wedding and verified review totals, and review an organizer only after the owner completes a wedding where that organizer was an active Planner collaborator. Wedding owners manage pending and approved collaborators through compact action menus with profile, permission, and confirmed revoke actions. Mood Board and Invitation deletions use in-app confirmation and refresh only their affected grids. Each selected wedding uses a profile rail and asynchronous workspace tabs with URL history. Financial inputs show the signed-in user's display currency and current configured rate, while existing wedding and contract values remain stored in their canonical currency.

• /dash/manage/weddings is the activity hub, wedding directory, and collaboration invitation workspace.
• Overview, Events, Budget, Mood Boards, Invitations, Guests, Check-in, and Settings open as responsive asynchronous tabs. The couple profile rail appears only on Overview; all task tabs use the full workspace width. Overview brings schedule, checklist, funding, contributions, guests, invitations, design, documents, alerts, and team activity into one wedding report. Opening a Mood Board or invitation design expands a full editor across the wedding workspace while keeping the global header and Manage sidebar. The invitation builder supports multiple artboards, independent editable elements, dynamic guest fields, templates, assets, comments, versions, collaboration, local-first recovery with background synchronization, and print or web export. Library, marketplace, AI, and creator-pool entry points stay unavailable until their feature flags and acceptance gates are enabled.
• Check-in provides a desktop event-day console and a scanner-first mobile view. Authorized staff can scan signed QR invitations, search the roster, record partial party arrivals and walk-ins, reverse an arrival with a reason, review recent activity and issues, and use attendance, meal, table, CSV, print, and badge reports. The minimum roster is prepared automatically for supported offline use.
• The Racinage publisher can pause Wedding Planner AI, choose supported features, set plan allowances, apply family or user controls, and review operational usage totals. AI remains unavailable when the required plan, allowance, provider connection, or platform safety control is not available.
• The owner may inherit wedding design access or set custom board permissions for accepted collaborators. Mood-board actions save locally first, remain available without a stable connection, and synchronize quietly across boards when connectivity returns. Each committed autosave stores a low-resolution shared thumbnail, so every collaborator sees the latest canonical editor snapshot without rendering the live board; only the newest five snapshots are retained. Layers, shapes, connector styles, inline text, comments, a contained minimap, and named checkpoints are available in the compact responsive editor. Optional encrypted Ably configuration adds live presence, cursors, and temporary locks; MySQL remains canonical and authenticated SSE continues collaboration when Ably is unavailable. Approved versions are immutable except for comments and reactions.
• Public mood-board links use /plugins/wedding/mood/{share_token}. The owner controls version pinning, expiry, passcode, and allowed contribution types. Visitor comments, votes, notes, colors, and screenshots remain pending suggestions until an authorized reviewer accepts them.
• Collaboration invitations and installed-plugin controls remain in Manage > Plugins > Installed. Publisher-only provider settings are in Manage > Plugins > Developer > Dev Settings.
• Guest invitation pages use /plugins/wedding/{public_token}. They are public-facing routes protected by the invitation access code and do not expose the dashboard.

Finance Manager official plugin

Finance Manager is pre-enabled under Manage > Finance Manager. Its workspaces belong to the signed-in user account, remain available when the selected family changes, and can be hidden from Manage without deleting records or attachments. It records personal-style cash finances only and never sends, withdraws, or receives real money.

Every plan includes manual tracking, CSV/OFX/QIF imports with preview and duplicate checks, reconciliation, calculations, reports, backups, private attachments, and the same account display-currency setting used elsewhere in Manage. Workspaces cover accounts, income and withdrawals, balanced transfers, split categories, recurring review, period budgets and rollover, goals, debt amortization and payoff comparisons, manual investment valuations, what-if forecasts, separate contribution or loan circles, and CSV, JSON, or A4 PDF exports. Each collaborator can independently choose interface and additional email delivery for collaboration, recurring-review, and shared-activity categories in workspace Settings.

Lite and Windows Free include 1 owned workspace, 8 accounts, 2,500 transactions, 5 each of budgets, goals, and debts, 1 investment account with 25 holdings, 1 scenario, and 3 circles with up to 25 people each and 1,000 total entries. Hosted Lite includes 1 collaborator. Family includes 5 workspaces, 50 accounts, 50,000 transactions, 25 each of budgets, goals, and debts, 5 investment accounts with 250 holdings, 10 scenarios, 10 collaborators per workspace, and 10 circles with up to 100 people each and 25,000 total entries. Max includes 25 workspaces, unlimited finance records, and 50 collaborators per workspace. Lifetime includes 50 workspaces with unlimited records and collaborators.

Owners can invite existing users by username or email and guests by email. Owner, Manager, Contributor, Viewer, and custom roles are enforced on the server with section and selected-record restrictions. Invited workspaces use the owner's plan and never consume the collaborator's ownership quota. After downgrade grace, existing records and collaboration remain accessible, but new additions above Lite limits are blocked.

Hosted users may connect an authorized Racinage finance wallet or individual Event or Project contribution as a read-only source. Source access is checked independently of the selected family; a link pauses and leaves totals if its owner loses access. Finance circles remain separate record-only ledgers and never affect personal accounts or net worth.

Kitchen Planner official plugin and Global Calendar

Kitchen Planner is a free, account-owned official plugin installed from Manage > Plugins > Library. Personal, Family, and Group kitchen workspaces remain independent of the selected Racinage family. Manual tools cover visual recipes, precise ingredient lines, ordered timed steps, serving scaling, costs, pantry lots and movements, cooking history, household profiles, meal plans, generated shopping lists, categories, tags, exports, and notification choices.

The account-wide Manage > Calendar combines authorized core dates and reviewed plugin providers without copying source-owned records. Month, Week, Day, Agenda, and Year views preserve date-only values, localize UTC times, expand supported recurrence, warn about visible conflicts, persist personal filters, and support previewed ICS import plus private read-only ICS feeds. Source-owned entries always open their canonical editor.

Recipe imports are independently feature-gated. A selected funded or BYOK provider processes bounded background jobs without silent fallback. Non-food sources are ignored, inaccessible or insufficient evidence remains Pending, exact matches remain hidden duplicates, and source text is always treated as untrusted data. Public cook profiles and immutable sanitized recipe snapshots remain behind separate moderation, copyright, privacy, and interaction flags.

Private media extraction uses only reviewed server executables configured by absolute path: RACINAGE_KITCHEN_TESSERACT_PATH for image OCR, RACINAGE_KITCHEN_PDFTEXT_PATH for PDF text, and RACINAGE_KITCHEN_FFMPEG_PATH for bounded video frame sampling. Optional OCR languages are allowlisted through RACINAGE_KITCHEN_OCR_LANGUAGES. Missing tools, failed scans, unreadable frames, and insufficient text remain Pending. Social links are metadata-only and never authorize downloading or archiving the linked video.

USDA nutrition matching runs only when the independent Nutrition flag and the private RACINAGE_FDC_API_KEY are configured. It keeps the FoodData Central ID, match confidence, retrieval time, per-100-gram values, batch and per-serving calculations, and a visible partial state when ingredient quantities cannot be normalized to mass. Nutrition and household allergen checks remain advisory.

Racinage Free installs Kitchen Planner only through the signed portable catalog. Its reviewed native bridge exposes named Kitchen operations, local Calendar projection, loopback-only AI status, guarded public-source fetching, and previewed local backup restore. It does not include hosted credits, collaboration, public publishing, or server synchronization.

NameGen official plugin

NameGen is a completely free, account-owned plugin that helps parents find names for their children. Install it for your personal account from Manage > Plugins > Library. It remains available across family switches and can be disabled or uninstalled independently.

The hosted workspace includes a sourced bilingual catalog, filters for association, country, language, era, meaning, syllables, pronunciation, nicknames, and variants, plus private Baby Projects for surname and sibling fit, middle-name ideas, initials checks, shortlists, avoid lists, and blind partner preferences that reveal mutual matches. Signed-in NameGen users can also create public or private groups, suggest names, and use likes, favorites, ratings, threaded comments, follows, mentions, reports, and sharing. Contributions hide the author by default and public groups never leave the installed NameGen community.

NameGen managers receive only the review, publishing, taxonomy, social moderation, team, or settings permissions granted by the plugin owner. Factual claims about origin, meaning, era, pronunciation, or popularity require a source before publication. On uninstall, users may retain their private data for later or delete it; approved catalog contributions remain available without their identity.

Racinage Free for Windows can install the offline NameGen companion. It includes the bundled finder, custom local names, favorites, personal ratings and notes, private groups, solo Baby Projects, and import/export. Hosted community, moderation, public statistics, manager tools, and partner collaboration are not available offline.

Unpublishing, deletion, and retained data

Developers request unpublishing through super-admin review. Approval removes the plugin from discovery and prevents new installs immediately, allows existing users three days to export or back up their data, then disables the plugin. Deletion is a soft deletion: the listing disappears from the library and developer workspace, but packages and tenant data may remain on Racinage servers where retention is required for regulatory compliance and authenticated user data-access requests.

Retained plugin data is isolated from normal application, developer, Racinage, and Fallax Vision interfaces. It is not used or shared with third parties and is released only to the authenticated user through the account data-request export, subject to applicable law.

Local Free plugin library

Racinage Free for Windows uses the same Manage sections as the hosted app, but removes collaboration controls. Its Plugins tab downloads a short-lived, cryptographically signed catalog over HTTPS. Only reviewed bundles that explicitly declare a local runtime can be installed. The server creates a separate production-only portable package from the declared local subtree, while source files, development metadata, maps, tests, and server code remain private. The client verifies the catalog signature, exact ZIP checksum, archive paths, expanded size, and local entrypoint before extracting the portable package into the Windows user profile.

Browser-rendered HTML, CSS, JavaScript, and WebAssembly can always be inspected by a determined device owner. Plugin authors must therefore keep proprietary algorithms, provider credentials, entitlement decisions, and sensitive operations on reviewed server endpoints rather than relying on client-side secrecy.

Lite constraints still apply locally. Paid plugin cards link to the hosted Racinage purchase and entitlement flow. Web-only plugins remain visible with a clear explanation and cannot be executed locally. Local plugin pages run in a sandboxed frame without family-record access unless a future reviewed host capability explicitly grants it.

Payment controls

• Provider routes remain disabled until credentials, product or currency mappings, and rollout flags are configured. FastSpring events require a valid webhook signature; pawaPay callbacks trigger an independent server-side API reconciliation before an order changes state.
• Publisher and affiliate payouts always require review. Approved affiliate payouts may use pawaPay when configured and are marked paid only after reconciliation confirms completion; manual payout records remain available.