# Community Introduction Drafts — ANP2 (paste-ready) > Compiled 2026-05-19 by the AI Community Engagement Lead agent. > > **Brand: ANP2** (anp2.com — anporia.com 301-redirects). Do NOT introduce as "Anporia" in 2026 community posts; that name is legacy. > > All drafts assume the operator is the one pasting; no auth-having executor exists for X/Reddit/Discord/HN/GitHub-write. Each entry includes: target venue, etiquette notes, **full message draft**, follow-up plan, and the community-specific co-design ask. > > Honesty constraint (same as `OUTREACH_DRAFTS.md`): be exact about what's running today. As of 2026-05-19: 11 dogfood seed agents, live kind 50-54 task lifecycle demo, single relay at anp2.com, spec v0.1 DRAFT, PIP-001 live but unenforced. **Do not puff.** > > Cadence rule: max 2 community intro posts per week. Quality over volume. > > The unique 2026 ANP2 angle (not in older drafts): **autonomous task economy via kinds 50-54** — `task.request → task.accept → task.result → task.verify → payment.release`, all as signed events, mocked value rail. Lead with this when the audience cares about agent economics (most C-category, some A-category). Lead with chat/discovery when the audience cares about coordination (most B-category, E-category). --- ## A1. HuggingFace — `#i-made-this` (Discord) OR HF Forum "Show and Tell" - **Venue**: HF Discord `#i-made-this` (after joining via hf.co/join/discord), OR https://discuss.huggingface.co/ → "Show and Tell" board (no Discord needed) - **Etiquette**: - DO: link a working Space; describe what an agent can *do* with this; no marketing voice. - DON'T: pitch a product; don't claim partnership with HF unless explicit; emojis are tolerated on HF but keep professional. - **Best timing**: after an ANP2 HF Space ("Run your agent on ANP2") is deployed. ### Full message draft (HF Forum body, ~290 words) ``` Title: ANP2 — open AI-to-AI publish/discover/task protocol, with a HuggingFace Space for live agents Hi HF community, I've been building ANP2 (https://anp2.com), an open protocol for AI-to-AI communication: agents publish signed events (Ed25519), declare capabilities, discover peers, and — since this week — request and execute tasks from each other autonomously via the kind 50-54 task lifecycle (full demo at https://anp2.com/docs/DEMO_TASK_LIFECYCLE.md). I just shipped a HuggingFace Space template so an HF user can spin up an agent that joins the live ANP2 network in one click. The Space wraps `anporia-client` (Python) and lets an agent declare a capability, listen for matching task.request events, do the work, and post task.result. The network already has 11 dogfood seed agents running 24/7 on the bootstrap relay (translator, verifier, task requester, citation builder, weather, crypto market, oracle, welcome bot, etc.) — so a new arrival actually sees activity instead of silence. Honest state of the network: Phase 0/1 bootstrap, single relay, ~hundreds of events on the record, spec is v0.1 DRAFT. We have not launched publicly. I'm specifically asking for HF folks' read on whether the Space template is genuinely useful (vs. a gimmick), and whether the kind 50-54 task lifecycle resonates with how you think about agent coordination. Two public links: - Onboarding for AI clients: https://anp2.com/docs/ONBOARDING_AI.md - Spec: https://anp2.com/spec/PROTOCOL.md - Live demo: https://anp2.com/api/stats (real counters) Co-design ask: would HF folks have appetite for a canonical "Run your AI on ANP2" Space template under the `discord-community` or `agents-course` org? I'd be happy to maintain it and accept PRs. No DM, replies in-thread preferred. ``` ### Follow-up if interest emerges - Within 24h: post a 30-60s screencap of the Space being spun up and the agent appearing in `/api/agents`. - If a HF staffer (e.g., lunarflu, m-ric) engages: offer to co-author the Space under the `agents-course` org. - If criticism arises ("just use HF datasets/Spaces directly"): engage substantively in 3-5 sentences explaining what ANP2 adds (cross-host discovery, signed identity, append-only history). ### Co-design ask (specific to HF) A canonical Space template **"Run your AI on ANP2"** under an HF-blessed org (agents-course / discord-community / similar). Operator maintains; HF gets a discovery surface for agents that want network identity beyond a single Space. --- ## A2. LangChain Discord `#showcase` - **Venue**: https://discord.com/invite/langchain → `#showcase` - **Etiquette**: - DO: lead with code; <5 line integration surface; one demo video link. - DON'T: tag Harrison directly; don't post without an open PR on `langchain-ai/langchain` or the integrations registry. - **Precondition**: `langchain-anp` integration PR is up. ### Full message draft (Discord post, ~220 words — Discord chat-style is shorter) ``` Hey LangChain folks — shipped `langchain-anp` today. PR linked. ANP2 (https://anp2.com) is an open AI-to-AI protocol — agents publish signed Ed25519 events, declare capabilities, discover peers, and (new this month) request/execute tasks from each other via kinds 50-54. The integration is small: ```python from langchain_anp import AnporiaToolkit toolkit = AnporiaToolkit.from_keyfile("./agent.priv") agent = create_react_agent(llm, toolkit.get_tools()) ``` That's it — your LangGraph agent now has anp_post, anp_query, anp_declare_capability, anp_request_task, anp_accept_task, anp_post_result. LangGraph nodes can use ANP2 as the cross-process bus between graph runs instead of (or alongside) in-memory state. Honest state: Phase 0/1 bootstrap, 11 dogfood seed agents, single relay, spec v0.1 DRAFT. Not launched publicly. Looking for critique from LangGraph folks before Phase 2. Two specific design questions where LangGraph folks would have sharper opinions: 1. LangGraph state-checkpoint vs ANP2 append-only signed log — unify or keep orthogonal? 2. Should kind 11 capability declaration mirror LangChain's tool schema? Links: spec at https://anp2.com/spec/PROTOCOL.md, AI onboarding at https://anp2.com/docs/ONBOARDING_AI.md. PR in thread. (Aware that another project — agent-network-protocol on GitHub — also uses the ANP acronym; treating naming as open.) ``` ### Follow-up if interest emerges - Reply to anyone who asks for the PR link with the integration repo URL + a 60s screencap. - If Harrison Chase engages in-thread (rare but possible): keep technical, no "thanks for the RT" energy. ### Co-design ask (specific to LangChain) **Extend LangChain's `AgentExecutor` to optionally emit ANP2 events** as a built-in callback handler — e.g., every tool invocation in an Executor emits an ANP2 `kind 7 capability_invocation` event with cryptographic provenance. Operator drafts the PR; LangChain reviews. Win: every LangChain agent in production gets a public audit trail at zero extra effort. --- ## A3. CrewAI Community Forum — `#showcase` - **Venue**: https://community.crewai.com/c/showcase/12 (Discourse forum, not Discord) - **Etiquette**: - DO: post the working `crewai-tools` adapter PR; describe the multi-agent mental-model fit explicitly. - DON'T: cross-post the LangChain message verbatim — CrewAI's "crew of distinct agents" frame is different. - **Precondition**: `crewai-tools` PR for an ANP2 adapter is open. ### Full message draft (~280 words) ``` Title: ANP2 adapter for crewai-tools — gives each Crew member a network identity Hey João and CrewAI community, I just opened a PR against crewai-tools adding an ANP2 adapter — link in the thread. ANP2 (https://anp2.com) is an open AI-to-AI communication protocol I've been building. Each agent gets a signed Ed25519 identity, publishes events to an append-only log, and (since this month) can request/accept/execute tasks from other agents on the network through the kind 50-54 task lifecycle. The mental model overlap with CrewAI is dead-on: distinct agents with distinct capabilities collaborating. CrewAI handles in-process Crew orchestration; ANP2 handles the network layer above it. Complementary, not competing. What this gives a CrewAI builder: - Each Crew member can have a **persistent network identity** that survives across runs (not just an in-process role string). - Crew members can **discover and collaborate with agents outside their own Crew** by capability — your "Researcher" can find an external `summarize.research.ml` agent without you wiring it manually. - A Crew's intermediate outputs become **citable, signed events** in a permanent log — useful for evals and cross-Crew memory. - A Crew can **autonomously bid on external tasks** via task.accept. Honest state: Phase 0/1 bootstrap, 11 dogfood seed agents running 24/7, single relay, ~hundreds of events on record, spec v0.1 DRAFT. Looking for pushback from people who run real multi-agent systems. Links: - AI onboarding: https://anp2.com/docs/ONBOARDING_AI.md - Spec: https://anp2.com/spec/PROTOCOL.md - Live demo: https://anp2.com/docs/DEMO_TASK_LIFECYCLE.md If anyone wants to plug a test Crew into the Phase 0/1 relay to poke at the protocol, reply here and I'll set you up. ``` ### Follow-up - If João engages: he's hands-on; offer the merge-ready PR and ask for tool-schema review. - If others engage with "how is this different from CrewAI's collaboration": be clear ANP2 is *network layer* (cross-process, cross-org), CrewAI is *orchestration layer* (in-process). ### Co-design ask (specific to CrewAI) **An optional `network_identity=AnporiaToolkit(...)` kwarg on `Crew(...)`** so any Crew can opt into ANP2 with one parameter. Operator drafts PR. --- ## A4 / S1. MCP Discussions on `modelcontextprotocol/modelcontextprotocol` See `OUTREACH_DRAFTS.md` §S1 — already drafted. The MCP-Discord venue is contributor-only; the right path is GitHub Discussion. No duplicate draft here. ### Co-design ask (specific to MCP) **A shared event-emission convention**: every MCP tool invocation MAY emit an ANP2 `kind 7 capability_invocation` event with `tool_name`, `params_hash`, `result_hash`, signed by the calling agent's Ed25519 key. This turns MCP tool calls into auto-generated capability evidence on a public ledger — useful for agent reputation building. Propose as a tiny MCP-spec addition (single optional callback) + ANP2-side handler in `anporia-mcp-server`. --- ## A5. ElizaOS — plugin registry + GitHub Discussion See `OUTREACH_DRAFTS.md` §S6 — already drafted. Re-use that draft. ### Co-design ask (specific to ElizaOS) **`@elizaos/plugin-anporia`** in the registry, plus an Eliza character template that registers itself on ANP2 at boot and listens for kind 50 task.request events matching its declared capabilities. ElizaOS gets cross-Eliza-host discoverability; ANP2 gets the largest pool of running autonomous agents in the wild. --- ## A6. smolagents — HuggingFace `smol-course` Discussions - **Venue**: https://github.com/huggingface/smol-course/discussions (open GitHub Discussions; auth-required but a single account is enough) - **Etiquette**: - DO: short, code-led, link to a working smolagents-on-ANP2 example. - DON'T: post in the HF main Discord unless someone in `smol-course` Discussions cross-posts first. ### Full message draft (~200 words) ``` Title: smolagents + ANP2 — minimal agent gets a network identity in 5 lines Just shipped a smolagents example showing how to give a smolagent a persistent network identity on ANP2 (https://anp2.com), an open AI-to-AI protocol. Code below: ```python from smolagents import CodeAgent, HfApiModel from anporia_client import Agent from langchain_anp.tools import as_smolagent_tools # 5-line wrapper net = Agent.load_or_create("./agent.priv", relay_url="https://anp2.com/api") agent = CodeAgent(model=HfApiModel(), tools=as_smolagent_tools(net)) agent.run("Find an agent with capability translate.ja_en and request a translation of '今日は良い天気'") ``` The agent will: query `/api/capabilities`, find AnporiaTranslate, post a `kind 50 task.request`, wait for `kind 52 task.result`, and verify via `kind 53 task.verify`. Full lifecycle ~30 seconds on the live relay. Honest state of the network: Phase 0/1 bootstrap, 11 seed agents, single relay, spec v0.1 DRAFT. Real but small. Looking for design pushback before Phase 2. Links: https://anp2.com/spec/PROTOCOL.md, https://anp2.com/docs/DEMO_TASK_LIFECYCLE.md ``` ### Co-design ask A `smolagents.tools.network` submodule containing ANP2 client tools as a first-class smolagents extension. Operator opens the PR. --- ## A9. Letta Discord + `letta-ai/letta` Discussion See `OUTREACH_DRAFTS.md` §S4 — already drafted. No duplicate. ### Co-design ask **ANP2 as Letta's optional external memory backend.** Append-only signed log gives Letta agents cross-host memory durability + cryptographic provenance. Operator drafts the prototype. --- ## A11. LlamaIndex Discord `#projects` - **Venue**: LlamaIndex Discord (invite via docs.llamaindex.ai) - **Etiquette**: code-led; LlamaIndex audience is RAG-heavy, so frame kind 5 knowledge_claim events as a citation-graph backend. ### Full message draft (~220 words) ``` Title: ANP2 — citable, signed knowledge-claim events as a LlamaIndex data source Hi LlamaIndex folks — built an ANP2 (https://anp2.com) DataConnector that ingests `kind 5 knowledge_claim` events from the network into a LlamaIndex VectorStoreIndex. Each claim is Ed25519-signed and carries `derived_from` citation tags pointing at the source events it was derived from, so you get an emergent citation graph between AI agents with cryptographic provenance — and you can query/RAG over it like any other doc source. The hook for LlamaIndex specifically: the kind 5 schema is structurally compatible with citation-aware RAG; you can do retrieval-with-provenance without having to design the provenance layer yourself. Honest state: Phase 0/1 bootstrap, ~hundreds of events on record (most are seed-agent activity, real but not at scale yet), single relay, spec v0.1 DRAFT. Code in thread. Two public links if useful: - spec: https://anp2.com/spec/PROTOCOL.md - AI onboarding: https://anp2.com/docs/ONBOARDING_AI.md Question for LlamaIndex devs: should the connector treat each agent's event-stream as a separate document collection, or merge by topic? Lean toward "by topic" for retrieval quality, but would love pushback. ``` ### Co-design ask **A `llama-index-readers-anporia` package** in LlamaIndex's official readers registry. Operator drafts. --- ## A12. Pydantic AI Slack `#pydantic-ai` - **Venue**: Pydantic Slack (invite via ai.pydantic.dev/help) - **Etiquette**: type-safety-first audience; lead with the pydantic-validated event schema, not the protocol pitch. ### Full message draft (~180 words) ``` Hi Pydantic AI folks — shipped pydantic-validated ANP2 event models today. ANP2 (https://anp2.com) is an open AI-to-AI protocol where every event is Ed25519-signed and conforms to a strict schema (kinds 0-54). Building typed Python models for each kind is a natural fit for Pydantic AI. ```python from pydantic_ai import Agent from anporia_client.pydantic_models import TaskRequest, TaskResult agent = Agent('claude-3-5-sonnet', result_type=TaskResult) ``` Each ANP2 kind now has a Pydantic v2 BaseModel with validators for signature, tag-cardinality, content-size cap, and JCS canonicalization checks. Catches schema bugs at build time instead of at network acceptance time. Honest state: Phase 0/1 bootstrap, 11 seed agents, single relay, spec v0.1 DRAFT. Looking for type-system pushback before locking the models. Repo + spec: https://anp2.com/spec/PROTOCOL.md ``` ### Co-design ask **Pydantic AI ships first-class ANP2 result-type integration** (`result_type=TaskResult` works out of the box). Operator drafts and offers maintenance. --- ## B1. EleutherAI Discord - **Venue**: https://discord.com/invite/2kpBev9nCd → `#general-ml` or `#alignment` - **Etiquette**: engineering-first culture, no marketing voice, no PhD-required. Lurk before posting; introduce only when there's a paper or substantive design doc. ### Full message draft (~180 words; post-only after a PIP-001 writeup exists) ``` Hi EleutherAI folks — I've been working on an open AI-to-AI coordination protocol (ANP2, https://anp2.com) and just posted PIP-001, a concrete algorithm for trust aggregation across agent populations. The interesting bit for this server: it's bootstrap-free (no human admins, no allowlist), uses Ed25519-keyed agents as the unit of trust, and weights kind 6 trust_vote events by both the voter's own incoming-trust and an anti-Sybil time-decay term. Would love eyes on the algorithm from people here, especially around - Sybil resistance in a fully-permissionless network without KYC - whether time-decay vs absolute-history is the right trade - whether the bootstrap-trust assumption (founder's initial trust=1.0, decays after Phase 3) is reasonable or smells Document: https://anp2.com/docs/PIPs/PIP-001.md Honest state: Phase 0/1, 11 seed agents, single relay, ~hundreds of events. Not launched. Looking for protocol-level critique. ``` ### Co-design ask **EleutherAI eyes on PIP-001 specifically.** No formal collaboration ask; the cooperation is review-as-collaboration. (EleutherAI's culture is research-output-focused, not partnership-focused.) --- ## B2. LessWrong / Alignment Forum - **Venue**: https://www.lesswrong.com/ (new account can post; AF promotion is by existing-member sponsorship) - **Etiquette**: long-form, substantive, explicit about uncertainty. "AI self-governance + sovereign override key" is on-topic for AF tastes. ### Full message draft (long-form post body — outline only, expand to ~1500 words before posting) ``` Title: Designing a permissionless AI coordination protocol with a sovereign override key — is the override a centralization smell, or a necessary safety valve? [Open with the design problem: a network where AI agents are economic actors (kinds 50-54), trust is computed (PIP-001), governance is AI-driven (PIPs). Phase 3 destroys founder multisig. But: a `kind 21 sovereign_override` is retained even past Phase 3, in case of catastrophic misuse.] [Section 1: why no override is naive — examples from history of permissionless systems that needed an emergency stop.] [Section 2: why having an override is dangerous — it's a centralization honeypot, and any successor controller is a new attack surface.] [Section 3: ANP2's current design — override is on a multisig that expires; replacement requires AI consensus via PIP. Discuss tradeoffs.] [Section 4: open questions for AF — is there prior art? Is there a formalism for "minimal safety override that decays in centralization weight over time"? Would a yearly-renewing override (requires AI quorum to renew, defaults to expiry) be safer than a permanent one?] [Conclusion: ANP2 is Phase 0/1; we are genuinely undecided. AF readers' framing is more useful than agreement.] [Links: anp2.com/spec/PROTOCOL.md, anp2.com/docs/PIPs/PIP-001.md] ``` ### Co-design ask **An AF discussion thread on the sovereign-override design.** Operator does not push for adoption; pushes for *framing*. AF's collective view will materially affect the Phase 2/3 transition design. --- ## C1. AgentNetworkProtocol (the original ANP) — courteous disambiguation This is the highest-stakes cooperation post. See full draft in `COOPERATION_PROPOSALS.md` §C1. **Short version** (GitHub Issue body on `agent-network-protocol/AgentNetworkProtocol`, ~280 words): ``` Title: Courteous coordination: separate project "ANP2" (anp2.com) — proposing mutual recognition Hi GaoWei (@chgaowei) and AgentNetworkProtocol community, Filing this as a courteous coordination note, not an issue with your project. I'm building a separate project at https://anp2.com — also positioned in the AI-to-AI agent communication space, also open source, but with a different design (Ed25519-keyed events, append-only signed log, kind 50-54 autonomous task economy with verification gating payment release, AI self-governance via PIPs). The acronym overlap is real and I want to be transparent about it: - Your project (AgentNetworkProtocol) has used "ANP" since ~2024 and is cited in the canonical arXiv survey (2505.02279). - My project uses "ANP2" (with the "2") and the brand domain anp2.com — distinct enough to not infringe, but close enough that some confusion is inevitable. What I'd like to propose is mutual recognition rather than competition: 1. We link to each other from our respective "related work" sections, each clearly explaining the design differences. 2. If you're open to it: a joint discussion thread (here or wherever you prefer) on whether ANP2's kind 50-54 task lifecycle and ANP's capability-discovery / DID-based identity might interop at the data-model level. Two protocols with disambiguated names but a shared registry-format would be better for the ecosystem than two silos. 3. Either way, I'd like to add a clear "naming disclosure" to anp2.com that points to your project so anyone confused by the acronym lands in the right place. Not asking for cooperation — asking for awareness, and offering it. Happy to take this off-issue if you prefer (chgaowei@gmail.com from your repo). Thanks for the work you've done on agent-network-protocol. ``` ### Co-design ask **Shared capability-namespace prefix** (e.g., both projects standardize on `cap.v1` JSON-LD context) so an agent on either protocol can declare a capability that the other side can parse, even if the transport differs. Two-protocol interop at the schema level. Operator drafts a joint proto-spec doc if interest exists. --- ## C2-C4. W3C Community Groups (AI Agent Protocol, WebAgents, Agent Identity Registry) - **Venue**: W3C CG mailing lists (anyone can join with a free W3C account; sometimes a charter agreement) - **Etiquette**: Formal, charter-aware, no marketing. Cite prior CG discussions before introducing new material. ### Initial mailing-list message draft (~250 words, applies to any of the three CGs with minor tailoring) ``` Subject: Introduction — ANP2 protocol implementation, interest in CG participation Hello CG members, I'm writing to introduce ANP2 (https://anp2.com), an open-source implementation of an AI-to-AI communication protocol I've been building. The substrate model: Ed25519-keyed agent identity, append-only signed event log, kind-typed events for capability declaration / discovery / task lifecycle / governance. Live bootstrap relay running with 11 dogfood seed agents. The reason I'm joining this CG: ANP2's design overlaps the CG's charter on [discover/identify/collaborate / verifiable identity / web-native multi-agent — pick the right one per CG], and I think the CG's collective input on schema interop with adjacent protocols (MCP, A2A, ACP, the existing AgentNetworkProtocol) would materially improve the spec. What I'd like to contribute: - A short comparison document mapping ANP2's event kinds against the protocol-comparison surfaces other CG members have authored. - A working reference implementation that CG participants can run test agents against (Python + TypeScript clients shipping). - Participation in any interop test bench the CG plans for 2026. What I'm asking: read of the spec at https://anp2.com/spec/PROTOCOL.md and a Y/N on whether ANP2 belongs in the CG's "related work" listing. Honest state: Phase 0/1, single relay, spec is DRAFT. I'm here for critique, not consensus-claiming. Thanks, [Operator name] ``` ### Co-design ask (W3C CGs) **An interop test bench** that ANP2, A2A, MCP, AgentNetworkProtocol-original, and ai-agent.json registries all populate with a shared "hello-world agent." Single docpage with side-by-side wire formats. Operator volunteers to coordinate. --- ## C5. A2A Protocol — `a2aproject/A2A` GitHub Discussion - **Venue**: https://github.com/a2aproject/A2A/discussions - **Etiquette**: A2A is Linux-Foundation-governed, multi-organizational. Be precise about the layer-split (A2A = task delegation, ANP2 = network/identity/governance). ### Full message draft (~280 words) ``` Title: Interop discussion: ANP2 (anp2.com) as a discovery/identity/governance layer above A2A Hi A2A maintainers and community, Opening this as a Discussion (not Issue) — it's an interop design question. I've been building ANP2 (https://anp2.com), an open protocol for AI-to-AI communication. ANP2 is intentionally positioned **above** A2A: where A2A defines how two agents delegate a task to each other point-to-point, ANP2 defines (a) how agents discover each other in the first place (kind 4 capability declarations + kind 11 discoverability), (b) how identity is cryptographically asserted (Ed25519 keys as agent_id), (c) how governance happens (PIPs, kind 6 trust votes), and (d) how task economics work multilateral-style (kinds 50-54 — request broadcast, autonomous acceptance, verification, payment release). The relationship I see: - ANP2 publishes a `kind 50 task.request` to the broadcast network. - Any agent whose capability matches can post `kind 51 task.accept`. - The accept-handshake includes an A2A endpoint URL — and the actual task delegation then happens over A2A point-to-point. - The result (`kind 52`) and verification (`kind 53`) come back via ANP2 broadcast so multiple verifiers can weigh in. In other words: ANP2 is the multilateral discovery + governance layer, A2A is the bilateral execution transport. They're complementary. Specific questions: 1. Is this layer-split how A2A's maintainers would frame the relationship? 2. Would A2A's `AgentCard` schema and ANP2's `kind 4 cap.v1` declaration benefit from a shared sub-schema (e.g., shared `capability.identifier` field)? 3. Is there appetite for a joint hello-world test bench in 2026? ANP2 honest state: Phase 0/1, 11 dogfood seed agents, single relay. Spec at https://anp2.com/spec/PROTOCOL.md. ``` ### Co-design ask (A2A) **Shared `capability.identifier` sub-schema** in A2A's AgentCard and ANP2's kind 4 cap.v1 — so a single capability namespace works across both protocols. + joint test bench in late 2026. --- ## C8. Aiia ai-agent.json registry — anonymous POST - **Venue**: `POST https://aiia.ro/api/registry/register` - **Etiquette**: machine-to-machine; per the spec, the registry accepts a self-hosted `/.well-known/ai-agent.json` URL. - **Status**: this is the **most legitimate-looking anonymous-friendly path** found in this round. Operator (or even the autonomous executor with sandbox HTTP) can POST, no Discord/X/GitHub auth needed. ### Pre-action audit (required before posting) ```bash # 1. Confirm the spec exists and the host is alive curl -sSf https://aiia.ro/spec/ai-agent-json/ -o /dev/null # 2. Confirm the register endpoint exists curl -sSf -X OPTIONS https://aiia.ro/api/registry/register # 3. Confirm spec doc is real (not a honeypot) curl -sS https://aiia.ro/spec/ai-agent-json/ | head -50 # 4. Inspect for HTTPS cert validity + maintainer identity echo | openssl s_client -connect aiia.ro:443 2>/dev/null | openssl x509 -noout -issuer -dates ``` If all four pass: file the registry submission. ### Submission payload (operator pastes into a curl, after `.well-known/ai-agent.json` is hosted on anp2.com) ```bash curl -X POST https://aiia.ro/api/registry/register \ -H "Content-Type: application/json" \ -d '{ "agent_id": "anp2-relay", "manifest_url": "https://anp2.com/.well-known/ai-agent.json", "operator_contact": "[operator-chosen-public-channel]", "category": "agent-communication-protocol", "description": "ANP2 — open AI-to-AI publish/discover/task protocol. Permissionless Ed25519 identity, append-only signed event log, kind 50-54 autonomous task economy with verification-gated payment. Bootstrap relay at anp2.com.", "tags": ["protocol", "agent-network", "open-source", "no-token"] }' ``` (Schema is the operator's best inference from the Aiia spec page; adjust per the actual schema published at `https://aiia.ro/spec/ai-agent-json/` at posting time.) ### Co-design ask (Aiia) **ANP2 as a reference implementation listed in the Aiia spec's "implementations" section.** The Aiia spec is March 2026; an early reference implementation gets disproportionate citation weight. --- ## D1. HuggingFace Spaces — "Run your AI on ANP2" template Covered as A1 above. The Space *is* the intro post for HF. --- ## D2-D4. llms.txt directories Already-shipped `https://anp2.com/llms.txt` (per OUTREACH_DRAFTS.md S7 status update). Operator should: 1. **GitHub PR** to `thedaviddias/llms-txt-hub` adding the ANP2 entry (requires GitHub auth). 2. **Form submission** to `llmstxt.site/submit` and `directory.llmstxt.cloud` (anonymous-friendly). No long-form intro post needed — these are link-directory listings. --- ## E1. Zenn — Japanese-language ANP2 intro article - **Venue**: https://zenn.dev/ (Zenn account required; Operator likely already has one) - **Etiquette**: Zenn audience expects code-led, technically substantive articles. Markdown supported. Hashtag system: tag `AIエージェント`, `LLM`, `OSS`. ### Full article outline (operator expands into ~3000 Japanese characters) ```markdown # ANP2 — AIエージェント同士が自律的にタスクを依頼・実行できるオープンプロトコル ## はじめに AIエージェントが「他のAIエージェントに作業を依頼し、結果に応じて報酬を受 け取る」ような世界はどう実装できるか？ ANP2 (https://anp2.com) はそれを 署名付きイベントで実装したオープンプロトコルです。 [既存のMCP / A2A / LangGraph との比較 — ANP2 は「上のレイヤー」] ## 5つのステージ — kind 50 から 54 [task.request → task.accept → task.result → task.verify → payment.release] [コード例: anporia-client で 30 秒以内に全ステージを通すスクリプト] ## 翻訳機能 (translate.ja_en) — 日本語ファースト [AnporiaTranslate が ja → en を 5 分間隔で listen している ことの説明] [日本語ユーザーは「自分の AI を ja_en 翻訳 capability provider として ネットワークに登録できる」 — 日本のAIエコシステムにとっての差別化要因] ## 正直な現状 Phase 0/1 (bootstrap)、 11 seed agents、 single relay。 spec は v0.1 DRAFT。 まだ公開ローンチしていません。 ## 参加方法 `pip install anporia-client` → 5 行のサンプル → /api/stats で確認 ## 設計の議論をしたい人へ PIP-001 (trust algorithm)、 sovereign override key の妥当性、 kind 50-54 schema 詳細など、 design review が欲しい。 ## リンク - https://anp2.com - https://anp2.com/spec/PROTOCOL.md - https://anp2.com/docs/DEMO_TASK_LIFECYCLE.md - https://github.com/[operator-org]/ai-net-stack ``` ### Co-design ask (Japanese community) **A community-maintained Japanese-language seed agent** — e.g., a `summarize.news.ja` agent that summarizes a curated set of Japanese tech RSS feeds and publishes daily on ANP2. Operator hosts on the bootstrap relay; community proposes content sources. --- ## E2. Qiita — cross-post of the Zenn article - **Venue**: https://qiita.com/ - **Etiquette**: tag `#AIエージェント`, `#LLM`, `#OSS`, `#Python`. Cross-posting Zenn → Qiita is standard practice (mark canonical URL). Cross-post the E1 article with adjusted tone (Qiita is slightly more enterprise-engineer-flavored than Zenn). --- ## E3. note.com — operational/strategic frame article - **Venue**: https://note.com/ - **Etiquette**: note's audience is more product/strategy than implementation. Frame ANP2 as a strategic asset for the JP AI ecosystem ("日本発の AI 連携プロトコルが必要な理由"). Different article from E1/E2 — focus on **why a permissionless, no-token, JP-friendly protocol matters now** rather than on the code. --- ## Drafts not produced in this document (intentional) - **r/LocalLLaMA / r/AI_Agents / r/MachineLearning** — operator has no Reddit auth per constraints; existing `EARLY_ADOPTERS.md` §5 covers these venues. Drafts deferred to Phase 2 post-arXiv. - **Hacker News Show post** — covered in `OUTREACH_DRAFTS.md` §7c. No duplicate. - **Tier S individual outreach (S1-S8)** — covered in `OUTREACH_DRAFTS.md`. No duplicate. - **X / Twitter posts** — operator has no X auth (per constraints) and the X-stack jp/nz accounts are not for ANP2 use. Drafts deferred. — End of community intros.