# LLM-Wiki Second Brain Brief

Date: 2026-06-16

## Working Name

FollowBrain

## One-Line Mission

Build a personal `llm-wiki` second brain for each user: a living, AI-maintained knowledge base whose life events, memory rights, and access grants are user-controlled on-chain while private content stays encrypted.

## Core Thesis

The product is not "abstraction." The product is a user-owned second brain.

Every person should have a private `llm-wiki`: raw sources flow in, an LLM compiles them into structured wiki pages, and that wiki becomes the user's durable context layer. Their life should live on-chain as owned commitments, permissions, provenance, and rights, not as exposed plaintext. It should follow the user across apps only when the user grants access and only where each app/platform allows integrations, APIs, exports, browser extensions, or local capture.

Abstraction is implementation detail: app connectors, agent harnesses, storage backends, chains, and compute providers should be swappable so the user's brain survives platform churn.

Important correction: "life lives on-chain" should mean "ownership, consent, provenance, access rights, revocation, and encrypted-data commitments live on-chain," not raw private memories. Full plaintext life data on public chains is permanent exposure.

## Product Vision

FollowBrain is a personal memory layer for AI plus a chain-native rights ledger. It watches approved inputs, compiles them into a local/private wiki, anchors encrypted memory commitments on-chain, and lets the user grant/revoke who can access which slices of their life data.

The user gets:

- A private `raw/` archive of source material.
- An AI-maintained `wiki/` of concepts, summaries, people, projects, decisions, timelines, backlinks, and open loops.
- App-specific permission controls: what can be read, written, remembered, forgotten, or shared.
- Pseudonymous continuity across apps where needed.
- Encrypted storage with chain-backed commitments for ownership, portability, provenance, auditability, and programmable access rights.

The end state is a second brain that follows the user without becoming platform-owned surveillance memory.

FollowBrain also becomes the foundation for personal agents. Each user can run an agent over their own private wiki. Agents can coordinate with other users' agents by exchanging only the minimum facts required for a task, not raw private context.

Example:

> "Schedule coffee with Sam when we are both available."

The user's agent and Sam's agent can negotiate compatible slots without exposing full calendars. Each side can reveal only availability proofs, constraints, preferred windows, or a final accepted time. The agents complete the task while preserving privacy.

## Ownership Model

No one owns the user's raw life data by default. The user owns root control. Other people, apps, agents, DAOs, companies, researchers, or services can receive scoped rights.

Rights are explicit:

- `read`: can decrypt approved memories/pages.
- `write`: can add sources or proposed wiki updates.
- `derive`: can compute summaries/embeddings/insights without receiving raw data.
- `share`: can pass approved data to another party.
- `commercialize`: can use approved data for paid products/training/research.
- `expire`: access ends at a time/block.
- `revoke`: user can remove future access.
- `audit`: user can inspect who accessed what.
- `negotiate`: can answer limited questions or coordinate tasks without exposing raw data.

On-chain records should store:

- encrypted-memory content hashes,
- owner/controller identity,
- permission grants,
- revocations,
- provenance receipts,
- payment/royalty terms when data is licensed,
- attestations that approved compute touched approved data.

On-chain records should not store:

- plaintext memories,
- raw documents,
- private chat logs,
- location trails,
- health/financial details,
- secrets,
- anything the user may need erased.

## Target User

Initial user:

- Builders, researchers, founders, traders, and operators drowning in fragmented context.
- People who use many apps but want one memory layer.
- Privacy-sensitive users who distrust centralized assistant memory.
- Crypto-native users are good early adopters, but not the whole market.

Later user:

- Professionals who need personal AI memory across tools.
- DAOs and teams that need private autonomous delegates.
- Consumer users who want portable AI identity and memory.

## Problem

Today, AI assistants have six broken defaults:

1. Memory belongs to platform providers.
2. Agent continuity dies when app sessions, API keys, or servers disappear.
3. Context is scattered across notes, chats, browser history, email, docs, calendars, wallets, repos, and SaaS tools.
4. Identity is either public wallet leakage or centralized account custody.
5. App integrations are inconsistent: some apps allow APIs/exports, some allow browser capture, some allow nothing.
6. Agent frameworks are fragmented; each harness stores tools, memory, and permissions differently.

For a second brain, this is fatal. Personal memory is the product. If memory is centralized, unportable, or visible to operators, the user does not own the second brain.

## Proposed Solution

Create a permissioned personal `llm-wiki`:

1. **LLM-wiki memory layer**
   - `raw/` holds approved source captures.
   - `wiki/` holds AI-written Markdown pages.
   - Pages include citations/backlinks to raw source files.
   - Wiki updates incrementally as new context arrives.
   - The wiki becomes the context layer agents and apps can query.

2. **App connector layer**
   - Each connector declares what it can legally/technically access.
   - Access modes: API, export/import, browser extension, local file watcher, webhook, manual paste, MCP server.
   - No connector bypasses app permissions or user consent.
   - Unsupported apps get manual import first.

3. **Permission layer**
   - User decides per app:
     - read from brain,
     - write to brain,
     - remember conversations,
     - forget specific data,
     - share only specific wiki pages/tags,
     - use pseudonymous identity.
   - Default is deny.
   - App can only receive scoped context.

4. **Agent identity layer**
   - User controls root key.
   - Agent uses delegated keys/session keys.
   - Public identity can rotate or use pairwise pseudonyms.
   - Chain sees capability proofs, not full user identity.

5. **Encrypted storage layer**
   - Memory chunks encrypted client-side or inside trusted execution.
   - Storage can be IPFS/Filecoin/Walrus/Arweave-like blob storage.
   - Chain stores content commitments, ownership/controller state, permissions, indexes, and revocation state.
   - Only user or approved agent execution context can decrypt.

6. **On-chain rights layer**
   - Smart contracts record who controls each memory block/wiki page.
   - Users grant scoped rights by app, agent, person, org, or data buyer.
   - Rights can expire, revoke, or require payment.
   - Contract can emit portable receipts for "this data exists and belongs to this controller" without revealing the data.

7. **Compute layer**
   - Jobs run on decentralized or commodity compute.
   - Runtime supports confidential compute where available.
   - Non-sensitive tasks can use cheaper public nodes.
   - Sensitive tasks require TEE/FHE/MPC path later.

8. **Harness adapter layer**
   - Standard interface: `load_memory`, `run_task`, `request_tool`, `write_memory`, `emit_attestation`.
   - Adapter wraps ElizaOS, Olas, LangGraph, custom Python/TypeScript agents.
   - Goal: agent framework swap without memory migration.

9. **Policy and payment layer**
   - Smart contracts enforce compute budgets, agent permissions, access revocation, staking/slashing where useful.
   - Agent cannot spend or reveal beyond delegated capabilities.

10. **Private agent-to-agent coordination**
   - Personal agents can negotiate tasks with each other.
   - They exchange scoped claims, proofs, or derived answers.
   - They do not exchange full underlying private records.
   - Common examples: scheduling, shared travel planning, group purchases, intros, collaborative work, health/fitness accountability, family logistics.
   - Each coordination flow has a disclosure policy.

## Big App / Company Data Sharing

FollowBrain should invert the current data model.

Today:

- Big apps collect data by default.
- Users get weak controls.
- AI platforms build memory inside their own silo.

FollowBrain:

- User owns private memory.
- Big apps request scoped access.
- User grants only what is useful.
- Grants can expire, revoke, charge fees, or require purpose limits.
- Apps get derived answers when raw data is unnecessary.

Examples:

- Calendar app gets "free after 2pm Tuesday" instead of full calendar.
- Shopping app gets "looking for running shoes under $150" instead of full browsing history.
- Health app gets weekly trend summaries instead of raw logs.
- LLM provider gets a temporary context bundle, not permanent memory ownership.
- Employer tool gets work-project context, not personal life context.

## Architecture Sketch

```text
User wallet/root key
        |
        v
Agent DID / pseudonymous identity
        |
        v
Rights contract ---- Compute market / scheduler
        |                      |
        v                      v
Encrypted memory index    Harness adapter
        |                      |
        v                      v
Decentralized storage <--- Agent runtime
        |
        v
Ownership + access commitments on-chain
```

## Minimum Viable Product

Do not start with full decentralized AI. Too much ceremony.

MVP:

- One local CLI.
- One harness adapter.
- One encrypted memory store.
- One EVM policy contract.
- One decentralized storage target.
- One compute backend abstraction with local runner first.

MVP user story:

1. User creates private second-brain vault.
2. User adds notes/tasks/files.
3. Agent runs recurring job.
4. Agent reads only decryptable memory.
5. Agent writes encrypted summary back.
6. Contract records memory commitment and agent action receipt.

This proves ownership, persistence, portability, and private memory without pretending every part is decentralized on day one.

## Recommended Open Source / Existing Projects

### Agent Harnesses

| Project | Use | Fit |
|---|---|---|
| Olas / Open Autonomy | Decentralized autonomous agent services, operator incentives, on-chain coordination | Best match for "always alive" crypto-native agents |
| ElizaOS | Web3-friendly agent framework with broad integrations | Best quick adapter for social/tool agents |
| LangGraph | Graph-based agent orchestration | Best non-crypto harness adapter |
| Autogen / CrewAI | Multi-agent workflows | Useful later, not first |

Olas docs say Open Autonomy provides CLI tools and base packages to build, deploy, publish, and test AI agents. Its protocol coordinates, secures, and manages software code on public blockchains and can support alternative agent frameworks. Sources: https://stack.olas.network/open-autonomy/ and https://stack.olas.network/protocol/

ElizaOS describes itself as an open-source, extensible platform for building and deploying AI-powered applications with modular architecture, CLI, and web interface. Source: https://github.com/elizaos/eliza

### Distributed Compute

| Project | Use | Fit |
|---|---|---|
| Akash | Decentralized cloud/GPU marketplace | Practical deploy target for agent runners |
| Hyperbolic | GPU/inference API and decentralized AI cloud direction | Good inference backend if API stable |
| 0G Compute | Decentralized GPU marketplace for inference/fine-tuning/training | Watch/use when mature |
| Golem | General decentralized compute | Useful for non-LLM jobs |
| Phala | Confidential compute / TEE network | Strong fit for private agent execution |

0G docs describe a decentralized GPU marketplace for AI inference, fine-tuning, and model training. Source: https://docs.0g.ai/concepts/compute

Hyperbolic claims open-access AI cloud, on-demand GPUs, OpenAI-compatible API, and 200,000+ builders. Source: https://www.hyperbolic.ai/

### Privacy, Identity, Encryption

| Project | Use | Fit |
|---|---|---|
| Lit Protocol | Decentralized keys, access control, programmable signing/decryption | Strong fit for threshold-gated memory access |
| Ceramic DIDs | Decentralized identity/data streams | Good identity model, maybe less runtime-critical |
| W3C DID | Identity standard | Use concepts, avoid heavy spec work at MVP |
| Oasis Sapphire | Confidential EVM | Good if privacy logic must be on-chain |
| Phala / TEE | Private compute | Good for sensitive runtime |
| Nillion / FHE/MPC systems | Private computation | Later-stage, not MVP |

Ceramic docs describe DIDs as identifiers requiring no central authority, with users controlling data and sharing. Source: https://developers.ceramic.network/docs/introduction/did-overview

W3C DID spec defines decentralized identifiers as identifiers controlled by a DID controller and decoupled from centralized registries, identity providers, and certificate authorities. Source: https://www.w3.org/TR/did-1.1/

### Storage / Data

| Project | Use | Fit |
|---|---|---|
| IPFS/Filecoin | Content-addressed storage and persistence | Good default blob layer |
| Walrus | Decentralized blob storage/data availability | Strong for large encrypted memory blobs |
| Tableland | Web3-native SQLite-like relational database | Good for public metadata/indexes, not private raw memory |
| Arweave | Permanent storage | Useful for commitments, public docs, immutable agent receipts |

Tableland describes itself as open source, permissionless cloud database built on SQLite for tamperproof data. Source: https://tableland.xyz/

Walrus docs say blobs are public by default and encryption/access control must be applied before upload; it suggests Seal for on-chain access control. Source: https://docs.wal.app/docs/data-security

## Market Opportunity

This sits at the intersection of five markets:

1. AI agents.
2. Personal AI assistants / second brains.
3. Decentralized AI.
4. Privacy-preserving AI / confidential compute.
5. Blockchain AI infrastructure.

Market signals:

- MarketsandMarkets projects AI agents from USD 7.84B in 2025 to USD 52.62B by 2030, 46.3% CAGR. Source: https://www.marketsandmarkets.com/Market-Reports/ai-agents-market-15761548.html
- Fortune Business Insights projects agentic AI at USD 9.14B in 2026 and USD 139.19B by 2034, 40.50% CAGR. Source: https://www.fortunebusinessinsights.com/agentic-ai-market-114233
- Market Research Future projects intelligent personal assistants from USD 16.58B in 2025 to USD 268.26B by 2035, 32.1% CAGR. Source: https://www.marketresearchfuture.com/reports/intelligent-personal-assistant-market-1116
- Fortune Business Insights projects blockchain AI from USD 891.12M in 2025 to USD 7.53B by 2034, 26.76% CAGR. Source: https://www.fortunebusinessinsights.com/blockchain-ai-artificial-intelligence-market-104588
- Mordor Intelligence projects confidential computing from USD 15.15B in 2026 to USD 172.95B by 2031, 62.74% CAGR. Source: https://www.mordorintelligence.com/industry-reports/confidential-computing-market
- Precedence Research projects privacy-preserving AI from USD 5.32B in 2026 to USD 39.93B by 2035, 25.10% CAGR. Source: https://www.precedenceresearch.com/privacy-preserving-ai-market

Market read: raw "AI agent" is crowded. "Private, portable, chain-coordinated agent memory" is narrower but sharper. It avoids competing head-on with OpenAI, Google, Apple, Microsoft, Anthropic, and enterprise agent platforms. It sells sovereignty, continuity, and privacy to users who already pay for wallets, infra, and automation.

## Competitive Landscape

### Centralized AI Memory

Examples: ChatGPT memory, Claude Projects, Gemini/Google ecosystem, Microsoft Copilot, Apple Intelligence, Notion AI.

Strength: UX, distribution, model quality.

Weakness: platform-owned memory, limited portability, trust/custody issue.

### Crypto Agent Frameworks

Examples: Olas, ElizaOS, Coinbase AgentKit-style stacks, Hyperbolic AgentKit.

Strength: agent tooling and wallet/blockchain integration.

Weakness: usually agent-first, not private second-brain memory-first.

### Decentralized Storage / Identity

Examples: Ceramic, IPFS/Filecoin, Arweave, Walrus, Tableland.

Strength: data ownership primitives.

Weakness: no polished agent runtime or second-brain UX by default.

### Privacy Compute

Examples: Phala, Oasis, Lit, Nillion, FHE/MPC/TEE projects.

Strength: privacy primitives.

Weakness: developer complexity; hard UX; scattered app layer.

## Differentiation

FollowBrain should not be "another agent framework" or "another notes app."

It should be:

- LLM-wiki-first: source material becomes durable pages, not ephemeral chat history.
- App-following: context appears where user works, depending on app permissions and connector support.
- Permission-scoped: every app gets only allowed pages/tags/facts/actions.
- Local-first: useful before chain, marketplace, or decentralized compute.
- Privacy-preserving by default.
- User-owned and pseudonymous.
- Portable across models, apps, and agent harnesses.

The strongest claim:

> Your second brain follows you across apps, but each app only sees what you allow.

## Business Model

Best early path:

1. Personal app: local/private `llm-wiki` vault.
2. Browser extension: capture/read context across web apps where allowed.
3. Connectors: Gmail, Calendar, Slack/Discord, GitHub, Notion/Docs, wallets, file systems.
4. Pro sync: encrypted multi-device vault.
5. Team/enterprise: private organizational wiki brains with app-level controls.
6. Protocol layer later: chain commitments, decentralized storage, compute routing.

Avoid token-first launch. Token before usage attracts speculation and weakens product clarity.

Possible revenue:

- SaaS: $10-30/month personal vault.
- Pro: $50-200/month for heavy users, founders, researchers, operators.
- Team: per-seat shared/permissioned wiki brains.
- Usage: optional compute/inference routing margin.
- Enterprise: private memory cloud + compliance controls.
- Protocol: take-rate on marketplace jobs later, only after usage.

## Key Risks

1. **Privacy theater**
   - If operators can see prompts/memory, product promise breaks.
   - Need honest privacy levels: local encryption, TEE, public compute.

2. **On-chain overreach**
   - Storing memory or agent reasoning on-chain is wrong for cost/privacy.
   - Store commitments and policies only.

3. **App permission reality**
   - Some apps will block APIs, exports, automation, or extensions.
   - Product must gracefully degrade to manual import/export.
   - Never bypass user consent or platform rules.

4. **UX complexity**
   - Wallet + DID + encryption + compute marketplace can crush adoption.
   - MVP should feel like a second-brain app plus extension, not infra dashboard.

5. **Framework churn**
   - Agent frameworks change fast.
   - Harness-neutral adapter is correct core bet.

6. **Regulatory/data risk**
   - "Anonymous agent following user around" can sound like evasion or surveillance.
   - Position as user-controlled pseudonymous identity and private memory portability.

## Privacy Model

Use precise language:

- Anonymous to apps by default.
- Pseudonymous across sessions when user wants continuity.
- Linkable only by user-controlled disclosure.
- Encrypted at rest always.
- Decrypted only on user device or approved confidential runtime.
- Chain sees commitments, not raw memory.
- App access is scoped by explicit user grants.
- Unsupported apps do not get hidden scraping as default.

"Block encryption" should become:

- Chunked content encryption for memory blocks.
- Per-block symmetric keys.
- Key wrapping via user root key or threshold access network.
- Merkle tree / content hash commitments.
- Optional rolling pseudonymous identifiers per app/context.

## Technical Principles

- Chain for coordination, not cognition.
- Apps for capture and action, wiki for durable memory.
- Memory encrypted before storage.
- Connectors are permissions-aware plugins.
- Compute and harnesses are swappable.
- Wiki schema is core.
- Local-first path must work without token or marketplace.
- One policy model across apps and harnesses.
- No custom crypto in MVP.

## Proposed Repo Shape

```text
followbrain/
  docs/
    brief.md
    architecture.md
    market.md
  packages/
    core/              # llm-wiki + permission interfaces
    connectors/        # app connectors
    extension/         # browser extension
    runner-local/      # local wiki compiler
  contracts/
    MemoryRegistry.sol
    AgentPolicy.sol
  examples/
    desktop-vault/
```

Do not create all this yet unless building. Brief first keeps scope clean.

## MVP Build Recommendation

Start with:

- TypeScript monorepo.
- Local file-backed `raw/` and `wiki/` folders.
- Markdown wiki pages, viewable in Obsidian or built-in simple UI.
- Browser extension or manual importer first.
- Local encryption after import pipeline works.
- Minimal chain registry from day one: commitments + rights only, no plaintext.

Lazy-but-correct path:

1. Define vault shape: `raw/`, `wiki/`, `index.json`, `permissions.json`.
2. Import one source type: manual text/Markdown.
3. Compile wiki pages with citations/backlinks.
4. Query wiki.
5. Hash encrypted memory/wiki blocks.
6. Register commitments and access grants on local/testnet contract.
7. Add browser extension capture.
8. Add app permission scopes.
9. Add stronger encryption/key management.

Only after that:

- App-specific connectors.
- Multi-device sync.
- Remote decentralized storage.
- Compute marketplace.
- DID rotation.
- TEE/private compute.

## Near-Term Roadmap

### Phase 0: Research and Design

- Finalize mission.
- Pick first two apps/sources.
- Write permission model.
- Define wiki page schema.
- Define raw source citation format.
- Define on-chain rights schema.

### Phase 1: Local Proof

- CLI creates vault.
- CLI imports notes/files.
- LLM compiles `wiki/`.
- User asks questions against wiki.
- Wiki updates incrementally.
- Contract records encrypted block commitments and rights.

### Phase 2: App-Following Proof

- Browser extension captures approved pages/chats.
- Extension injects scoped context into approved web app fields or side panel.
- `permissions.json` controls read/write per app.

### Phase 3: Privacy

- Encrypt local vault.
- Add forget/delete flow.
- Add per-app pseudonymous profile.

### Phase 4: Portability

- Add Obsidian export/import.
- Add MCP server so agents can query scoped wiki.
- Add second harness/LLM provider.

### Phase 5: Decentralized/Chain Layer

- Store encrypted blobs in IPFS/Filecoin/Walrus.
- Keep chain ownership and rights commitments.
- Add key revocation/access policy.
- Add compute attestations only if useful.

## Sharpest Initial Wedge

Build "LLM-wiki that follows you across apps" before "decentralized autonomous agent network."

Tagline:

> Your private AI wiki, available wherever you work.

Why this wedge:

- Pain is clear.
- It avoids full decentralized compute dependency.
- It can plug into existing app workflows.
- It has privacy differentiation.
- It can become protocol later.

## Open Questions

1. Which first apps matter most: browser, Gmail, Slack/Discord, GitHub, Notion/Docs, calendar, wallet?
2. Should first demo be local desktop, browser extension, or CLI + Obsidian?
3. What does "follow them" mean first: capture context, inject context, remember actions, or maintain identity?
4. Is anonymity requirement privacy-driven, or cross-app pseudonymous continuity?
5. What is "cchain" exactly: Avalanche C-Chain, custom chain, or generic chain?
6. Should data rights support monetization/royalties from day one, or only read/write/revoke?

## Recommended Next Step

Write `docs/architecture.md` with:

- vault schema,
- wiki page schema,
- connector permission model,
- trust model,
- first implementation stack.

Then build tiny proof. No token. No marketplace. Chain from day one only for encrypted commitments and rights grants.