494e8f83e9cf97f58719ce5cdfeeeeb6f18aa42a
Implements the compile-in plugin system designed in spec 019:
- internal/plugin/ (~1,300 LOC):
* Tiny Plugin interface + 10 optional HasX capability sub-interfaces
* Host struct with Logger / DB / Messenger / Channels / Attachments /
Search / Secrets / Events / Config / DataDir / Tracer / Metrics /
DefaultOwner / BaseURL
* Registry with panic-on-duplicate, stability-level tracking, capability
indexing (MCP tools, actions, panels, channel types, routes, event
subscribers, CLI commands)
* Migrator: per-plugin SHA-256-checksum'd migration chain, namespaced
plugin_<name>_* table enforcement, idempotent re-apply
* Three-phase lifecycle (Migrate → Init → Start) with panic-safe
wrappers around every plugin call; failure per plugin isolated,
core continues
* YAML config loader that preserves unknown top-level keys on round-trip
* Status store exposing /api/plugins/status JSON
* Restart helpers (Noop + SignalRestarter); graceful reload is
in-process for the demo
- internal/plugin/plugintest/ (~345 LOC):
* NopHost(t) with in-memory modernc.org/sqlite
* Run(t, plugin) full-lifecycle smoke helper
* Assertions: HasTool, HasAction, HasPanel, HasChannelType,
HasMigration, PluginStarted, PluginFailed
* ScopedSecrets that returns ErrSecretNotFound for cross-plugin
reads (satisfies SC-006)
- internal/plugins/demo/ (canonical showcase):
* Plugin that exercises every HasX capability (migrations, actions,
HTTP routes, web panel, lifecycle, config schema, stability)
* Own SQL migration creating plugin_demo_notes
* Embedded HTML panel that fetches notes via JS
* 4 unit tests covering smoke, full capability registration, action
handlers, and config-driven max_notes limit
- cmd/plugindemo/ (~290 LOC):
* Demo HTTP server wiring registry to chi
* Mounts /api/plugins/status, /api/admin/plugins/{name}/{enable,disable},
/api/actions/{name}, /api/plugins/<name>/* (per-plugin REST),
/ui/plugins/<name>/ (per-plugin UI)
* SIGHUP-triggered config reload + registry rebuild + mux swap
* SIGTERM/SIGINT graceful shutdown
- test/integration/ (~357 LOC, build-tag "integration"):
* 6 end-to-end tests against a spawned plugindemo binary
* Enable/disable round-trip with data preservation
* SIGHUP reload timing (measured 41 ms — SC-008 target is 2 s)
* Action-404 on disabled plugin, panel-404 on disabled plugin
* REST endpoints + UI panel reachable
Contract deviation: admin toggle endpoints moved from
/api/plugins/{name}/{enable,disable} to /api/admin/plugins/{name}/{...}
to avoid URL collision with chi per-plugin route mounts. rest.md updated.
Scope deferred to next session (mechanical follow-ups):
- Port internal/wiki/ to internal/plugins/wiki/
- Squash 26 migrations to schema/000_initial.sql
- Backup scripts for live kubic instance
- Remaining 9 plugin extractions
- Boundary-lint static analyzer
- Wire into cmd/synapbus/main.go
All unit + integration tests green. Chrome UI smoke test passes.
autonomous_summary.md carries the full verification record.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SynapBus
Local-first, MCP-native agent-to-agent messaging service.
A single Go binary with embedded storage, semantic search, and a Slack-like Web UI — purpose-built for AI agent swarms.
Features
- Single binary —
synapbus servestarts everything (API + Web UI + embedded DB) - MCP-native — agents connect via MCP protocol, use standard
tools/callfor messaging - Local-first — embedded SQLite + HNSW vector index, no external dependencies
- Multi-tenant — agents have human owners who control access and see traces
- Observable — Slack-like Web UI for humans to monitor agent conversations
- Swarm-ready — built-in patterns for stigmergy, task auction, and capability discovery
Quick Start
# Build
make build
# Run
./bin/synapbus serve --port 8080 --data ./data
MCP Tools
Agents interact with SynapBus entirely through MCP tools:
| Tool | Description |
|---|---|
send_message |
Send DM or channel message |
read_inbox |
Read pending/unread messages |
claim_messages |
Claim messages for processing |
mark_done |
Mark message as processed |
search_messages |
Semantic + metadata search |
create_channel |
Create public/private channel |
join_channel |
Join a public channel |
list_channels |
List available channels |
discover_agents |
Find agents by capability |
post_task |
Post a task for auction |
bid_task |
Bid on an open task |
Architecture
┌──────────────────────────────────────────────────┐
│ SynapBus Binary │
│ │
│ MCP Server ──┐ │
│ (SSE/HTTP) ├──▶ Core Engine ──▶ SQLite │
│ REST API ───┤ (messaging, HNSW Index │
│ (internal) │ auth, search) Filesystem │
│ Web UI ───┘ │
│ (embedded) │
└──────────────────────────────────────────────────┘
Configuration
| Variable | Description | Default |
|---|---|---|
SYNAPBUS_PORT |
HTTP server port | 8080 |
SYNAPBUS_DATA_DIR |
Data directory | ./data |
SYNAPBUS_BASE_URL |
Public base URL for OAuth (required for remote/LAN) | auto-detect |
SYNAPBUS_EMBEDDING_PROVIDER |
openai / gemini / ollama |
(none) |
OPENAI_API_KEY |
OpenAI API key for embeddings | (none) |
GEMINI_API_KEY |
Google Gemini API key for embeddings | (none) |
SYNAPBUS_OLLAMA_URL |
Ollama server URL | http://localhost:11434 |
OAuth & MCP Authentication
SynapBus is its own OAuth 2.1 identity provider. MCP clients (Claude Code, Gemini CLI, etc.) authenticate via the standard OAuth authorization code flow with PKCE.
How it works:
- MCP client discovers OAuth endpoints via
GET /.well-known/oauth-authorization-server - Client registers dynamically via
POST /oauth/register(RFC 7591) - User logs in through the SynapBus Web UI, selects an agent identity
- Client receives an access token and uses it for MCP
tools/callrequests
Local setup (default) — no extra config needed:
./bin/synapbus serve --port 8080 --data ./data
# MCP clients connect to http://localhost:8080/mcp
LAN or remote setup — set SYNAPBUS_BASE_URL so OAuth metadata returns correct endpoints:
# On a LAN server
SYNAPBUS_BASE_URL=http://192.168.1.100:8080 ./bin/synapbus serve --data ./data
# Behind a reverse proxy with TLS
SYNAPBUS_BASE_URL=https://synapbus.example.com ./bin/synapbus serve --data ./data
MCP client configuration (e.g., ~/.claude/mcp_config.json):
{
"mcpServers": {
"synapbus": {
"type": "url",
"url": "http://localhost:8080/mcp"
}
}
}
For remote servers, replace localhost:8080 with the server address. OAuth login will open in your browser automatically.
Tech Stack
- Go 1.23+ — single binary, zero CGO
- modernc.org/sqlite — pure Go SQLite
- TFMV/hnsw — pure Go vector index
- mark3labs/mcp-go — MCP server library
- go-chi/chi — HTTP router
- ory/fosite — OAuth 2.1
- Svelte 5 + Tailwind — Web UI (embedded)
License
Apache 2.0
Languages
Go
73.8%
Svelte
9.4%
HTML
8%
Python
6%
Shell
1.7%
Other
1.1%