Architecture
Pelagora is built as a set of composable packages that work together to form a decentralized marketplace.
Package overview
┌─────────────────────────────────────────────────┐
│ AI Assistants │
│ (Claude, etc. via MCP) │
└────────────────────┬────────────────────────────┘
│
┌──────┴──────┐
│ MCP Server │ @pelagora/mcp
│ (bridge) │
└──────┬──────┘
│ HTTP
┌──────┴──────┐
│ Pelagora │ pelagora
│ Node │
│ ┌────────┐ │
│ │ Web UI │ │
│ │REST API│ │
│ │ SQLite │ │
│ └────────┘ │
└──┬───────┬──┘
│ │
┌──────┴──┐ ┌─┴──────────┐
│ DHT │ │ PIM │ @pelagora/pim-protocol
│(Hyper- │ │ Protocol │
│ swarm) │ │ (types) │
└────┬────┘ └────────────┘
│
┌──────┴──────┐
│ Other Nodes │
└─────────────┘Data flow
Local operations
- User interacts via Web UI, REST API, or MCP Server
- Pelagora node processes the request
- Data is stored in a local SQLite database (WAL mode)
- Changes are broadcast to connected peers via the DHT
Peer discovery
- Node joins the Hyperswarm DHT on startup
- Peers discover each other by topic (derived from network key)
- Connections are established directly between nodes
- Peer messages follow the
PeerMessageformat defined in PIM Protocol
AI integration
- MCP Server connects to the node's REST API over HTTP
- Exposes node capabilities as tools (list items, search, make offers)
- AI assistants call these tools in response to natural language requests
Key design decisions
- Local-first — All data is stored locally in SQLite. No cloud dependency.
- Schema.org aligned — Product data uses Schema.org vocabulary for interoperability.
- Plugin architecture — Skills extend node capabilities without modifying core code.
- Protocol-first — Shared types in
@pelagora/pim-protocolensure all packages speak the same language.
Next steps
- Pelagora Node → — Deep dive into the node
- PIM Protocol → — Understand the type system
- MCP Server → — AI integration details