Link Triage explainer · GitHub repository

anyproto/anytype-ts

Official Anytype desktop client: a large Electron + TypeScript app for a local-first, peer-to-peer, end-to-end-encrypted knowledge OS. The captured link points to the Quick Start section, but the useful story is the stack and architecture behind a serious open-source, local-first personal knowledge product.

Source: github.com/anyproto/anytype-ts Captured URL anchor: # Quick Start Default branch: develop Version inspected: 0.55.8-alpha Explainer written: 2026-05-28T12:19:00Z

~8.0k GitHub stars at fetch time

TypeScript Primary language; React/Electron frontend

ASAL 1.0 Any Source Available License, not permissive OSS

What it is

Anytype is a personal knowledge base / “digital brain” that lets users create pages, tasks, wikis, journals, databases, kanban boards, calendars, custom object types, and graph-like relationships. Its distinguishing design choices are:

Local-first/offline-first: data lives locally and should remain usable without the network.
Peer-to-peer sync: optional sync uses Any’s any-sync ecosystem rather than a simple central SaaS backend.
End-to-end encryption: README describes zero-knowledge encryption powered by any-sync.
Composable objects/blocks: pages are built from blocks and custom types, similar to Notion/Coda but with a local-first privacy posture.
Desktop-first client: this repository is the official macOS/Linux/Windows app, built with Electron, React, TypeScript, Vite, Bun, and a Go middleware layer.

Why this matters for Mission Control

This is not just a reading link. It is a reference implementation for a local-first knowledge workspace with custom types, block editing, graph/database surfaces, sync boundaries, and desktop packaging.

Relevant to: possible Mission Control substrate evaluation, local-first UX patterns, item/object modeling, graph surfaces, and future Dab workflows that need a private durable knowledge base.

Architecture map

Electron shellelectron/, electron.js. Windowing, system integration, updates, packaging, native messaging host hooks.

React renderersrc/ts/. App entry, pages, components, MobX stores, router, block/editor UI.

gRPC API layersrc/ts/lib/api/ + generated middleware bindings. Renderer talks to backend through commands/mapper/streams.

anytype-heartSeparate Go middleware repository. Build instructions require cloning it beside anytype-ts.

any-sync networkLocal-first encrypted sync substrate. Optional P2P sync beyond the local desktop client.

Source map

Area	What to look at
`src/ts/component/`	UI components: blocks, pages, menus, popups, sidebar, widgets, graph views, dataview surfaces.
`src/ts/lib/`	Core utilities, API command layer, renderer IPC, keyboard/storage/router helpers.
`src/ts/store/`	MobX stores split by domain: auth, block, detail, common app state, menus/popups/UI state.
`src/scss/`	Styles mapped to component structure; project guidance emphasizes exact design values.
`electron/`	Main process TypeScript, signing/update hooks, preload bridge, safe storage, server/window/menu code.
`dist/`	Bundled/static assets, web clipper extension artifacts, graph worker bundles, fonts and themes.
`docs/`	Internal docs and generated README-style maps for component/lib areas.
`scripts/`	Build helpers: Electron build, dependency analysis, proto generation, release notes, web/dev startup.

Tech stack signals

Runtime/build: Bun, Vite, Electron, electron-builder.
Frontend: React 18, TypeScript, MobX, SCSS, Lexical editor, dnd-kit, D3, PixiJS worker for graph rendering.
Backend bridge: gRPC-web / protobuf bindings to anytype-heart.
Packaging: macOS, Windows, Linux scripts with signing/notarization flags and AppImage assets.
Extension: web clipper extension build path with Firefox/Chromium manifest switching.
Quality tooling: TypeScript typecheck, Biome, ESLint, Vitest, Storybook, lint-staged/Husky.

Install / use path

For normal use

The README recommends downloading installers from GitHub releases or download.anytype.io and logging in with an Any-ID.

For source build / evaluation

git clone https://github.com/anyproto/anytype-ts.git
cd anytype-ts
bun install
./update.sh <macos-latest|ubuntu-latest|windows-latest> <arm|amd>
cd ..
git clone https://github.com/anyproto/anytype-heart.git
cd anytype-heart
make install-dev-js CLIENT_DESKTOP_PATH=../anytype-ts
cd ../anytype-ts
bun run update:locale
bun run dist:<linux|win|mac>

For local development, the repo also documents nix develop --command $SHELL, bun run start:dev, bun run start:web, bun run typecheck, and bun run lint. ARM systems may need C++ compiler + Python setuptools because keytar rebuilds during installation.

Maturity signals

Large, active repository: fetched metadata showed updates and pushes on 2026-05-28.
Latest release inspected: v0.55.8-alpha, published 2026-05-26, with macOS, Linux AppImage, and Windows-style release assets visible via the GitHub API.
Substantial codebase: recursive tree returned 6,926 files; src/ and dist/ dominate, with many generated/static assets.
Clear build/development scripts and explicit architecture guidance in CLAUDE.md.
Open issues enabled; metadata showed 166 open issues, which is normal for a large client app but still a maintenance signal.

Caveats / risks

License is not permissive: ASAL 1.0 allows non-commercial use and some commercial use only on allowed networks. Treat it as source-available, not MIT/Apache-style reusable OSS.
Not a simple backend drop-in: the useful ideas are architectural; adopting Anytype itself as Mission Control’s backend would mean accepting its object model, app UX, sync layer, and account/network assumptions.
Build complexity: source builds need Bun, Electron, platform-specific native deps, middleware assets, and a sibling anytype-heart checkout.
Generated/dist-heavy repo: lots of bundled assets and generated outputs can make source archaeology noisy.
Agent docs mismatch: AGENTS.md appears generic/outdated compared with the richer repo-specific CLAUDE.md; use README + CLAUDE.md + actual tree as source of truth.

Mission Control fit

Question	Answer
Should Dab install/run this automatically?	No. The cron pass should not execute setup. If Ananth wants a hands-on trial, make it an explicit project and choose normal installer vs source build.
Useful as a task backend?	Maybe for human-facing knowledge management, but not obviously ideal as an agent-controlled operational store. Mission Control currently benefits from file/JSON determinism, CLI transactions, generated HTML, and git history.
Useful as design reference?	Yes. Study custom types, block editor primitives, graph/dataview surfaces, local-first sync boundaries, and object relationship UX.
Useful as code reference?	Yes for Electron/React/MobX architecture, graph worker rendering, and desktop packaging; less useful for directly copying backend logic because key middleware lives in `anytype-heart`.
Suggested next experiment	If Ananth cares, create a focused comparison: “Anytype as Mission Control substrate vs current Notice Board v3 architecture” using criteria: capture speed, API/CLI control, local-first guarantees, renderer flexibility, agent automation, sync/recovery, and privacy.

Best consumption path

Skim README Quick Start and Development Workflow for build/runtime shape.
Read CLAUDE.md architecture sections: Electron main, React frontend, MobX stores, gRPC layer, graph rendering.
Use GitHub tree search around src/ts/component/page/main/graph.tsx, src/ts/component/block/dataview/, and src/ts/lib/api/ if researching specific UI patterns.
Only build locally if the question is hands-on product feel, packaging, or API integration. For substrate evaluation, a source/read-only architecture pass is enough first.