Skip to content

Results from this documentation version only.

    ← Alcubi Delegator

    Development preview · These guides describe unreleased source code.

    Control optional telemetry

    Delegator’s optional telemetry helps the maintainer understand whether consenting instances continue to use the product and which workflows and settings need work. It is configured independently for each Delegator data directory.

    Read the complete Delegator privacy notice for the exact data inventory, service providers, local storage, retention, and deletion process.

    Interactive dg init asks whether to enable telemetry while the setting is null. The prompt selects Yes initially, but viewing it does not grant consent. Delegator records the choice only when you submit it. Cancelling, reaching end of input, or leaving setup before submission keeps null; both null and false send nothing.

    Automated setup can submit a choice without a prompt:

    Terminal window
    dg init --telemetry=true
    dg init --telemetry=false

    Without that flag, scripted setup preserves the current value or leaves a new data directory at null.

    Use config to inspect, enable, or disable telemetry:

    Terminal window
    dg config get telemetry
    dg config set telemetry true
    dg config set telemetry false

    The get command returns true, false, or null. Setting false prevents new reports, but it does not contact the collector or erase reports already received. Re-enabling starts a new consent period and does not fill in days while telemetry was disabled. To request deletion of received reports, follow the email process in the privacy notice.

    After the first explicit Yes, Delegator immediately attempts an installation report. This identifies a consenting initialized instance; it cannot measure all downloads, installations, devices, or people. Daily reports contain aggregate ticket and run counts, normalized agent families, and a snapshot of selected current settings. Delegator does not send ticket text, prompts, source code, paths, project names, logs, errors, command arguments, credentials, or individual ticket and run identifiers.

    An installation report without later daily activity does not prove that someone abandoned or uninstalled Delegator. It can also mean brief use, disabled telemetry, no later invocation, a network failure, or an eligible final day that was never sent. Zero-count daily rows confirm reporting coverage; they do not prove active use.

    Reports use a random instance identifier stored in the local SQLite database and, when the operating system provides suitable input, an application-specific derived machine hash. Raw operating-system machine identifiers and network-interface addresses are not sent. These values are pseudonymous: they can connect reports from the same instance or machine, but a machine hash may change or be shared and does not reliably represent one person.

    Daily reports cover only whole Coordinated Universal Time (UTC) days that were fully inside the current uninterrupted consent period. Delegator skips the partial day when you opt in, any disabled or interrupted day, and the current unfinished day. On a later invocation it catches up every eligible day through yesterday, including zero-count days, within the 90-day reporting window.

    A failed request does not affect command output or queue work. Delegator rebuilds the request from local data and can retry after at least 15 minutes, or later when the server asks it to wait longer. There is no permanent telemetry process. A request already in flight may still arrive after you disable telemetry.

    The collector validates allowlisted fields and removes unknown fields before it stores a small envelope and sanitized JavaScript Object Notation (JSON). Each report has a stable identifier. The first accepted copy is retained, and later retries cannot replace its counts, settings, or receipt time. Linkable reports are removed after 90 days; Cloudflare D1 recoverable history can retain deleted data separately for up to 30 days depending on its service plan.

    Deletion is handled by the operator through protected access. A request adds the instance identifier to a revocation register, removes its installation, usage, and settings reports, and prevents delayed reports from recreating them. The revocation record remains for the service lifetime for that limited purpose.

    Reference: dg init, dg config get, and dg config set.