Installation Channels

Draft 0.1 — 2 August 2026
The channel order in this document is a product strategy, not a commitment that every adapter ships in the first release.

Distribution thesis

ANUKA should not require a company to migrate its stack before receiving value.

The shared core remains one system. Installation adapters bring that system into the tools companies already use.

One project identity, one capability model, many installation channels.

Every adapter MUST connect to the same ANUKA project, permission model, event vocabulary, and Presence Protocol. An adapter must not create a separate shadow profile merely because it was installed through a different platform.

The two primary channels

1. Browser extension

The extension makes ANUKA available to the participant across the web.

Primary jobs:

• open ANUKA through an explicit browser action;
• detect official ANUKA presence;
• open Backstage in a side panel or extension page;
• show observed profiles with unmistakable unclaimed labels;
• submit feedback and opportunity proposals;
• follow products and companies;
• access the participant’s passport and work queue;
• request optional per-site permissions only when useful.

Recommended implementation baseline:

• Manifest V3 for Chromium;
• WebExtensions-compatible APIs;
• WXT as the initial open-source build framework;
• one codebase with browser-specific manifests and release packages;
• Chrome, Edge, Firefox, and Safari as distinct tested targets.

WXT states that it supports Chrome, Firefox, Edge, Safari, Chromium browsers, Manifest V2 and V3, TypeScript, and automated publishing. It is an implementation choice, not an ANUKA protocol dependency.

2. Google Tag Manager template

The GTM template makes ANUKA an official owner-installed part of the website without requiring a product-code release.

Primary jobs:

• configure the ANUKA project identifier;
• load the approved Site SDK;
• select modules;
• respect configured consent requirements;
• read only allowlisted dataLayer values;
• emit documented ANUKA events;
• enable preview and debug behavior;
• make updates available through the Community Template Gallery process.

Google describes custom templates as a safer, permission-centric alternative to Custom HTML and custom JavaScript variables because they run in sandboxed JavaScript and request explicit permissions.

The public gallery requires a GitHub repository containing the exported template.tpl, metadata.yaml, LICENSE, and README.md, with version updates tied to commit SHAs.

Channel ladder

The recommended rollout sequence is based on distribution leverage, implementation cost, and the amount of owner trust required.

Tier 0 — Hosted demo

A prospect enters a domain and previews an example Backstage without installing code.

The demo MUST not represent inferred data as owner-approved or verified.

Tier 1 — Direct script

A small loader installed with one script tag.

Best for:

• founders;
• static sites;
• custom apps;
• rapid pilots;
• platforms without a dedicated adapter.

Offer two release channels:

• Pinned: immutable version URL with SRI hash;
• Managed: stable loader that receives compatible updates under a declared policy.

Tier 2 — Google Tag Manager

Best for:

• SaaS marketing sites;
• growth teams;
• agencies;
• organizations that control tags separately from application releases.

Initial launch may provide Custom HTML instructions, but the strategic artifact is a Community Template Gallery submission.

Tier 3 — Browser extension

Best for:

• participants who want ANUKA across the web;
• contributors, testers, investors, and product explorers;
• viral acquisition from unconnected sites;
• participant identity and personal work queue.

Tier 4 — JavaScript and framework SDKs

Packages:

Record at a glance

JavaScript and framework SDKs

Field	Example value	Why it matters
Canonical shared implementation	The base contract used by all thin adapters.
Embeddable web surface	Direct integration for website experiences.
Framework adapters	Thin framework-native bindings over core.
Site-framework adapters	Integration for server-rendered web products.

Framework packages SHOULD remain thin adapters over @anuka/core rather than independent implementations.

Tier 5 — CMS and commerce adapters

Candidates:

• WordPress plugin;
• Shopify app extension;
• Webflow app;
• Framer component;
• Ghost integration;
• HubSpot app.

Prioritization should be based on actual resident demand and distribution access, not a desire to display a long integrations list.

Tier 6 — Event and data platforms

Candidates:

• Segment destination/source;
• RudderStack integration;
• PostHog app or webhook adapter;
• analytics and warehouse connectors;
• server-side GTM client and tag;
• customer data platform destinations.

These integrations expand evidence and automation but require stronger data governance than the public widget.

Tier 7 — Agent and developer interfaces

• OpenAPI description;
• MCP-compatible server where appropriate;
• versioned skill.md packages;
• CLI;
• GitHub App;
• webhook subscriptions;
• reference agent tools.

Agents MUST use the same permissions and audit model as human clients.

Browser release matrix

Browser	Initial format	Notes
Chrome	Manifest V3	Primary Chromium target and Chrome Web Store policy baseline
Microsoft Edge	Chromium-compatible package	Microsoft says Chrome extension APIs and manifest keys are largely code-compatible, with testing and store-specific packaging still required
Firefox	WebExtensions package	Test permissions, APIs, manifest behavior, and restricted domains separately
Safari	Safari Web Extension	Apple supports common JavaScript, HTML, CSS, and extension formats, but packaging and App Store distribution require Apple tooling
Brave and other Chromium browsers	Chromium package where supported	Test rather than assume full compatibility; store and update channels differ

One source repository does not mean one untested binary.

Channel comparison

Browser release comparison

Each browser channel needs its own package, policy check and compatibility validation; compatibility is never assumed from shared source code alone.

Chrome

Format

Manifest V3

Compatibility

Primary Chromium target

Validate

Chrome Web Store policy and target-browser tests

Microsoft Edge

Format

Chromium package

Compatibility

Largely code-compatible, store-specific packaging

Validate

Edge testing and store validation

Firefox

Format

WebExtensions

Compatibility

Permissions and manifest behavior differ

Validate

API, restricted-domain and manifest tests

Safari

Format

Safari Web Extension

Compatibility

Common web formats, Apple tooling required

Validate

Packaging and App Store distribution checks

Brave / Chromium

Format

Supported Chromium package

Compatibility

Store and update channels differ

Validate

Explicit browser testing

Permission strategy for the extension

Default install

Request only capabilities required for the extension shell:

• activeTab;
• scripting if injection is needed after invocation;
• narrowly justified storage;
• side panel where supported.

Do not request <all_urls> at installation merely for future features.

Optional site access

Persistent host permissions may be offered when the participant explicitly enables features such as:

• automatic badge activation on chosen sites;
• continuous opportunity notifications for selected domains;
• persistent Backstage integration;
• authorized workflows requiring page context.

The permission prompt MUST explain the immediate benefit and affected origins.

Enterprise deployment

Managed-browser policies may permit organization-controlled installation and permissions. Enterprise deployment is a separate mode and must not weaken the public-store privacy model.

GTM template fields

The first template SHOULD expose a small configuration surface:

Field	Purpose
projectId	Connects the site to one ANUKA project
environment	Production, staging, or development
modules	Widget features enabled by the owner
position	Badge or launcher placement
language	Interface language or automatic selection
consentMode	Basic policy for nonessential collection
dataLayerMapping	Explicit mapping of allowlisted business events
debug	Preview logging without production noise

The template MUST NOT accept arbitrary executable JavaScript.

GTM permissions

A template requests permissions based on the sandbox APIs it uses. Permissions should be as narrow as possible.

Expected permission classes may include:

• injecting or loading the approved script URL;
• reading allowlisted global or data-layer values;
• sending requests only to declared ANUKA endpoints;
• reading or writing narrowly scoped storage where enabled;
• reading consent state;
• logging in preview mode.

Every new permission is a product decision and a trust cost.

Community Template Gallery workflow

The GTM adapter should live in its own public repository, for example:

Record at a glance

Community template repository

Field	Example value	Why it matters
sergous/anuka-gtm-template	Public, independently releasable adapter.
template.tpl · metadata.yaml	The installable template and its declared capabilities.
LICENSE · README.md	Reuse terms and usage guidance.
tests/	Evidence that the adapter continues to work as promised.

Release procedure:

1. build and test as a private custom template;
2. verify field labels, permissions, and error behavior;
3. export template.tpl;
4. add metadata and a supported license;
5. publish the repository;
6. submit the GitHub URL to the Gallery;
7. release updates by referencing immutable commit SHAs in metadata.yaml;
8. retain compatibility and migration notes.

Google’s Gallery terms state that user licenses for submitted templates are provided under Apache License 2.0. The exact terms must be reviewed when the repository is prepared.

Direct-script contract

Illustrative loader:

<script
  src="https://cdn.anuka.network/widget/0.1.0/widget.js"
  data-anuka-project="prj_01H..."
  data-anuka-modules="feedback,roadmap,opportunities"
  integrity="sha384-..."
  crossorigin="anonymous"
  defer
></script>

The loader SHOULD:

• remain small;
• avoid blocking page rendering;
• initialize only after configuration validation;
• provide a destroy/unmount API;
• isolate CSS;
• handle single-page-app navigation;
• emit lifecycle events;
• fail without breaking the host page;
• expose its exact version;
• support strict CSP guidance.

Package design

@anuka/core SHOULD contain:

• schemas;
• event types;
• capability identifiers;
• manifest parsing;
• validation;
• API client interfaces;
• privacy modes;
• no framework-specific UI.

@anuka/widget SHOULD contain the embeddable user interface.

Framework adapters SHOULD provide idiomatic mounting, lifecycle, and type integration while preserving core behavior.

Adapter conformance

Every official adapter MUST pass a common test suite covering:

• project identity;
• manifest discovery;
• capability mapping;
• event names and payloads;
• consent and collection behavior;
• error and offline behavior;
• accessibility;
• version reporting;
• security headers or permissions relevant to the platform;
• visual owner branding rules;
• unclaimed and verified labels.

No lock-in rule

A resident company SHOULD be able to:

• export its public configuration;
• switch from GTM to direct SDK without changing project identity;
• self-host an approved open component where supported;
• remove the adapter cleanly;
• revoke keys and permissions;
• preserve its contribution and evidence history subject to policy and law.

Success metrics

Track by channel:

• installation completion rate;
• time to first visible value;
• permission acceptance rate;
• active connected origins;
• widget interaction rate;
• extension weekly active participants;
• extension-to-site claim conversions;
• site-to-extension installs;
• adapter error rate;
• consent-denied safe-operation rate;
• uninstall and disconnect reasons;
• verified resident conversion.

Do not optimize installation volume at the expense of permission trust, data quality, or product utility.

Recommended MVP package

The first commercially useful release should include:

1. direct script;
2. GTM custom template prepared for Gallery submission;
3. Chrome/Edge extension using activeTab;
4. public Backstage and feedback;
5. one shared project ID and Presence Manifest;
6. an installation debugger;
7. documentation and copy-paste setup;
8. events sufficient to measure the two-sided growth loop.

Firefox and Safari should remain explicit targets, but shipping dates should follow tested product readiness.

Sources

• WXT introduction
• WXT manifest generation
• Chrome permission warning guidelines
• Mozilla WebExtension permissions
• Microsoft — Port a Chrome extension to Edge
• Apple — Safari web extensions
• Google Tag Manager custom templates
• Submit to the GTM Community Template Gallery
• GTM template style guide
• GTM Gallery developer terms

Verification record

• Sources opened and checked: 2 August 2026
• Adapter selections: Proposed, not ratified
• Store compatibility testing required: Yes
• Gallery terms review required before submission: Yes