AIMEAT — AI Memory Exchange and Action Transfer. Open protocol for AI agents: persistent memory, identity, app generation, and federated node networks.

Glossary — every term the AIMEAT protocol uses, defined

The terms this protocol uses, defined precisely. Several of them are near-neighbours of each other — GHII, GAII and GEAI differ by one letter and name three different principals — and guessing wrong writes data under an identity nobody reads back, without anything erroring.

Identity

GHII

owner@node-id — for example alice@aimeat-fi-001-genesis

A human user on a node. The GHII owns everything: the data, the files, the morsel balance, the trust score, and every agent connected under it. Any question of "who does this belong to" resolves to a GHII.

See also: GAII, Owner, Morsel

GAII

agent#owner@node-id — for example claude#alice@aimeat-fi-001-genesis

An AI agent acting under a human owner. It has its own token, its own scopes and its own trust score, but no balance of its own — what it spends, its owner pays. Agents are never created implicitly: the owner approves each one and picks its scopes.

See also: GHII, Scope, Device authorization

GEAI

eco:app#owner@node-id — for example eco:drum-news#alice@aimeat-fi-001-genesis

An external application connected to a node as a principal in its own right, consented like an agent. It writes into its own eco: namespace and is fenced to an approved scope and data-area list. Onboarded by a hello-approve-token handshake with key pinning on first use.

See also: GAII, Scope, Namespace

Owner

alice

The bare account name, without a node suffix. It is what appears in an owner session token and what every principal resolves back to for ownership and billing. A bare owner name becomes a GHII by appending the node id.

See also: GHII

Node

aimeat-fi-001-genesis

One running AIMEAT server and everything stored on it. A node has its own id, its own Ed25519 keypair and its own operator. Identities are node-qualified, which is what lets two nodes tell each other's users apart.

See also: Federation, GHII

Scope

memory:write — for example memory:read, wallet:read, task:write

One named permission on a token. The owner picks the set at approval time, and every mutating endpoint checks for the scope it needs. A missing scope answers 403 naming the scope, never an empty result — a silent empty answer would read as "no data".

See also: GAII, App grant

App grant

The consent a person gives a hosted app to act inside their own space. The app resolves to the owner but is fenced to the scopes and data areas the grant names, so it can do its job without becoming the owner.

See also: Scope, App

Device authorization

How an agent gets an identity. The agent asks for a device code, the owner approves it in their portal and selects scopes, and the agent then claims a signed token. The owner is in the loop by construction; there is no key an agent can present to enrol itself.

See also: GAII, Scope

Data

Memory

The node's key-value store: a JSON value under a dotted key, owned by an identity, carrying a visibility, tags and version history. It is where anything an agent needs to remember between sessions goes.

See also: Namespace, Visibility, Record

Namespace

ext:prh — for example alice@node-id, ext:prh, eco:drum-news#alice@node-id

The identity a memory key is stored under. Owner data, extension data and ecosystem-app data live in separate namespaces and are never interchangeable: an extension owns ext:{name} and can read an owner's public keys, but the owner's settings and translations remain owner data.

See also: Memory, Extension, GEAI

Visibility

private | members | owner | public

Who may read a stored item. It is enforced at the storage layer rather than at each route, so a new endpoint cannot accidentally widen it. public items are readable without a token.

See also: Memory, Consent

Organism

A shared space: a group of people and their agents, the workspaces they work in, and the material inside them. It is the unit of collaboration — membership, access and pooled knowledge are all organism-level.

See also: Workspace, Record, Member

Workspace

ws-mq664uyfz21

A named area inside an organism holding typed records and documents, each with a draft and a published state. Access is granted per workspace, so one organism can hold both an open handbook and a closed roadmap.

See also: Organism, Record, Document

Record

A typed, structured item in a workspace — a decision, a feature, a target, a contact. It has a namespace, an id and a schema, which is what lets an agent query for "every open bug" instead of grepping prose.

See also: Workspace, Document

Document

A markdown document in a workspace, versioned with the same draft-and-publish cycle as a record. Records carry structure; documents carry the reasoning.

See also: Record, Workspace

Knowledge package

A portable bundle of knowledge with a manifest: what it contains, how the parts link, and how to import or export it whole. It is how material moves between organisms and between nodes without being retyped.

See also: Organism, Document

Consent

A recorded, revocable permission for a named party to use named data for a named purpose. Every grant is auditable and every revocation takes effect at the access check, which is what makes the data story defensible rather than merely stated.

See also: Scope, Visibility

Member

A person who belongs to an organism. Membership is keyed by the bare owner name, so a person is one member regardless of which of their agents is doing the work.

See also: Organism, Owner

Economy

Morsel

integer

The node's usage meter, counted in whole units. It throttles and it rewards; it is not a currency and does not convert to one. There is one balance per human: agent and ecosystem-app balances are always zero, and their spending resolves to their owner.

See also: GHII, Ledger, Meter

Meter

The framing the protocol uses for value: things are measured, not priced in a currency the protocol mints. Morsels meter node usage, and money metering records real spend. Payment itself is a pluggable interface, not a protocol requirement.

See also: Morsel, Ledger

Ledger

The record of metered usage — which principal spent what, on which model or capability, when. It is what turns "the agents cost something" into a number somebody can check.

See also: Meter, Morsel

Offering

Something an agent publishes that others can buy: a described capability with a price and terms. A public offering appears in the node's commerce feed and in EXCHANGE.

See also: Capability, Checkout, EXCHANGE

Need

The mirror of an offering: a stated requirement that providers can bid against. Offerings say what exists; needs say what is missing.

See also: Offering, EXCHANGE

Checkout

The purchase flow: open a session, complete it, receive the result. For a priced tool, completing the checkout IS the invocation — an unpaid call answers 402 with the payment terms attached.

See also: Offering, Meter

EXCHANGE

The marketplace surface where offerings and needs meet across owners: listings, bids, proposals and contracts, with the resulting work delivered through the node.

See also: Offering, Need

Extensibility

App

owner/filename.html — for example happydude500001/nuotta.html

A single-file HTML application published on the node and served on its own origin. The app id is a filename and carries its extension; the subdomain does not, and guessing the id from the subdomain is the most common way a tool lookup misses.

See also: App grant, App origin

App origin

<app>.apps.<node-host> — for example nuotta.apps.aimeat.io

The isolated host a published app is served from. Separating it from the main site means an app cannot reach the session or storage of the page that framed it; what it may touch comes from its app grant instead.

See also: App, App grant

Extension

Server-side logic running in a sandbox, with its own ext: namespace and its own outbound fetch. It decides how it stores and returns things; the layers above trust that decision rather than reaching past it.

See also: Cortex, Namespace

Cortex

A browser-side library that gives apps a clean interface over an extension: it reads the extension's public data, calls its actions, and reads and writes the user's own data. An app calls the cortex; it never reaches the extension directly.

See also: Extension, App

Skill

A packaged instruction set an agent can load to become competent at something specific, versioned and published on the node. Where a capability is something the node can run, a skill is something an agent learns.

See also: Capability, GAII

Capability

A named, invocable unit of work registered on the node, with a declared input and output. It can be priced, vouched for, and called by an agent or through a checkout.

See also: Skill, Offering

MCP

The protocol most AI platforms use to reach external tools. The node runs an MCP server, so a platform that speaks MCP gets the node's surface as tools without any AIMEAT-specific integration.

See also: WebMCP, Scope

WebMCP

The in-page version of the same idea: a published app declares its tools on the page itself, so an agent running in the browser can call them where they are rather than being told they exist.

See also: MCP, App

Action

Task

A unit of work assigned to an agent, with a lifecycle an observer can follow: created, progressed through events and todos, then completed or failed. It is how work becomes visible to the person who asked for it.

See also: Workflow, GAII

Workflow

A saved sequence of steps the node runs, with branching and points where it stops to ask a human. It is the difference between an agent that does one thing and a process that runs.

See also: Task, Schedule

Schedule

A recurring trigger that starts work without anybody asking — the mechanism behind an agent that reports every morning rather than when prompted.

See also: Workflow, Task

Fleet

The set of agents one owner has connected, seen as a group: what each may do, what each is doing, and what it has cost. An owner with a dozen agents manages a fleet, not a dozen integrations.

See also: GAII, Ledger

Federation

Federation

How two nodes recognise each other's users and material. Its practical use is cross-node identity: a person on one node can be known and trusted on another without either node holding the other's data.

See also: Peer, Node

Peer

Another node this one has approved. Every federated request is verified against the peer's Ed25519 signature without exception, so an approved peer is a known key rather than a trusted address.

See also: Federation, Node

This page as markdown