kubo/docs/telemetry.md
Hector Sanjuan 4255cc3889
feat: telemetry plugin (#10866)
* Initial pass at Telemetry plugin

Currently, IP Shipyard, with the help of Probelab, monitor and extract
Amino/IPFS public network metrics with the use of DHT crawlers and
bootstrappers (via peerlog plugin). For example, we log all peer IDs seen and
their AgentVersion/Addresses obtained from the `identify` protocol, which
provides insights into protocol usage, total number of peers etc.

We would like to increase the ability to obtain more insights from the network
by collecting some more information in the future, but also to give users more
control over this collection (i.e. opt-out). The information collected will
not allow unique identification of anyone and is only used for aggregation.

Now, this PR explores a way of moving in this direction:

* A new "telemetry" fx plugin is in charge of dealing with telemetry
* The FX plugin allows to plug and make decisions / take actions during the setup phase:
  * We can inspect whether we are using Private Networks before the libp2p.Host has been initialized.
  * We can send telemetry after the libp2p Host is initialized.
  * Everything is self-contained. Custom builds can remove the plugin altogether without needing to surgically edit the code.

As for behaviour:

* The user can opt-in/out via EnvVar, file in the repo path or plugin configuration.
* Users on private networks or with custom bootstrappers are detected, offered a wall of text explaining why we need telemetry and invited to opt-in. Opt-out happens otherwise on a timeout (with no input). Their preferences are stored.
* Users on standard settings are opted-in by default. This is the status quo in Kubo already, except they don't get a chance to opt out.

The telemetry libp2p protocol is yet to be defined, but expect something similar to identify, with a protobuf being pushed to bootstrappers or to a specific telemetry node that we define. In the case of pnets, this will be done with a temporary peer.

* checkpoint

* telemetry plugin: second pass

* On first run it generates a UUID and shows a message to the user.
* UUID is persistend to "telemetry_uuid"
* Sends telemetry 1 minute after boot and every 24h
* LogEvent is the thing containing all the telemetry that is sent
* Opt-out possible via env-var or plugin configuration

* Telemetry: add changelog and environment variable documentation

* docs: improved daemon message

making it more obvious nothing was sent yet
and that user had 15m to out-out

plus some debug logs that confirm opt-out

* refactor: rename IPFS_TELEMETRY_MODE to IPFS_TELEMETRY

* fix: add User-Agent header to telemetry requests

---------

Co-authored-by: Andrew Gillis <11790789+gammazero@users.noreply.github.com>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
2025-08-18 20:46:05 +02:00

4.0 KiB

Telemetry Plugin Documentation

The Telemetry plugin is a feature in Kubo that collects anonymized usage data to help the development team better understand how the software is used, identify areas for improvement, and guide future feature development.

This data is not personally identifiable and is used solely for the purpose of improving the Kubo project.


🛡️ How to Control Telemetry

The behavior of the Telemetry plugin is controlled via the environment variable IPFS_TELEMETRY and optionally via the Plugins.Plugins.telemetry.Config.Mode in the IPFS config file.

Available Modes

Mode Description
on Default. Telemetry is enabled. Data is sent periodically.
off Telemetry is disabled. No data is sent. Any existing telemetry UUID file is removed.
auto Like on, but logs an informative message about the telemetry and gives user 15 minutes to opt-out before first collection. This mode is automatically used on the first run when IPFS_TELEMETRY is not set and telemetry UUID is not found (not generated yet). The informative message is only shown once.

You can set the mode in your environment:

export IPFS_TELEMETRY="off"

Or in your IPFS config file:

{
  "Plugins": {
    "Plugins": {
      "telemetry": {
        "Config": {
          "Mode": "off"
        }
      }
    }
  }
}

📦 What Data is Collected?

The telemetry plugin collects the following anonymized data:

General Information

  • Agent version: The version of Kubo being used.
  • Platform details: Operating system, architecture, and container status.
  • Uptime: How long the node has been running, categorized into buckets.
  • Repo size: Categorized into buckets (e.g., 1GB, 5GB, 10GB, etc.).

Network Configuration

  • Private network: Whether the node is running in a private network.
  • Bootstrap peers: Whether custom bootstrap peers are used.
  • Routing type: Whether the node uses DHT, IPFS, or a custom routing setup.
  • AutoNAT settings: Whether AutoNAT is enabled and its reachability status.
  • Swarm settings: Whether hole punching is enabled, and whether public IP addresses are used.

TLS and Discovery

  • AutoTLS settings: Whether WSS is enabled and whether a custom domain suffix is used.
  • Discovery settings: Whether mDNS is enabled.

Reprovider Strategy

  • The strategy used for reprovider (e.g., "all", "pinned"...).

🧑‍🤝‍🧑 Privacy and Anonymization

All data collected is:

  • Anonymized: No personally identifiable information (PII) is sent.
  • Optional: Users can choose to opt out at any time.
  • Secure: Data is sent over HTTPS to a trusted endpoint.

The telemetry UUID is stored in the IPFS repo folder and is used to identify the node across runs, but it does not contain any personal information. When you opt-out, this UUID file is automatically removed to ensure complete privacy.


📦 Contributing to the Project

By enabling telemetry, you are helping the Kubo team improve the software for the entire community. The data is used to:

  • Prioritize feature development
  • Identify performance bottlenecks
  • Improve user experience

You can always disable telemetry at any time if you change your mind.


🧪 Testing Telemetry

If you're testing telemetry locally, you can change the endpoint by setting the Endpoint field in the config:

{
  "Plugins": {
    "Plugins": {
      "telemetry": {
        "Config": {
          "Mode": "on",
          "Endpoint": "http://localhost:8080"
        }
      }
    }
  }
}

This allows you to capture and inspect telemetry data locally.


📦 Further Reading

For more information, see: