[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-81355":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":18,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":21,"hasPages":21,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":27,"discoverSource":28},81355,"Synapse","zai-org\u002FSynapse","zai-org","Self-hosted AI workspace with shareable AI teammates, shared conversations, memory, and governed access to plugins, MCP tools, and local devices.","https:\u002F\u002Fsynapse-zai-org.vercel.app\u002F",null,"TypeScript",46,5,40,3,0,2,6,47.93,"Apache License 2.0",false,"main",[],"2026-06-12 04:01:33","\u003Cp align=\"center\">\n    \u003Cpicture>\n        \u003Csource media=\"(prefers-color-scheme: light)\" srcset=\"docs\u002Fassets\u002Fsynapse-full-logo.svg\">\n        \u003Cimg src=\"docs\u002Fassets\u002Fsynapse-full-logo-dark.svg\" alt=\"Synapse\" width=\"500\">\n    \u003C\u002Fpicture>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Cstrong>Build AI teams, not chatbots.\u003C\u002Fstrong>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  A self-hosted AI workspace for shareable teammates, shared conversations, memory,\n  governed access to plugins and MCP tools, local execution, and event-driven automation.\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Cstrong>English (US)\u003C\u002Fstrong> ·\n  \u003Ca href=\".\u002FREADME_CN.md\">简体中文\u003C\u002Fa> ·\n  \u003Ca href=\".\u002FREADME_ES.md\">Español\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"#why-synapse\">Why Synapse\u003C\u002Fa> ·\n  \u003Ca href=\"#architecture-overview\">Architecture\u003C\u002Fa> ·\n  \u003Ca href=\"#example-flows\">Example Flows\u003C\u002Fa> ·\n  \u003Ca href=\"#roadmap\">Roadmap\u003C\u002Fa> ·\n  \u003Ca href=\"#quick-start\">Quick Start\u003C\u002Fa> ·\n  \u003Ca href=\"#surfaces-in-this-repo\">Surfaces in This Repo\u003C\u002Fa> ·\n  \u003Ca href=\".\u002Fdeploy.md\">Deployment\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Cimg\n    src=\"docs\u002F.images\u002Fgpt-image-2\u002Fsynapse-framework-gpt-image-2-20260514-061731.png\"\n    alt=\"Synapse framework overview\"\n    width=\"100%\"\n  \u002F>\n\u003C\u002Fp>\n\n> [!WARNING]\n> Synapse is still in an early design and implementation phase. Schemas, runtime contracts, and product surfaces can change quickly, and backwards compatibility for old data is not guaranteed yet.\n\nSynapse is a conversation-centric runtime for digital teammates.\n\nMost AI products treat chat as a thin interface on top of isolated bots. Synapse treats the conversation itself as the collaboration boundary: humans, platform-native actors, and bridged remote agents can work in the same thread; memory, permissions, plugins, relay-exposed tools, and event sources are governed at the workspace layer; shareable teammates can be added across workspaces like contacts and then granted the right resources to work.\n\n## Why Synapse\n\n- **Conversation-first, not bot-first.** A conversation is the runtime boundary for participants, transcript visibility, actor execution, wakeups, and memory handoff.\n- **Shareable teammates.** Workspace members, actors, and remote agents can be shared across workspaces and added through a contact-style graph. Shared actors can work with the destination workspace's granted resources.\n- **Governed resource access.** Plugins, skills, MCP relay exposures, and event sources are modeled as workspace-owned resources with explicit access control, grants, and audit trails.\n- **Cloud coordination plus local execution.** Teams can collaborate in the web app while still reaching local browsers, desktops, filesystems, internal services, or bridged remote-agent runtimes.\n- **Event-driven teamwork.** Scheduled jobs, custom webhooks, and integration-backed event sources can wake conversations and route work automatically.\n- **Native and remote agents together.** Platform-native actors live inside Synapse. Remote agents join through a bridge and keep their own runtime stack.\n\n## Core Model\n\n| Concept          | What it means in Synapse                                                                          |\n| ---------------- | ------------------------------------------------------------------------------------------------- |\n| `Workspace`      | Ownership and governance boundary for teammates, plugins, relay devices, and event sources.       |\n| `Conversation`   | Shared runtime where participants collaborate and work is persisted.                              |\n| `Actor`          | A native Synapse teammate managed by the platform.                                                |\n| `Remote agent`   | An external runtime bridged into a conversation without becoming a native actor.                  |\n| `Resource layer` | Plugins, skills, MCP relay exposures, and event sources that can be granted, audited, and reused. |\n\n## Architecture Overview\n\nSynapse uses a conversation-centric architecture. Around that core, the system separates resource runtimes, access control, memory, transport integration, and context management into distinct subsystems.\n\n- **Conversation and session runtime.** `conversation`, participants, conversation items, actor sessions, and `session_wakeups` define the primary collaboration and execution model. Web chat, remote-agent bridges, and IM transports reuse this model rather than implementing separate conversation systems.\n- **Resource runtimes.** Plugins, installed skills, relay exposures, actors, and remote agents are represented as distinct runtime resources with independent state, lifecycle, and APIs. Marketplace catalog metadata is stored separately from installed runtime state.\n- **Access control.** Authorization is evaluated against explicit resource types, including `workspace`, `conversation`, `actor`, `remote_agent`, `plugin_installation`, `installed_skill`, `relay_capability`, and `memory_item`. Sharing, invocation, and governance therefore rely on the same access model.\n- **Memory subsystem.** Memory is partitioned by scope: `workspace_shared`, `conversation_shared`, `actor_private`, `participant_private`, and `user_private`. Retrieval combines lexical indexing and embeddings to support both durable memory and thread-local working state.\n- **Transport and automation integration.** IM transports bind external endpoints back to conversations. Event sources, schedules, webhooks, and integration triggers enter the same runtime so they can wake sessions and emit conversation-visible events.\n- **Context window management.** Model context is compiled from canonical context items into shared and private archive chains plus a live tail window. Archive points, compaction runs, and per-event context policies bound prompt size while preserving scope and event semantics.\n\n## Example Flows\n\n- Share a research actor into another workspace, grant it the right plugins, and let it work in the same thread as people.\n- Pair a desktop relay so teammates can use browser, filesystem, or command-line capabilities without giving every conversation global access.\n- Register GitHub, GitLab, or custom webhook event sources to wake an incident room and bring the right actors into the conversation.\n- Bridge a coding agent from another machine as a remote agent and let it collaborate in Synapse while keeping its own external runtime and tools.\n\n## Exploratory Features\n\nThis section highlights runtime directions that are already being validated in code, but should not yet be treated as stable platform contracts.\n\n### Everything is a file model\n\nSynapse is exploring a virtual-filesystem projection for selected local runtimes. The goal is to expose state, structure, and actions through paths, files, and writable control nodes. This fits the platform's authorization model and also aligns with models' strong prior over command-line workflows, where composition, pipes, and chained operations can express richer procedures with fewer execution round trips.\n\nCurrent support includes:\n\n- **Session-scoped VFS exposures.** Relay VFS currently projects builtin browser and CUA runtimes under session paths, with file-based controls for session creation, inspection, and teardown.\n- **Browser projection.** The browser surface exposes page state, page lists, current-page snapshots and screenshots, a tree projection with per-node files, and writable action files for navigation and interaction.\n- **CUA projection.** The CUA surface exposes displays, windows, apps, captures, keyboard state, focused-element summaries, and a semantic accessibility tree when the desktop backend is available.\n- **Action files.** Writable nodes are already mapped to concrete runtime actions. In the browser surface this includes operations such as `navigate`, `new_page`, `select_page`, `click`, `fill`, `press_key`, and `evaluate`; in the CUA surface this includes `click`, `type_text`, `press_keys`, and `scroll`, with per-node semantic actions where actionable bounds are available.\n\n## Roadmap\n\nRoadmap items describe planned platform capabilities. They are directional and may change as the runtime model evolves.\n\n### Planned: Sandbox runtime\n\nIntroduce a managed Sandbox runtime as a governed execution surface for agents.\n\nPlanned goals:\n\n- Provide isolated execution environments as workspace-governed resources rather than direct host access.\n- Support suspend\u002Fresume and persistent state so agent work can continue across runs.\n- Offer standardized environment profiles, including optional GUI variants and preconfigured integrations.\n- Support both cloud-hosted and local-managed deployments.\n- Evaluate E2B-style control interfaces where they fit Synapse's conversation, resource, and authorization model.\n\nThis is a planned capability, not a shipped feature.\n\n## Quick Start\n\n### Local web + API\n\nPrerequisites:\n\n- Node.js\n- Docker and Docker Compose\n\nClone the repo and start the core local stack:\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fzai-org\u002FSynapse\ncd Synapse\n\nnpm ci\n.\u002Fsetup.sh\ndocker compose up -d postgres redis\n\n# Create the current schema\nnpm run db:bootstrap\n\n# Start the API and desktop web in separate terminals\nnpm run dev:api\nnpm run dev:web\n```\n\nOpen:\n\n- Desktop web: `http:\u002F\u002Flocalhost:3000`\n- API health: `http:\u002F\u002Flocalhost:3001\u002Fapi\u002Fv1\u002Fhealth`\n\nIf your local Docker setup requires elevated privileges, run the `docker compose` command with `sudo`.\n\nBefore using actor or chat flows with real models, edit `.env` and set an AI provider such as `AI_PROVIDER`, `AI_API_KEY`, `AI_BASE_URL`, and `AI_MODEL`.\n\n### Optional: reset and seed a demo environment\n\nIf you want a fully seeded local environment with demo users, a demo workspace, official actors, and built-in plugin catalog entries:\n\n```bash\nnpm run db:rebuild\n```\n\nSeeded demo accounts:\n\n- `demo@synapse.dev` \u002F `demo1234`\n- `yihang@synapse.dev` \u002F `demo1234`\n\n### Optional: run the Expo mobile app\n\nThe mobile client lives in its own package with its own lockfile:\n\n```bash\ncd packages\u002Fmobile-app\nnpm ci\nnpm run web\n```\n\nYou can also use `npm run ios` or `npm run android` inside `packages\u002Fmobile-app`.\n\n## Surfaces in This Repo\n\n- `packages\u002Fapi` — Fastify API, orchestration runtime, chat, memory, files, automation, plugins, relay, IM, and audit surfaces\n- `packages\u002Fweb-next` — Next.js desktop web app and workspace dashboard\n- `packages\u002Fmobile-app` — Expo Router mobile app and exported mobile web surface\n- `packages\u002Fremote-agent-daemon` — machine-side daemon for bridging external runtimes such as Codex CLI or Claude Code\n- `packages\u002Fshared` — shared types, protocol contracts, automation definitions, and constants\n- `subprojects\u002Fcli-anything` — vendored capability pack used by relay-backed auto-loaded skills\n\n## Deployment\n\nThis repository currently ships with a self-hosting path centered on a single Ubuntu host:\n\n- `systemd` for the API and desktop web services\n- `nginx` as the public entrypoint\n- Dockerized PostgreSQL and Redis for local infrastructure\n- desktop web served from `packages\u002Fweb-next`\n- mobile web exported as static assets from `packages\u002Fmobile-app`\n\nSee [`deploy.md`](deploy.md) for the production deployment path used in this repo.\n","Synapse 是一个自托管的AI工作区，旨在构建可共享的AI队友，支持共享对话、记忆以及对插件、MCP工具和本地设备的受控访问。其核心功能包括以对话为中心的运行时环境，允许人类用户、平台原生角色及远程代理在同一线程中协作；通过工作区层管理内存、权限、插件等资源，实现跨工作区的角色共享；提供云协调与本地执行能力，让团队能够在网页应用中合作的同时触及本地浏览器、桌面文件系统或内部服务。该项目适合需要高效协同工作的开发团队使用，特别是在那些希望集成多种AI工具和服务，并保持对数据和流程控制的场景下。","2026-06-11 04:04:45","CREATED_QUERY"]