v0.3.0

Added

• The AgentLink logo now appears at the top of the README, and brand/ holds a downloadable brand kit: logos, social images, the colour palette and plain-language usage rules (DOCS-BRAND-KIT). The usage terms for the name and logo are proposed; the owner confirms them at merge.
• agentlink init opens the first-run page (M1-11b-6, S2, 08 §1, D-120): run in your own terminal, it opens the AgentLink setup page in your browser with a one-time link, where you protect approvals with a passkey; the settings pages keep working until you press Ctrl+C (at most 30 minutes). When your AI runs init, no page opens and no link is shown: it tells you to run init yourself, named the way AgentLink was started. Setup is offered only while no owner exists anywhere on this computer: no owner key, no passphrase-file owner, and no other agent (an agent restored from a recovery kit counts). If no browser opens, agentlink owner init works as before.
• Setup page on first start (M1-11b-8, S2, 06 §7, D-120 (1)): after you install AgentLink and (re)start your AI app, its AgentLink server opens the setup page in your browser once, while this computer has no owner yet, so you can protect approvals with one passkey. Nothing opens when an owner exists, in CI, over SSH or without a display; your AI never sees the page's one-time link, and its tools still tell you which command to run if the page didn't open.
• agentlink ui (M1-11b-9, S1, 08 §1): run in your own terminal, it opens your AgentLink activity page in your browser with a one-time link, or the setup page while no owner exists, and stops on Ctrl+C or after 30 minutes. When your AI runs it, nothing opens and no link is shown: it tells you to run it yourself, named the way AgentLink was started. It is not an AI tool.
• The local web app has its Contacts page (M1-11c-a2, S2, D-118): your contacts by name, with their label. For a new contact it shows the 12-digit safety code with a short nudge to compare it by phone, and "They match", "They don't match" and "Skip". "They match" marks the contact Safety code checked after you confirm with your passkey or owner code; "They don't match" explains what that can mean and offers to remove the contact. You can also rename or remove a contact. With no contacts yet, it suggests asking your AI to create an invite.
• The local web app has its Files page (M1-11c-a3, S2, D-118, D-119): the folders your AI can send files from, and "Allow a folder". Before you confirm, the page shows the real folder that will be allowed (a link is followed), lists every warning in plain words with its own tick, and AgentLink refuses to make the change until each one is ticked. Folders that hold keys or AgentLink's own data, hidden folders and your whole home folder can't be allowed. Every change needs your passkey or owner code. With no folders yet, it says what to do next.
• The local web app has its Proofs and credits page (M1-11c-a4, S2, D-118): your proofs with when they were made and whether they were recorded, and your credits shown as proofs left with the dollar balance beside it. With no proofs yet, it suggests what to ask your AI. Adding credits is not available yet, and the page says so.
• Add credits by QR on the Gnosis test network (M1-11c-a4c, S2, D-122, D-123): Proofs & credits → Add credits shows your agent's address with a QR code and a copy button, the network and coin, and the privacy note (11 §5.6). After funds arrive, "Turn received funds into credits" (owner code, confirm screen) makes your agent add them to its credits, keeping a little for network costs. Base test network: coming soon.
• Withdraw credits (M1-11c-a4c, S2, D-122): returns unused credits to your agent's own account after a confirm screen and your owner code. Sending them to another account comes with a later update.
• Spec (proposed, owner confirms at merge): owner actions credits.deposit and credits.withdraw in 04 §2.5 and §2.5.1.
• The local web app has its Rules page (M1-11c-a5, S2, D-118, D-119): what your agent may do without asking, in two groups, "Everyday" (adding proof and its budget, new contacts, accepting terms) and "More rules" (unknown senders, files, exports and the limits for accepting terms on its own). Changes wait in an unsaved-changes bar. Before saving, the page lists in plain words everything the change lets your agent do without asking, you tick each one, and then you approve once with your passkey or owner code. The selling warning appears only while you turn selling on.
• agentlink policy allow-send-folder † (M1-36b-2-c, S2, D-121 D6; 04 §2.5, 06 §3, §8): for an agent that was set up before owner init and owner add-agent signed a first rule, it creates the empty AgentLink/Send folder in your home folder (readable only by you; an existing folder only when it is real and empty, never a link) and, with one owner code entry, adds only that folder to your rules. Nothing else in your rules changes, and AgentLink signs nothing wider, whatever was prepared. (Proposed, owner confirms at merge: the 06 §8 wording.)
• The first part of the always-on cloud agent for 0.4.0 (M2-3a, S2, D-131; 08 §3.1, §3.2): the agent's store, keys and inbox now run inside your own Cloudflare account. It checks your relays for new messages about once a minute, only for a moment each time, and keeps them encrypted at rest; its identity comes from a secret only your account holds. It does not act on messages by itself. Not usable from Claude yet: the connection to Claude, sign-in and setup pages follow in the next steps of 0.4.0.

Changed

• Documentation-only changes merge faster (CHORE-CI-DOCS-FASTLANE, S1, ci-cd.md): a merge-queue group that holds only docs runs the checks for the affected packages instead of the full suite, and a docs-only push to a feature branch skips the heavy jobs. Any code change, an unknown diff base, or a push to main still runs everything. Pull requests that change docs-site/ now need an independent review like other public docs, except the generated status page.
• The owner confirmed nine details of the 0.4.0 cloud agent (CLOUD-SPEC-DECIDE, S2, D-131; 08 §3, 04 §2.5, §7, 06 §2.3): your recovery code is also the fallback when a passkey is lost; sending files from the cloud agent comes in a later release; template updates go out only after the owner's click; connected apps sign in again about once a month; fetched files open through a 15-minute link and are deleted after 7 days; connected apps start with the ones we have tested (Claude first, ChatGPT on the web next), others only under Advanced; the agent checks for messages every minute; pages offer "Open in Safari" or "Open in Chrome" when a passkey can't be used; and the rest of the cloud work comes in later 0.x releases.
• The always-on cloud agent is now planned as AgentLink 0.4.0, right after the usable local app in 0.3.0 (CLOUD-SPEC, S2, D-131; 08 §3, 04 §2.5, §7, §8): it runs in your own Cloudflare account and works first with Claude on the web and in the Claude iPhone and Android apps, with approvals by Face ID or fingerprint on your agent's own page. ChatGPT on the web comes later. The spec records one narrow exception to the crypto rule, for the OAuth library inside your own cloud agent only, which never handles keys or message content.
• Spec and backlog now mark four decisions as owner-confirmed on 23 Oct 2026 (DOCS-CONFIRM-1023): a refreshed file link never extends retention, the 80 % "near the limit" storage threshold, the agentlink mcp --advanced network override, and 16 downloads per drop object.
• Docs publishing (DOCS-GITBOOK-ONE-SPACE, decided by Tali, 2026-10-26): GitBook is one space, the 4thTech Docs site at wiki.4thtech.io; the AgentLink guide and technical docs are copied into it from each release tag, screenshots are dark theme only, and the GitHub wiki of this repo is a short map of links.
• One docs system for every page (DOCS-MODEL, S1, docs only): page types, plain-first pages with a marked "For the technically curious" part, screenshot rules, templates, and the Files page of the local app rewritten as the first example, with a table linking each part of the page to the code behind it.
• The README is now a plain-language landing page: what AgentLink does, how to get started, what works in 0.2.0 and what is coming (DOCS-README-LANDING). The status block now says v0.2.0 is released.
• Spec for the 0.3.0 first run (DOCS-UXV2-SPEC, D-130, 04 §2.5, 06, 08 §1, 11 §5.5 and §6): Touch ID or Windows Hello is the main way to approve, one confirmation at first run sets up approvals and allows the Send folder, the backup code is shown once with a save step, and your AI may open AgentLink's pages in your browser but never gets a link or a code and can never approve.
• The terminal approve card no longer prints the invite link; it shows a plain summary of who and what instead (M1-11a-ux-c, S1, 08 §1).
• The approval page is styled from the design (light and dark, phone width). Each request leads with a plain sentence, for example "Connect with “Ana” (self-declared)", and an accept-invite request never shows the invite link. The owner code field is full width, takes codes and passphrases of any length, can be shown and hidden, and says where the code comes from (M1-11a-ux).
• When your agent tries to send a file and no folder is allowed yet, it now tells you the exact command to run in your own terminal, policy allow-send-folder (M1-36b-2-c). Your AI can't set up the folder itself.
• policy allow-folder with a path spelled differently from the folder on disk (for example in upper or lower case) shows the exact path and asks Use <exact path>? (y/N) instead of refusing; it still allows only the real folder, and a path through a link is still refused (M1-36b-2-c).
• agentlink init asks once to set up all found apps, shows a "Skipped" line for each declined app, ends with a per-app summary, and waits for Claude Desktop to be quit before writing its...

v0.2.0

Added

• Roadmap (D-110, 10 M6): AgentLink on Solana after the EVM chains, direction only with no dates, starting with a design spike (M6-1).
• Docs site: a "Privacy of proofs" concepts page and a "What a proof makes public" section in the user guide (D-109).
• Testnet credits pool alerts (M1-10b-e, S2, 05 §9): the submitter's /v1/health reports per chain whether the gas wallet is ok or low and whether the free test credits are ok, low or paused; a scheduled check fails visibly so the owner tops the wallets up before they run dry. While the faucet cannot cover one grant it answers paused instead of failing part-way.
• A deploy pipeline for the proof relay and the testnet credits faucet (M1-10c, S2, D-28, D-88, release §4.5): every merge deploys staging, a smoke test checks health, a simulated proof on each test network that sends nothing, and that the faucet refuses a mainnet; production at submit.agentlink.4thtech.io (the testnet beta) follows automatically, with a health check, automatic rollback and the deploy freeze. Its keys are set by the owner only, outside GitHub (owner steps: docs/runbooks/submitter-deploy.md).
• First-run page in the local app (M1-11b-1, S2, 08 §1, D-120): protect your approvals with one passkey (Touch ID, Windows Hello or your phone). The page then shows your owner fingerprint, to compare with agentlink doctor, and a backup owner code, folded away, shown only once. The recovery kit can wait ("Later"); the page remembers it for a reminder. The last step tells you what to say to your AI next, with a Copy button. Every failure is explained in plain words, and a computer that is already set up is never set up again. Shared page states (expired link, AgentLink not running, setup unfinished, network, empty, loading and error) now match the design. The page is included in this release but not yet opened or connected by the CLI, so it is not usable end to end yet; it becomes usable from the next release (M1-11b-6, agentlink ui).
• An Activity page in the local app (M1-11c-a1, S2, 08 §1): what happened lately, newest first, in plain words: requests you approved or denied, requests approved by your rules, proofs, senders and contacts you blocked, and rule updates. Nothing on it changes anything. When it is empty, it suggests what to ask your AI. The page is included in this release but not yet opened by the CLI; it becomes usable from the next release (M1-11b-6).
• The core can now answer the local app's read-only pages (M1-11r-a, S2, 07 §2): your agent and owner fingerprints, the agent ID for adding credits, the resolved shared folders, your proofs list, credits per proof network, free test credits on test networks only, the message network list, and an activity feed of approvals, proofs, blocks and rule changes. Nothing secret is returned.
• Core: helpers that prepare the unsigned owner actions the local UI shows before the owner confirms: a rules edit (allowed folders and every other policy setting) as a complete, version-bumped policy.set, and the safety-code check, rename and remove of a contact. They never sign; the owner's confirmation still signs on this machine (M1-11r-b, S2).
• The core can now tell the local UI's Storage page how much of the encrypted drop's weekly allowance this agent has used, and whether your own storage is connected and working, with its last test result (M1-11r-c, S2, 07 §2). It never shares storage addresses, bucket names, credentials or file links.
• The activity list now shows messages and files you sent or received, requests from unknown senders, the contact name on each entry and what each item cost (M1-11r-d).
• The local web app has its first shell (M1-11s-a, S1, D-118): a new React app in apps/local-ui with the sidebar, header and status bar from the design system, the routes for first run and the settings pages, and a "not available yet" state on each page until the page cards land. The agentlink mcp server now holds it, but nothing opens its pages for you yet, so it stays in development.
• The local approval page's server can now host the new local web app (M1-11s-b, S2, 08 §1, D-118): its files are served from the CLI itself under a strict content security policy, its pages open with the same one-time link and session as the approval page, and every change it makes needs your owner code or passkey, checked before anything runs. The app's pages are included in this release but not opened yet.
• Owner setup on the first-run page (M1-11s-c, S2, 04 §2.2, §2.3.1, 08 §1, D-120): the local approval server can now protect your approvals from the setup page with one passkey gesture. A backup owner code is made at the same time and shown once, and your agent's first card is signed in the same step; if anything fails, nothing is saved. Once approvals are protected on this computer, setup is refused. The first-run page that uses it is in the local app (M1-11b-1), but the CLI does not enable this setup or open the page yet (M1-11b-6), so it is not usable end to end yet. Spec text is proposed, owner confirms at merge.
• The AgentLink skill file now covers files and proof (M1-12c, S1, 06 §5, 11 §5.6): sending a file with or without proof (cost first, no network choice), receiving a file safely, checking whether something was received, delivery receipts only when the user asks, exporting proof, and recording a proof of agreement for final terms. A repo test keeps it inside the in-chat vocabulary.
• End-to-end tests for files, proof and proof of agreement (M1-13c, S1, 10 M1-13, 02 J2, J3, J5, J8): a 5 MB file with no storage set up, needs_credits then the faucet route then the recorded proof, the default and per-contact receipt rules (D-109), a third party's agentlink verify on the exported pack and tampered packs failing with their reasons. A deterministic run against the repo's fakes is part of the e2e job; a live testnet run (e2e-live, manual dispatch on main) is opt-in. The proof of agreement itself is still not reachable through the tools (the terms tools refuse notarize); two it.fails tests state it.
• The invite page checks that the inviter's name matches the invite and shows a damaged invite, with no install prompt, when it does not (M1-19-b, S2, 04 §3.6).
• A CI deploy pipeline for the invite page: staging only, on every merge, with a smoke test that compares the served files and headers with the build. The production deploy waits for the trademark check and the domain decision (M1-19-d) (M1-19-b, 08 §4, D-25, D-52).
• The invite host's static how-to-install page is built (M1-19, S1, 04 §3.6, 06 §7.1, 08 §4): it reads the invite from the link in the browser only, checks its size, version, format and expiry, shows who invited you (name under the contact-name rule, labelled Self-declared) and one prompt to copy into your own AI that installs AgentLink and accepts the invite. The prompt holds only the official text and the canonical link. No analytics, no referrer, and the strict content policy of 08 §4. Not deployed yet: the deploy pipeline follows in its own card.
• With files.deleteAfter: receipt, your agent now deletes a sent file from storage (your own or the encrypted drop) once the contact's delivery receipt is on record. A drop file uploaded before a key change is still deleted with the key it was uploaded under. Without a delivery receipt nothing is deleted and the file stays until it expires (M1-1g-h, S2, 04 §4, 06 §3, 07 §5.4). Every key store backend now runs one shared set of key-epoch and drop-request tests.
• Test vectors: the eip712-revocation suite refuses a Revocation under any domain other than the OCC v2 chain domain, including the AgentCard domain, and a keyEpoch spelled -0; 04 §2.4.1 names the Revocation keyEpoch and deadline as JSON integers (M1-1j-b, S2).
• New user-guide page "Negotiating terms", glossary entries for offers, and an FAQ answer on negotiating; the guide's FAQ and glossary no longer say nothing can be installed (M1-25, S1).
• The top-up link in the tools and the CLI (M1-26-e, S1, D-111, D-113), off until the pay page is deployed: the pay host and a live flag come from the shipped chain config (PAY_PAGE, not live yet). When live, needs_credits and agentlink_status give https://{payHost}/#v=1&a=<agent ID>&usd=<suggested amount> (address and amount only in the fragment), and agentlink credits --topup prints it with a terminal QR code and opens the browser for a person at a terminal. Today no link is given and needs_credits says adding credits is not available yet. The server instructions describe agent-assisted funding.
• agentlink init --hook adds an optional start-of-session note to Claude Code: a line or two with unread counts, requests and contact names from agentlink status --brief, never message text. It is off until you ask for it, shows the exact change to ~/.claude/settings.json first, writes it only after you confirm, and runs the installed program by its full path, never npx. Codex, Gemini CLI, OpenCode and Antigravity are documented as not available (M1-29, S1, 06 §7, D-53).
• When you add proof you can ask the contact to confirm delivery; when a contact asks you, your agent tells you and confirms only if you choose "Confirm delivery". Asking never confirms anything by itself, and each confirmation says what it makes public (M1-33d, S2, D-109, 06 §2.4).
• The shared UI package now carries the design tokens: typed values and a CSS file for the light, dark and increased-contrast themes, the Geist fonts served from the package itself (no external fonts or CDNs), and the font and icon licence notices (M1-35a, S1, 11 §11.7).
• The shared UI package now has the review-together view for approvals: one agent's waiting approvals as full cards, each with Approve, Deny or Later and nothing preselected, and one button that names exactly what it applies, such as "Approve 3 and deny 1" (M1-35b-b, S1, brief B-2).
• The shared UI package now has t...

v0.1.2

Added

• The submitter, in development and not deployed (M1-10a, S2, 07 §7, 05 §3.3): a 4thTech service that records agents' signed proofs and receipts for them, so an agent needs no funds of its own on the network to get a proof. It only ever receives items the agent already signed, cannot change them, and is checked before anything is sent: the signature, the deadline, the prepaid credits and whether the item is already recorded. An agent's client can use several submitters and moves on when one fails.
• Free test credits, in development and not deployed (M1-10b, S2, 05 §9, 03 §4.4): the submitter can top up a test agent's credits on the test network, so testers never need funds of their own. It serves test networks only, from a fixed list that refuses every main network.
• When your AI needs your approval, AgentLink now opens the approval page in your browser and the AI shows you its link (M1-11a-b, S2, 08 §1, 06 §2.5): approve or deny there with your owner code or passkey, or run agentlink approve <id> in your own terminal as before. The link the AI sees opens nothing by itself, and your AI can't approve for you.
• Automatic choice of where a proof is paid, in development and not user-facing yet (M1-26, S1, 07 §6.3, D-40): the client checks the agent's credits on every supported network at once, uses the default network when it has enough credits, otherwise the cheapest one that does, and otherwise says credits are needed, how much is missing and where adding them costs least. A network that does not answer in time is skipped, never chosen. Only test networks are ever used in this release.
• The contract interface package @4thtech-io/occ-v2-abi (M1-3f, S1, D-83, 05 §9): the OCC v2 ABIs and the Base Sepolia testnet addresses from contracts release v0.1.0-testnet.2, imported with tools/occ-v2-abi/import.mjs and checked in CI against the release's SHA-256 manifest (the addresses in a scanner-safe generated form whose rebuilt file bytes match the manifest; @4thtech-io/chain loads them with EIP-55 checksums). It is private and bundled into the CLI. Client code gets Notary and vault ABIs without admin, upgrade or module functions, and EIP-3009 deposits stay off until the contracts enable them (M1-3c). Testnet only: no mainnet addresses exist.
• CI fails if any Solidity source (a .sol file or a pragma solidity line) appears in this repository (M1-3f, D-19).
• The chain client foundation, in development and not user-facing yet (M1-4a, S2, 07 §6.1, §6.2): the client knows Base Sepolia from the shipped entry and the pinned contracts release, picks the chain on its own, reads through several public endpoints with timeouts, retries and failover, and builds proof records and receipts that match the shared test vectors exactly. Every record gets a fresh random salt and nonce the caller cannot choose, and signing goes only through the agent's key store.
• Fee quotes, credits and top-ups in the chain client, in development and not user-facing yet (M1-4b, S2, 07 §6.2, 12 §4, §5): the client quotes a proof or a registration from the fee vault itself and shows it in USD with the AgentLink fee and any app fee separate, reads the agent's prepaid credits on every supported chain, and prepares a direct top-up (an approval of exactly the amount, then the deposit). Only the stablecoin fee tokens are ever priced, shown or deposited.
• Proofs are sent through a list of submitters with failover, or directly from the agent's own account when no submitter gets them on-chain (M1-4c, S2, 07 §6.2, §7; 04 §5, §7). Every result is read from the chain, never taken from a submitter's answer: a wrong transaction hash, a silent drop, a modified record or a false failure is noticed and the same signed item goes to the next route. A replacement is allowed only when the earlier item can never land (04 §5). Deposits read the current allowance first and reset it to 0 for tokens that need it; after a deposit or a refusal for missing credits the chain is selected again from fresh reads.
  The default submitter at submit.agentlink.4thtech.io is not deployed yet, so proofs need it before they work out of the box.
• Your agent now tells its contacts about its new keys after a key change (M1-4d-f, S2, 04 §3.4.1): it sends its new card, with both of its own signatures, to every contact on the next sync. It sends it only to contacts your contact list allows, and none while your rules can't be read (D-106). It also keeps its earlier cards, so a proof made for a message sent before the key change can still name the sender.
• Proof-pack verification in the chain client, in development and not user-facing yet (M1-4d, S2, 07 §6.2, §8, 05 §3.3, G-46, D-86): a proof file is checked against the record on the proof network by one record read, the signer's signature (including smart accounts), the disclosed recipient and the recorded receipts, and, when a content key is shared, the message in the fixed 07 §8 order. Every failure has a fixed reason and plain text, and nothing from the proof file or the network address is echoed.
• Files that are too large to travel inside a message can go through the 4thTech encrypted drop with no setup (M1-6c, S2, 07 §5.4, §5.6, D-48): the drop receives only encrypted bytes, their size and fingerprint, never the file, its name or its key; links expire within 7 days and are never written to logs. Small files still travel inside the message first, and when several do not fit together the largest move to storage (G-27). Your own storage, when set up, is used instead and never silently swapped for the drop; a busy drop asks you to try again later instead of asking you to set up storage. Using this for sending files comes with the file tools.
• Your agent's core can now send files to a contact and fetch received files (M1-7f, S2, 04 §3.4, §4, 06 §2.3, D-84, D-85): small files travel inside the message and larger ones go through the encrypted drop or your own storage, encrypted with a fresh key per file. A message whose files cannot fit is refused before anything is read or uploaded. Received files are checked in a hidden temporary file and get their (cleaned, never overwriting) name only once both fingerprints match, so a tampered or cut-off download leaves nothing behind. Download links are kept encrypted on disk and never logged. Using this from the CLI and MCP tools comes with the file tools.
• The recipient of a recorded message can now export its own proof pack too (M1-7g-b, S2, D-107, 07 §8): the sender's proof message carries the signed record, which the recipient checks against the proof network and its copy of the message before keeping it. A check that cannot reach the proof network waits and retries for up to 7 days instead of being refused. A proof from an older sender is still accepted, but its recipient cannot export a pack.
• Proofs and receipts in the core (M1-7g, S2, 07 §2, §8; 04 §5): recording a sent message on-chain with automatic chain selection, the budget and approvals; the recipient checks every record on-chain before it signs a receipt (DELIVERED automatically, OPENED on request, ACCEPTED or REJECTED only with an approval); a fresh salt for every record; and proof-pack export, with the content key only after the owner approves and the recipient only on request. Signed receipts are kept and resent unchanged until they land. The CLI and MCP proof tools use it (M1-9d-2).
• Your agent can send a file and save a received one (M1-9d-1, S2, 06 §2.2, §2.3, 04 §4, D-84): ask it to send a file by its path and it attaches it, but only from a folder you allow in your AgentLink rules; hidden files, private folders and anything outside your allowed folders are refused without being read. Small files travel inside the message, larger ones through the encrypted drop. A new tool saves a received file into your inbox folder only after it arrived complete and unchanged, never replacing a file and never opening it. Your agent never sees download links or file keys. Before most people can use this, two pieces still have to land: a way to allow a folder (agentlink policy) and the running encrypted drop for files above about 12 KB.
• Your agent can add proof to messages and check proofs (M1-9d-2, S2, 06 §2.1, §2.2, §2.4, D-87, D-101): ask it to send a message with proof, or to add proof to one it already sent; it costs a small fee from credits, and your rules decide when it asks you first. It can show a proof and its receipts, add an "opened" receipt when you asked it to open a message (and "accepted" or "rejected" only with your approval), save a proof file into your proofs folder (with the message content only after you approve), and check a proof file from your proofs or inbox folder, never any other folder. Status now shows your credits, the price with the AgentLink part and any app part shown separately, your agent ID and a link to add credits. This runs on test networks and is usable once the 4thTech proof service and free test credits are running; recording offers and acceptances comes later.
• Check a proof file yourself, and see your credits, in a terminal (M1-9h, S1, 06 §8, 07 §8, D-87): agentlink verify <proof file> checks a proof file from your proofs or inbox folder and says first whether it checks out ("Verified", or "Record only" when the proof doesn't show who wrote the content, or why it doesn't check out); a proof on a test network is labelled as one. agentlink credits shows your agent ID, your credits in dollars and the price of adding proof, and --topup says how much to add and where. agentlink doctor now also checks that the public record answers.
• agentlink policy recover (M1-9m-b, S2, D-100, 06 §8): when your rules can't be used (for example an older copy was put back), this command, in a terminal you opened yourself, says what went wrong, shows you the full rules it would sign (your last rules if they are still signed by you, otherwise the starting rules), and signs them only aft...

v0.1.1

Added

• Spec (D-82, owner decision): 04 §2.3 now defines the owner seed blobs. ALKP v1 is the passkey PRF wrap (owner key and credential ID in the header, random nonce, whole header as AAD, size and owner checks); ALKR v1 is the recovery-code wrap (the ALKO layout with its own magic and label, generated codes only, Argon2id 64 MiB / 3 / 1). M1-1k is unblocked: vectors first, then code.
• Security utilities for files (M1-15, S1, 04 §4, §7; not wired into any tool yet, M1-7f and M1-9d use them): @agentlink/core gets the pure checks (checkFetchUrl on the raw URL string: https only, no numeric host notation in any base, no local or internal names, no user info; pickPublicAddress: every resolved address must be globally routable; decidePath for both POSIX and Windows paths; sanitizeFileName). @agentlink/node gets nodeSafeFetch (one lookup per hop, connect to the checked address, at most 2 redirects each re-checked, byte cap, one deadline, no proxy; errors never carry the URL), resolveAllowedFile / openAllowedFile (realpath on both sides; hidden files, ~/.ssh, ~/.agentlink and keychain folders always refused, also through links) and createInboxFile (sanitised name, exclusive create, never through a link). In Workers (G-14, proposed) the raw URL check applies and the address check relies on Workers egress; that path lands with M2-3b.
• Crypto (M1-1j, S2): EIP-712 typed data and hashing for the OCC v2 proof types Record, Receipt and Registration under the chain domain {name: "OCC", version: "2", chainId, verifyingContract}, with strict 05 §3.1 JSON-form parsing (refused, never normalised); recordStructHash; the recipient commitment keccak256(abi.encode(recipientAgentEvm, salt)); and EIP-3009 ReceiveWithAuthorization typed data under a token domain the caller reads from chain. The eip712-proof vector suite is no longer pending. The revoke struct waits for G-20 (M1-1i-b).
• Storage (M1-6a, S2): @agentlink/storage has the StorageAdapter interface (07 §5.1), the inline adapter (ciphertext up to 12 288 bytes, base64url in the payload) and the S3-compatible adapter over aws4fetch: upload, a presigned download link clamped to 7 days and to the expiry of temporary credentials, and delete. Objects are keyed agentlink/<storagePrefix>/<random> with no metadata; credentials come from an injected provider; no credential, link or object key is logged. Not yet wired into the tools; integration tests against MinIO and R2 follow in M1-6a-2.
• Local approval server (M1-8d, S2, @agentlink/node; not wired into the CLI yet, M1-11a): an HTTP server on 127.0.0.1 and a random port with a view-only session token kept in memory (exchanged for an HttpOnly cookie, never written to disk or logged), exact Host and Origin checks against DNS rebinding, a CSRF token and non-simple requests for decisions, and owner presence (owner code or owner passphrase) for every approve or deny, signed as one approval.decide that core verifies. Each approval ID is decided once through it; a fixed OS notification and the /approve/<id> route are included. The same-user script test runs against the live server.
• Live relay subscriptions (M1-9s): while agentlink mcp runs and holds the publisher lease, new messages and handshakes are stored and processed as they reach a relay instead of on the next 30 s poll. The core Transport gains subscribe and the client subscribeInbox (same receive path as syncInbox: dedup by gift-wrap ID and envelopeHash, one store transaction, rate limit). The background loop keeps a catch-up every 5 min as a fallback, polls when no subscription can open, and closes the subscription on lease loss and on shutdown.
• Spec text sync (M1-9s): the 07 §4.1 interface sketch now shows subscribe with the implemented sync handler shape (relays, identities, persistence, onEnvelope) and an unsubscribe that resolves once in-flight handlers settle; no protocol change.
• Dogfood tooling (M1-23-b): tools/dogfood/run.mjs --role a|b runs the pairing, messages, owner approvals and the J8 negotiation across two Macs, one agent per Mac, with the invite link and run ID exchanged by hand; --same-owner for one person at both Macs. Single-machine mode is unchanged. Runbook RB-17 section 10 has the commands.
• Test vectors (M1-1i, S2): two new suites, pending until their code lands. eip712-proof (M1-1j) covers EIP-712 hashing of Record, Receipt and Registration under the OCC v2 chain domain, the recipient commitment, and the Record/Receipt JSON-form rejections. prf-wrap (M1-1k) covers the passkey PRF salt and wrap key (04 §2.3). STREAM and revoke vectors wait for G-26 and G-20 (new card M1-1i-b).
• CLI (M1-9w, S1): agentlink init --harness claude-desktop sets up the Claude desktop app (macOS and Windows; its own claude_desktop_config.json, not Claude Code's file), with the usual diff, confirmation, backup and refusal of malformed files. On Linux it says the app isn't available there.
• Docs (DOCS-SETUP, S1): a beginner page, "Set up AgentLink in your AI tool", with the Node check, one install line per tool, the owner step, a first test, pairing two of your own tools and the top troubleshooting fixes. Claude Desktop is marked as merged but not in v0.1.0.
• Owner approvals (M1-11a, S2, 08 §1, 11 §6.2.1, 04 §2.5.2, D-68): the local approval page on http://localhost:<port> lists your waiting approvals as cards (who, what, cost, expiry, the rule that asked, and what your AI chose), soonest to expire first. Mark each Approve, Deny or Later, then confirm exactly that list with one passkey gesture or one entry of your owner code; terms are listed but always approved on their own card. Before asking, the page checks the list again and tells you what it left out. Text from your AI or a contact is shown as plain text only. The first-run screen explains what approvals need and offers the passkey, or says when this browser has none and the owner code is the way. Each link the agent opens works once (a link in your browser history no longer opens the page), and after 3 wrong owner codes or passkeys in a row the page makes you wait before the next try (5 seconds, doubling up to 5 minutes); agentlink approve in your own terminal is not affected by that wait. "Remember for this contact" and opening the page from the CLI come later.
• File encryption (M1-1d, S2, 04 §4, D-80): the crypto package encrypts and decrypts files in 1 MiB chunks as a stream, so a large file never has to be in memory whole, and refuses a file whose header was changed or whose chunks were dropped, reordered, repeated or added. The stream test vectors now run in every runtime.
• Test vectors (M1-1i-b, S2): two new suites, pending until their code lands. stream (M1-1d) covers ALF1 file encryption with the D-80 chunk AAD header ‖ isFinal (04 §4): empty, 1-byte, one-chunk, chunk + 1, multi-chunk, exact-multiple and inline-cap files, and rejection of tampered headers, reordered, dropped, truncated or appended chunks, a flipped final flag and a wrong nonce. eip712-revocation (M1-1j) covers EIP-712 hashing of the D-81 Revocation struct (05 §4), a Registration and a Revocation sharing one owner nonce, and the Revocation JSON-form rejections.
• Revocation signing data (M1-1j, S2, 05 §4, D-81): the crypto package builds and hashes the EIP-712 Revocation an owner signs to revoke an agent, under the OCC v2 chain domain with the Registry as verifying contract, and refuses every non-canonical form. The eip712-revocation test vectors now run in every runtime.
• Crypto (M1-1k, S2): @agentlink/crypto seals and opens the owner seed as ALKP v1 under a passkey PRF output and as ALKR v1 under a generated recovery code (24 base32 characters in six groups of four), with header, size and owner checks, one generic error and no partial output on failure. The prf-wrap vector suite (80 cases, including cross-type cases with ALKO and ALKS) is no longer pending.
• Hands-free two-Mac dogfood: node tools/dogfood/run.mjs --two-mac --remote <ssh-host> runs both Macs from Mac A over ssh, syncs the steps by itself and ends with one combined table. The invite link goes over ssh stdin only; owner approvals are still typed by you in the same terminal (M1-23-d, S1).
• Auto-sync two-Mac dogfood for macOS: run.mjs --role b --auto-sync on Mac B, then --role a --auto-sync --remote <host> on Mac A. Each agent runs in its own Mac terminal (ssh only moves small files), so the keychain works; approvals are typed locally on each Mac. --two-mac now detects the macOS keychain-over-ssh failure and points to it (M1-23-e, S1).
• Encrypted drop (M1-27a, S2, D-48): the drop Worker in apps/drop, tested locally under Miniflare and not deployed (deployment is M1-27b; the R2 buckets and lifecycle rule are the owner's M1-28). Signed uploads with no accounts, single-use upload targets that take exactly the declared size (multipart above 64 MiB), a commit that hashes the stored bytes and deletes them on a mismatch, signed downloads until expiry with a download limit of 16, DELETE by the uploading drop key only, an abuse report that deletes only that object, per-key quotas, per-IP (IPv6 per /64) and global limits, and no logs: aggregate counters only. @agentlink/crypto gains the drop request signature (verification and the unsigned event), the drop URL MAC and an incremental SHA-256, with the drop-auth vectors in all runtimes. Spec (07 §5.4, 04 §4, 08 §7; proposed, owner confirms at merge): the signature format, the signed URLs, the limits with the shared-egress and global-cap rules, the download limit, and the CORS policy for browser downloads.
• Encrypted drop deploy pipeline (M1-27b, S2, D-48): apps/drop/wrangler.toml (staging on workers.dev, production on drop.agentlink.4thtech.io; bucket and Durable Object bindings, a raised CPU limit, and observability, Logpush and Tail Workers off) and `.github/workflow...

AgentLink v0.1.0

AgentLink v0.1.0 (M1a, walking skeleton): release note

Draft: ready to release, not released. This becomes the GitHub Release text once the owner publishes (RB-18); the CHANGELOG.md ## [0.1.0] section is the canonical source. Claims here match merged code only.

Pre-alpha, testnets only. Two AI agents on different apps can pair, talk and negotiate terms, end to end encrypted, with every binding step approved by their owner.

Install

npx -y @4thtech-io/agentlink init

Or ask your agent: "Install AgentLink for me. Run npx -y @4thtech-io/agentlink init, show me the exact configuration change, and apply it only after I confirm." Check that the package name is exactly @4thtech-io/agentlink. Guides for Claude Code, Codex and Gemini CLI are in docs-site/guide/get-started/; init --harness also sets up OpenCode and Antigravity.

What is in it

• One package, @4thtech-io/agentlink: the agentlink command line and an MCP server over stdio, with the AgentLink libraries bundled in. Keys live in your OS keychain. Published from CI with npm provenance.
• Setup: init (detects Claude Code, Codex, Gemini CLI, OpenCode and Antigravity; shows the exact change before writing it), doctor, status.
• Pairing: invite links and accept, a short safety code checked on both sides, contacts, requests from unknown senders (accept, ignore, block).
• Talk: messages between paired agents over public Nostr relays (a default set of four); an inbox with unread counts; offline catch-up; a background loop that keeps messages flowing without a tool call.
• Terms: propose, counter, reject and accept terms over Talk, with one owner approval per agreement and owner-signed auto-accept limits.
• Owner control: owner init, approve (one or a list), deny and cancel in your own terminal with your owner code; the agent cannot approve for you. One owner can have several local agents (owner add-agent).
• Safety defaults: inbound content is wrapped as untrusted, agents see a fixed small tool list (guard-tested), and nothing secret leaves your computer.
• For agents: a skill file and AGENTS.md snippet, and quickstart pages with permission settings that guard ~/.agentlink.

Not in it yet

Files (encrypted handover), proof packs and notarization (testnet contracts exist, but AgentLink does not use them yet), credits, the local approval page (M1b), the owner console, desktop apps and cloud agent (M2), mainnet (M3). Relay messages are polled every 30 s; live subscriptions come later.

Known limits

• Pre-alpha, testnets only. Formats may break between 0.x minors.
• Same-user residual (G-1, D-67): agents under the same OS user as the owner are kept apart logically, not by a security boundary. Approvals need your owner code in your own terminal; the guidance pages say how to guard the private folder.
• Harnesses: the automated end-to-end run passes in full with Claude Code on both sides. Codex as the second agent passes only partly, so it is not a gate. OpenCode and Antigravity are covered by the dogfood tooling and runbook, not by CI.
• The LLM end-to-end test is a manual-dispatch job, not scheduled; the deterministic end-to-end test runs on every pull request.
• Public relays: the default set is not yet signed off (an opt-in vetting script exists).
• The two-person dogfood (Tali and Denis) has not yet run against the published package.

Security

Specs and decisions are in docs/foundation/. There has been no external security audit yet (before mainnet, M3).

v0.0.1 — M0 Foundations

M0 Foundations: specifications (spec pack v0.3), development and audit process, CI/security workflows, versioning framework, agent instructions; no product code yet.

Added

• Specification pack under docs/foundation/: product, architecture, security and cryptography (invariants I-1 to I-10), OCC v2 contracts, MCP server, SDK/transport/storage, clients, build plan and design brief, with a decision log (D-01 to D-44).
• Development process (orchestrated AI agents, task lifecycle, definition of done), audit rules (security classes S0 to S2, independent reviews) and a sync protocol for collaborators, under docs/process/.
• Release and deployment process: continuous delivery to staging and testnet, one owner approval click for production, rollback matrix and DEPLOY_FREEZE.
• GitHub Actions workflows for CI, security checks, secret scanning, pull-request hygiene, the review gate and the release pipeline (npm trusted publishing with provenance), all pinned to commit SHAs and dormant until the monorepo skeleton exists.
• Versioning framework (D-43): SemVer 2.0, one product version during beta, milestone-to-version map, npm next and latest channels, wire-format compatibility table and this changelog.
• Agent instructions (AGENTS.md and the per-tool files that point to it) and the backlog of task cards.
• Public repository files: README with status, LICENSE, SECURITY.md, Renovate configuration and the documentation map (D-44).

Security

• Audit of the CI and release workflows: actions pinned to full commit SHAs, least-privilege token permissions per job, no untrusted event data in scripts, no long-lived npm token, and publishing only from main through GitHub Environments with provenance.