Skip to content

Latest commit

 

History

History
122 lines (85 loc) · 7.14 KB

File metadata and controls

122 lines (85 loc) · 7.14 KB

KnowledgeFabric

Borrow a friend's brain. Keep your own.


The Story

Minho has been building a local LLM-Wiki for months — every infra trick, every hard-won config insight, stored as Markdown in his personal repo. One day he hits a wall: a gnarly Kubernetes scheduling problem his own knowledge can't crack.

He messages Byungmin. Byungmin pastes a file. It's out of context, hard to integrate, and already half-stale.

With KnowledgeFabric, Minho instead opens his dashboard and connects to Byungmin's wiki. One click later, Byungmin's k8s/ nodes appear in Minho's editor sidebar — not copied into his repo, not polluting his git history, just there, virtual-mounted like a read-only network drive. Minho reads, synthesizes, writes my-k8s-strategy.md in his own words, linking back to the source. The problem is solved in 20 minutes.

The dashboard shows: "3 problems solved this week using Byungmin's knowledge." Minho sends a thank-you nudge. Byungmin starts sharing more.

That's KnowledgeFabric.


What Is KnowledgeFabric?

KnowledgeFabric is a lightweight bridge that lets you borrow a friend's curated LLM-Wiki knowledge directly into your local environment — without copying files, without polluting your git history, and without asking your friend to change anything about how they work.

Your knowledge stays yours. Theirs stays theirs. The connection is the product.


Core Hypotheses

# Hypothesis Signal to watch
A Personal LLM-Wiki environments will fragment — and demand for knowledge connections will surge "Connect friend" request frequency
B Linking fragmented knowledge via graph is more valuable than raw search External knowledge utilization rate in LLM answers
C "Imbalance warnings" and selective sharing lower the psychological barrier to sharing Share acceptance rate
D Real-time MCP queries beat raw data sync for efficiency and privacy Latency + consistency of local↔remote knowledge
E Auto-ingested data degrades insight quality — curation beats collection Manual node reference rate vs. auto-ingested node reference rate
F Knowledge value is proportional to context, not volume Answer quality + user feedback (thumbs up / edit)

Architecture

┌─────────────────────────────────────────────────────┐
│                     WebApp                          │
│  Dashboard · Share controls · Notify · Graph view   │
└───────────────────┬─────────────────────────────────┘
                    │ OAuth / metadata only
┌───────────────────▼─────────────────────────────────┐
│                    Backend                          │
│  Auth (GitHub OAuth) · Access token mapping         │
│  Raw data never stored — knowledge sovereignty kept │
└───────────────────┬─────────────────────────────────┘
                    │ MCP protocol
┌───────────────────▼─────────────────────────────────┐
│               MCP Bridge                            │
│  Local MCP  — reads your llm-wiki                   │
│  Remote MCP — reads friend's repo as virtual mount  │
│  Exposes: list_shared_nodes · read_shared_node ·    │
│           search_shared_knowledge                   │
└───────────────────┬─────────────────────────────────┘
                    │ onboarding
┌───────────────────▼─────────────────────────────────┐
│                   Skills                            │
│  CLI: install MCP · GitHub OAuth login ·            │
│       auto-register index.md nodes                  │
└─────────────────────────────────────────────────────┘

Knowledge flow: Friend's data lives in their repo. Your MCP fetches it on demand into a virtual shared/ namespace — readable by Obsidian, VS Code, and any local LLM client. No commit. No merge conflict. Disconnect = instant cleanup.


MLP: 3-Hour Sprint

Role assignments

Role Owner Stack Goal
Frontend Next.js + shadcn/ui + Vercel Dashboard UI: friend list, shared node list, reference graph
Backend Supabase (Auth/DB) + GitHub API GitHub OAuth, access token mapping, share/notify API
LLM_Wiki Python + MCP SDK Local index.md parser, remote fetch, shared/ sync daemon

Sprint timeline

Time Frontend Backend LLM_Wiki
0–1h Layout + dashboard skeleton GitHub OAuth + DB setup index.md parser + node structure
1–2h Friend list view + state Share node list API Remote MCP fetch logic
2–3h Imbalance warning UI + graph Notify + share status API shared/ folder sync (read-only)

Demo checklist (4 scenes)

  • Connect — Minho adds Raeyoung as a friend via dashboard URL
  • Share — Raeyoung's index.md appears as shared nodes in Minho's dashboard
  • Reference — Minho clicks a node → file appears in ~/shared/raeyoung/ locally
  • Visualize — Dashboard graph shows minho → raeyoung knowledge edge

Future Milestones

These are intentionally out of scope for the MLP. Parked for later:

  • Confidence scoresUnverified tag on auto-ingested nodes; weighted RAG by trust level
  • Knowledge Lifecycle — periodic cleanup of low-connectivity auto-collected nodes
  • CC License reciprocity — "you borrowed mine, share yours" enforcement in share settings
  • Auto-sync daemon — background polling so shared/ stays fresh without manual trigger
  • Obsidian plugin — native sidebar integration without filesystem sync workaround

Key Design Decisions

No GitHub App. GitHub OAuth + PAT is sufficient for MVP. GitHub App adds installation overhead with no meaningful gain at this scale.

No raw data in backend. The backend stores only auth tokens and metadata. Knowledge sovereignty stays with each user — friends' data is never copied to our servers.

Virtual mount over git clone. Friends' files live in a namespaced shared/{name}/ directory excluded from .gitignore. Your git history stays clean. Disconnecting a friend removes their files instantly.

index.md as the unit of truth. Every llm-wiki includes one by default. Fetching just this file is sufficient to map a friend's knowledge graph — no deep repo crawl needed.