Countly allows:

Countly.q.push(['add_event',{
  "key": "click",
  "count": 1,
  "sum": 1.5,
  "dur": 30,
  "segmentation": {
    "key1": "value1",
    "key2": "value2"
  }
}]);

a new interface needs to be added:

MetricsProvider.accumulate.event(event: CountlyEvent, flush: boolean)
// event can be indexed by key,
// flush forces a flush to event queue.
accumulatedEvents = Record<key: string, event: CountlyEvent>;

Internally, events can be represented as a hash-map of events by key where:

• count represents the sum of count from each event.
• sum represents the sum of events accumulated.
• dur represents the duration over which the events were accumulated, defaults to 5 mins, but can be flushed earlier using flush param.

Optionally, an additional helper method can be provided to force flush the accumulated events synchronously. which can be hooked on the beforunload event.

MetricsProvider.accumulate.flush(key: string)
// this method is called when flush is set to true in `event` call.
// this will be a synchronous call:
Countly.add_event(accumulatedEvents[key])

• https://github.com/ipfs-shipyard/ignite-metrics/blob/main/docs/telemetry/images/single-toggle-modal.png
• https://github.com/ipfs-shipyard/ignite-metrics/blob/main/docs/telemetry/images/telemetry-modal-toggle.png
• https://github.com/ipfs-shipyard/ignite-metrics/blob/main/docs/telemetry/images/telemetry-modal-view1.png

See ipfs/public-gateway-checker#340, ipfs/public-gateway-checker#341, ipfs/public-gateway-checker#342 for more information

The work tracking doc should exist in notion, but policy, standards, and processes should all be defined in the GitHub repo.

Metrics documentation requirements make me think that the majority of docs existing in GitHub is the right decision:

• The public can access them easily
• The Public/devs can post questions/updates directed at documentation easily and publicly
• The public can be informed of updates and track update history easily
• Current and future devs can find this information and update it easily while not violating the above three items.

Tasks

• create docs in ipfs-shipyard/ignite-metrics
  • privacy policy based on https://github.com/ipfs/ipfs-companion/blob/main/PRIVACY-POLICY.md
  • Breakdown of metrics collection intentions (opt-out and what that entails)
    • This is what the user will see
    • This is what will be collected
    • This is what won't be collected
  • basic dev consumption docs on how to use for react/non-react packages (README)
  • Link to above docs in README.md
• create single notion page under our team notion page - https://pl-strflt.notion.site/Telemetry-b005d4f217f44db3986902c67d922cf4
  • Link to all metrics items (past, present, future)
  • Link to above pages in ignite-metrics (will probably be in PR)
  • Specify team methodology and ethics for metrics collection and tools/UI used for doing so
    • specify process to follow for updating metrics.
  • Update Notion doc to address comments from Steve

We need to determine whether to prioritize working on exports of react components from this library, or getting metrics integrated in all the projects listed at ipfs/ipfs-gui#105. To do so, we need to know:

• How many of the projects listed in ipfs/ipfs-gui#105 are using react
• Are the majority of those projects react?
  • if not, don't prioritize react components
  • if so, prioritize react components styling and exports to match ipfs/public-gateway-checker/issues/341, ipfs/public-gateway-checker/issues/340, ipfs/public-gateway-checker/issues/342

The result of this task is to determine whether we will focus on exporting react components from this library prior to finishing #105, or doing this later.

While debugging #129 the test suite did not give enough info on what calls were failing, the final fixes were added in:

• 3b1cccd
• dc52e2f

This could have been simpler if the test runner reported the call order in the failure scenario.

Example: https://github.com/Countly/countly-sdk-nodejs/blob/master/examples/bulk_import_example.js#L20

The interface for ignite-metrics can be exposed such that we should allow tracking events against a unique identifier/deviceId.

The change could look like:

const metrics = new MetricsProvider({
  ...,
  deviceDetail: {
    deviceId: <device_id>,
    os: <os>,
    arch: <arch>,
    appVersion: <version>,
    additionalDetails: <overload>
  }
})

This will then call the add_user method and set the user_details and return an instance of the user instead of countly.

Countly web sdk provides plenty of customizable features: https://support.count.ly/hc/en-us/articles/360037441932-Web-analytics-JavaScript-#setup-properties

• These properties should be allowed to be passed to countly instance.
• A better default should be shipped by default:
  • Sync every 5000ms instead of 500ms.
  • Increase the max events from 100 to 1000.

Background

The PL Inc Countly account that has been used is getting shut down 202402 because of costs and organizational changes within PL Inc. Something needed to be done about the account, and it was agreed that amongst the transitions that are happening in 2024 that the Countly metrics being collected won't be reviewed closely. In addition, there are other ways for getting high level usage of major projects like IPFS Companion (e.g., use the Webstore usage metrics) or IPFS Desktop (e.g., use probelab metrics with user-agent breakdown for Amino DHT participation).

Apps/Sites In Scope

That said, it would still be good to get metrics around the different sites and apps that had been collected previously with Countly:

• ipfs-companion
• ipfs-desktop
• public-gateway-checker
• ipfs-webui-kubo
• ipfs-webui
• cid-utils-website
• explore.ipld.io
• pinning-service-compliance
• starmap.site
• ipfs-check
• ipfs-dag-builder-vis
• pl-diagnose

What to do

An ignite-metrics adapter to Plausible should be built. This would allow an update in the properties above to a new ignite-metrics and still at least get some metrics flowing. It would also give a nice public dashboard like we have with other related projects that are already on Plausibnle (e.g., https://plausible.io/ipfs.tech/).

When to do it

This work of building an ignite-metrics/Plausible adapter is separate from shutting down the PL Inc County account. The PL Inc Countly shutdown will occur in early February. This work here to migrate to Plausible will be scheduled for later in the year, or when needed.

Related Items

• https://pl-strflt.notion.site/202401-Countly-Handling-cb2fd621257a4d998c8e1b57dedbeaf8 - Discussion and handling of the Countly shutdown

We need to use .tech so we are not running into issues like https://blog.nft.storage/posts/2022-04-29-gateways-and-gatekeepers

related to https://github.com/protocol/infra/issues/1015

Note that until ipfs/ipfs-gui#125, ipfs/ipfs-gui#130, and https://discuss.ipfs.tech/t/ipfs-gui-metrics-changes-in-progress/15695 have been available to the community for feedback for enough time (at least two weeks: ETA Jan 20th), we will continue with the implementation we currently have in public-gateway-checker:

• metrics implementation was already merged (ipfs/public-gateway-checker#309), but it's not opt-out yet. I.e. until you accept/decline, no metrics are sent.

• provide necessary consent on page-load
• Allow users to disable necessary metrics (see ipfs/ipfs-gui#125 (comment))
  • Send a metric when users disable necessary metrics. This would give us a signal about the number of users we have that prefer zero telemetry collection

Blocks: ipfs/ipfs-companion#1127
Related: Countly/countly-sdk-web#382

The issue:

• countly-web-sdk ships as an iife which bundles everything, including dependence on window object and implements XMLHttpRequest. Both of these are blockers for implement countly in webworkers (companion background worker and service workers)

Proposed Fix:

• Since not all APIs are used by ignite-metrics, it's possible to write a minimal set of function calls that can call countly endpoints from within the webworker.
• APIs Needed:
  • Authentication Flow
  • Session Create Flow
  • Push Event Flow
• Other considerations:
  • We already implement an eventAccumulator
  • We will need a batching mechanism to not overwhelm the endpoint.
• Limitations:
  • webworkers don't have access to DOM, window, XMLHttpRequest and localStorage, so:
    • use fetch to open connections to countly endpoints
    • use indexedDB for storage needs. The browser API is awful to use, but projects like Dexie provide a decent API to work with indexedDB.
• Shipping:
  • Since webpack supports webworker build target as of v5. We can simply provide an export target without changing a lot of things.

Other Thoughts

• If countly can implement a modular SDK, we might be able to treeshake most of unreachable code and shim window if still needed.
• In the short term this can help unblock and have light and sane way of communicating with countly.

CC: @SgtPooki

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

We should use something similar to:

    rules: {
        'import/order': [
            'error',
            {
                alphabetize: {
                    order: 'asc',
                    caseInsensitive: false,
                },
                'newlines-between': 'always',
                // the overall order of imports
                groups: ['builtin', 'external', 'internal', ['sibling', 'parent', 'index'], 'object'],
                pathGroupsExcludedImportTypes: ['builtin'],
                pathGroups: [
                    { // 3p imports
                        pattern: '+(!(@))*/**',
                        group: 'external',
                        position: 'before',
                        patternOptions: { nonegate: true },
                    },
                    { // scoped external imports excluding our 2p scoped packages
                        pattern: '@!(ipfs|libp2p|ipfs-shipyard|ipld|multiformats)/**',
                        group: 'external',
                        position: 'after',
                        patternOptions: { nonegate: false },
                    },
                    { // our 2p scoped packages
                        pattern: '@{ipfs,libp2p,ipfs-shipyard,ipld,multiformats}/**',
                        group: 'parent',
                        position: 'before',
                        patternOptions: { nonegate: true },
                    },
                    { // our relative (this package) imports
                        pattern: '.*/**',
                        group: 'index',
                        position: 'after',
                        patternOptions: { dot: true, nonegate: true },
                    },
                ],
            },
        ],

The preferences modal used for apps without settings pages -- first mentioned at ipfs/public-gateway-checker#340 (comment) -- needs to support multiple toggles.

V0 state

V1 state