NanoClaw
NanoClaw rebuilds Mattermost support on its v2 channel adapter
NanoClaw has replaced an obsolete REST-polling Mattermost proposal with a current v2 ChannelAdapter implementation using WebSockets, thread-aware routing and a conformant setup skill. The older pull request is closed; the new one explicitly documents missing uploads, cards, native streaming and interactive commands.
nanocoai/nanoclaw PR #3199 is the inspected primary source: “Add Mattermost channel integration (v2 ChannelAdapter).” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- nanocoai/nanoclaw PR #3199 was created 2026-08-07T21:08:52Z and was open at inspection; its title is “Add Mattermost channel integration (v2 ChannelAdapter).” - nanocoai/nanoclaw PR #546 was created 2026-02-26T23:01:06Z and was closed at inspection; its title is “Add Mattermost channel skill (/add-mattermost).” - nanocoai/nanoclaw PR #2909 was created 2026-07-02T09:42:04Z and was open at inspection; its title is “feat(setup): template setup flow in the wizard and first-agent stamping.” - The repository reported 30466 stars, 868 open issues, default branch main, and last push 2026-08-06T13:28:16Z. - The latest tagged-release baseline checked was v2.1.54 published 2026-08-01T20:46:31Z.
What changed
nanocoai/nanoclaw PR #3199 reports: Supersedes #546, which targeted the pre-v2 Channel/registry.ts architecture that no longer exists on main. This is a fresh implementation against the current ChannelAdapter/channel-registry.ts contract. Summary src/channels/mattermost.ts — registers via registerChannelAdapter, wraps the community chat-adapter-mattermost package through createChatSdkBridge, following the same pattern as slack.ts. WebSocket-based (/api/v4/websocket) rather than REST polling — a behavior improvement over the original v1 approach. supportsThreads: true, verified against the adapter's actual channelId/rootPostId thread model (channel-is-default, thread-is-optional-sub-conversation — same shape as Slack), not assumed from the Slack template. src/channels/mattermost-registration.test.ts mirrors the existing slack-registration.test.ts..claude/skills/add-mattermost/SKILL.md — written in the current nc: directive format (modeled on add-slack/add-imessage), with apply-fixtures.json for scripts/skill-conformance.test.ts. chat-adapter-mattermost added as a pinned dependency — community/unscoped package, same risk tier already accepted for chat-adapter-imessage. Known limitations (from the adapter, documented in the skill's Troubleshooting section) No editable file uploads after posting Cards render as plain-text fallback (no native card support) No native streaming (post-and-edit only) No slash commands or interactive modals
nanocoai/nanoclaw PR #546 reports: Closes #1379 Summary Rewrites the Mattermost integration to use the **channel registry pattern** (self-registration), matching upstream architecture MattermostChannel class implementing the Channel interface with registerChannel() at module level No modifications to src/config.ts or src/index.ts — only adds a barrel import in src/channels/index.ts REST API polling (2s interval) for message retrieval Supports public channels, private channels, group DMs, and direct messages Changes from v1 **Removed** all hardcoded Mattermost references from config.ts and index.ts **Removed** MATTERMOST_ONLY config — uses the standard channel registry (all configured channels run together) Channel reads its own credentials from.env via readEnvFile() in the factory function Rebased cleanly on current main (no merge conflicts) Files Added src/channels/mattermost.ts — Channel implementation with self-registration src/channels/mattermost.test.ts — Unit tests (8 tests).claude/skills/add-mattermost/ — Skill package (SKILL.md, manifest.yaml, add/modify files) Files Modified src/channels/index.ts — Added import './mattermost.js' barrel import src/routing.test.ts — Added Mattermost JID pattern test.env.example — Added MATTERMOST_URL and MATTERMOST_BOT_TOKEN Testing All 228 tests
nanocoai/nanoclaw PR #2909 reports: Summary Agent templates, part 2 of 2. The template loader landed in #2890; this adds the setup-wizard flow and first-agent stamping. What it does The standard setup flow asks **"How should we create your first agent?"** right before the sandbox build: **Fresh agent** (Enter-through default), the **NanoClaw template library** (clones the fixed public registry once, copies the chosen template into local templates/), or **local templates**. The pick reaches scripts/init-first-agent.ts as an explicit --template flag, passed by all six channel drivers via the new setup/lib/picked-template.ts helper. NANOCLAW_TEMPLATE_PATH is only the carrier across setup's self re-execs (sg docker, fail-retry), so a resume keeps the pick instead of re-asking. A new templatePath config entry presets the ref and skips the picker: --template-path flag, NANOCLAW_TEMPLATE_PATH env, or the Advanced screen ("First-agent template"), validated against templates/ up front. Stamping is idempotent (reuse by folder), so a setup retry cannot create a duplicate group and double-wire the DM. Channel paths that
Why it matters
Channel adoption becomes expensive when an integration targets yesterday’s registry. Superseding rather than rebasing the old patch makes the architectural break visible and gives operators an honest capability floor. The operator test is whether the visible result, retained state and authority still describe the same event after retries, background work or restart.
Current
The primary record was open when captured on 2026-08-08. The release baseline was v2.1.54 published 2026-08-01T20:46:31Z. Repository metadata, source bodies, pull requests, issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nanocoai/nanoclaw/pull/3199. Supporting records are https://github.com/nanocoai/nanoclaw/pull/546 and https://github.com/nanocoai/nanoclaw/pull/2909. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Verify reconnect and thread identity against a live server, treat the community adapter as a reviewed dependency, and keep unsupported interaction types visible in setup rather than failing silently. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.