ANUKA Presence Protocol

Draft 0.1 — 2 August 2026
This document defines the network-level presence model. It does not require every resident product to expose the same interface or the same data.

Purpose

ANUKA needs to exist in two places at once:

inside a product, where the product owner can expose an official Backstage, opportunities, evidence, feedback, and selected metrics;
inside the participant’s browser or agent, where ANUKA can be opened on a site even before that site has joined the network.

The ANUKA Presence Protocol defines how those surfaces discover one another, exchange declared capabilities, establish trust, and remain understandable to people.

The protocol is designed around one principle:

A website controls its official presence. A participant controls their browser. Neither side silently acquires authority over the other.

Scope

The Presence Protocol covers:

discovery of ANUKA-aware websites and products;
official and unofficial company profiles;
the ANUKA site widget and full-screen Backstage;
browser-extension behavior;
a machine-readable presence manifest;
capability negotiation between a site and an extension;
consent, permissions, and data minimization;
public, permissioned, and private information boundaries;
installation through direct script, Google Tag Manager, packages, plugins, and extensions;
provenance and verification labels;
graceful operation when one or more channels are unavailable.

It does not define:

the complete identity protocol;
the complete reputation protocol;
payment settlement;
bounty contracts;
investor qualification;
universal certification criteria;
a right to modify third-party websites without user or owner authorization.

Presence surfaces

Site Presence

A website owner intentionally installs an ANUKA adapter. Examples:

direct JavaScript loader;
Google Tag Manager Community Template;
NPM or framework package;
CMS plugin;
ecommerce app extension;
native server integration.

Site Presence is the authoritative source for the site’s declared ANUKA project identifier, selected capabilities, official links, and owner-controlled public information.

Browser Presence

A participant installs the ANUKA browser extension. Browser Presence may:

detect an official ANUKA installation;
open a trusted Backstage;
show publicly available ANUKA records;
let the participant submit feedback or an opportunity proposal;
let the participant follow, compare, or save a company;
show an unclaimed profile assembled from permitted public sources;
request additional access only when a feature requires it.

Browser Presence MUST NOT imply that an unclaimed company has endorsed ANUKA.

Agent Presence

An authorized AI agent discovers ANUKA capabilities through documented APIs, schemas, and a machine-readable presence manifest.

Agent Presence MUST identify:

the agent principal;
the permissions granted;
the tool or skill version;
the source of data;
whether an action is simulated, proposed, or executed;
the audit record for consequential actions.

Network Presence

The ANUKA Network indexes public and permissioned presence records so that participants can discover:

resident products;
claimed organizations;
opportunities and bounties;
public evidence;
contributor communities;
product stewards;
verified capabilities.

Network Presence is an index and coordination layer. It is not automatic ownership of resident-product data.

Presence states

Every organization–origin relationship has one explicit state.

1. Unknown

ANUKA has no recognized profile for the origin.

The extension may offer a neutral action such as Create a private note or Suggest this company to ANUKA.

2. Observed

ANUKA has public information or participant activity associated with the origin, but the company has not claimed the profile.

Required label:

Unclaimed profile — this company has not verified or endorsed this ANUKA page.

Observed profiles MUST distinguish:

source-provided facts;
community statements;
inferred relationships;
disputed claims;
unavailable or stale data.

3. Claimed

An authorized organization representative has proved control of the origin or completed another accepted claim process.

Claimed means control was checked under a declared method. It does not mean the company is certified, investable, safe, or high quality.

4. Connected

The site has an active ANUKA adapter and exposes a valid Presence Manifest.

Connected sites may provide official capabilities such as feedback, roadmap, opportunities, feature sponsorship, public metrics, and Backstage navigation.

5. Resident

The product or company has accepted the current resident agreement or network rules applicable to its participation.

Resident status MUST name:

the participating legal or operating entity;
the ruleset version;
the enabled network services;
the effective date;
material exceptions;
termination and exit conditions.

6. Verified

One or more claims about the company or product have passed named verification policies.

Verified MUST never appear without context. Interfaces MUST say what was verified, by whom, using what evidence, and when.

Examples:

domain control verified;
Stripe-origin revenue event verified;
release-readiness review passed;
ownership record verified against a named source;
metric provenance verified for a stated period.

Capability model

A connected site publishes a list of capabilities rather than granting the extension general authority.

Initial capability identifiers:

presence.profile.read
presence.backstage.open
feedback.create
feedback.vote
feedback.publish.request
roadmap.read
feature.sponsor
opportunity.list
opportunity.apply
experiment.propose
experiment.observe
metric.public.read
attestation.read
community.join

Future capabilities MUST be versioned and documented. Unknown capabilities MUST be ignored safely.

A capability declaration MUST include:

identifier;
protocol version;
access class;
endpoint or interaction mode;
authentication requirement;
consent requirement;
rate limit or abuse control;
data categories involved;
responsible product or entity.

Access classes

Public

Available without account or organization membership.

Public does not mean unrestricted reuse. Copyright, privacy, contract, database, trademark, and platform terms may still apply.

Participant

Available to an authenticated ANUKA participant.

Community

Available to members of a named product community or program.

Qualified

Available after satisfying declared evidence, reputation, jurisdiction, age, identity, or competence requirements.

Organization

Available to authorized members of the organization.

Investor

Available under a controlled diligence or investor-access workflow.

Private

Not exposed through Presence Protocol discovery.

Founder and owner control

The authorized site owner controls:

whether the site is connected;
which capabilities are enabled;
which metrics are public;
which records require authentication;
moderation and publication policy;
whether feature sponsorship is available;
who may create or accept opportunities;
whether the organization is listed as a resident;
revocation of the connection.

Owner control does not permit false or misleading claims. Public statements remain subject to evidence policy, applicable law, and ANUKA network rules.

Participant control

The participant controls:

whether to install the extension;
when the extension receives page access;
which optional permissions are granted;
whether to authenticate;
which profile information is presented;
whether a contribution is public, private, or pseudonymous where supported;
whether to follow or interact with a company;
whether to revoke permissions and disconnect.

The extension SHOULD work in an explicit user-invoked mode using temporary activeTab access before requesting persistent host access.

Presence Manifest

A connected site SHOULD publish a machine-readable manifest at:

/.well-known/anuka

The use of /.well-known/ follows the path convention defined by RFC 8615. A production protocol name should be registered or otherwise governed before claiming standards-level interoperability.

Illustrative response:

{
  "spec": "https://anuka.network/spec/presence/0.1",
  "origin": "https://example.com",
  "projectId": "prj_01H...",
  "state": "connected",
  "manifestVersion": "0.1.0",
  "issuedAt": "2026-08-02T00:00:00Z",
  "expiresAt": "2026-09-02T00:00:00Z",
  "capabilities": [
    {
      "id": "feedback.create",
      "access": "public",
      "interaction": "widget"
    },
    {
      "id": "opportunity.list",
      "access": "participant",
      "endpoint": "https://api.anuka.network/projects/prj_01H/opportunities"
    }
  ],
  "publicKeys": [
    {
      "id": "owner-key-1",
      "type": "JsonWebKey2020",
      "purpose": "manifest-signing",
      "publicKeyJwk": {}
    }
  ],
  "signature": "..."
}

This example is not yet a final schema.

Discovery order

Clients SHOULD discover presence in this order:

a validated in-page handshake from the official site adapter;
the origin-bound /.well-known/anuka manifest;
an ANUKA Network registry lookup for the exact origin;
a clearly labeled observed profile;
no profile.

A lower-trust source MUST NOT silently override a higher-trust source.

Authority and conflict rules

When sources disagree:

preserve each source and timestamp;
prefer current origin-controlled declarations for official capabilities;
do not erase verified historical records merely because a current owner changes a claim;
show disputes and corrections;
treat signatures as proof of signer control, not proof of truth;
avoid merging organizations based only on similar names or domains.

Public Backstage

Backstage is the human-facing experience built on the Presence Protocol.

A minimal Backstage MAY contain:

product identity;
claim and verification status;
community activity;
feedback and voting;
roadmap;
sponsored features;
public opportunities;
selected metrics and provenance;
recent releases and outcomes;
links to official policies and evidence.

Backstage MUST clearly distinguish:

official company statements;
community content;
ANUKA-computed summaries;
simulations;
verified records;
sponsored placements;
disputed or revoked claims.

Rendering modes

The same protocol can support multiple interfaces:

compact badge;
floating widget;
side panel;
full-screen Backstage;
embedded component;
browser-extension panel;
mobile app;
spatial or 3D business map;
AI conversation;
investor data room.

The protocol defines meaning and capability. It does not force one visual design.

Failure behavior

Presence MUST fail safely.

Examples:

if the API is unavailable, the host site remains usable;
if a signature is invalid, the client does not display verified status;
if a capability is unknown, the client ignores it;
if consent is absent, nonessential collection remains disabled;
if the extension lacks permission, it asks only when the user invokes the feature;
if a manifest is stale, the interface displays the last verified time;
if the site removes ANUKA, the extension may still show an observed profile but not an official connection.

Compatibility and versioning

The protocol uses semantic versions.

patch versions clarify or fix compatible behavior;
minor versions add optional compatible capabilities;
major versions may change required meaning or security assumptions.

Clients MUST declare supported versions. Servers SHOULD maintain at least one documented migration path when deprecating a major version.

Open implementation rule

The protocol schemas, capability registry, conformance tests, and reference clients SHOULD be open source under an OSI-approved license.

Hosted ANUKA services MAY be commercial. A resident product MUST be able to understand which parts are open protocol, open implementation, hosted service, or proprietary module.

Adoption test

The protocol is successful when:

a site can connect in minutes;
a participant can open ANUKA with an explicit gesture;
a browser or agent can discover official capabilities without scraping private data;
companies can control what they publish;
users can tell claimed, connected, resident, and verified states apart;
new adapters reuse the same project identity and capability model;
no channel becomes the sole point of control for the network.

Sources

Verification record

Sources opened and checked: 2 August 2026
Protocol status: Founding draft
Security review required before implementation: Yes
Privacy and legal review required before production: Yes