Ask questions across your Markdown notes using a fully local Graph RAG engine. Built for Obsidian vaults, works with any folder of Markdown files. Extracts entity-relation triples from wikilinks & YAML frontmatter, retrieves answers via hybrid search (vector + BM25 + temporal). Multilingual. No cloud. Runs on Ollama.

https://github.com/benmaster82/Kwipu

Hey everyone,

I wanted to share a project I've been working on called Glia. It is a 100% offline, local-first RAG and memory layer designed to connect your AI web chats (Claude, ChatGPT, DeepSeek) with your local developer tools (Claude Code, Cursor, Windsurf) using a unified local database.

I wanted something lightweight that did not require pulling heavy Docker containers or subscribing to third-party memory APIs. I settled on a Node.js + SQLite architecture running sqlite-vec (for 768-dim float32 embeddings) alongside SQLite FTS5 for hybrid search, powered completely by local Ollama instances.

We just launched a live website that outlines the details and demonstrates the features in action:

• Website: https://glia-ai.vercel.app/
• Codebase: https://github.com/Eshaan-Nair/Glia-AI

Technical Stack & Features:

• Hybrid Search Retrieval: SQLite-vec (using nomic-embed-text locally) + FTS5 keyword prefix matching (porter stemmer).
• Surgical Sentence-level Trimming: Chunks are sliced into sentences. When a prompt is intercepted, only the exact matching sentences are pulled out of the vector store instead of the whole paragraph. It cuts LLM prompt bloat by ~90-95% in my benchmarks.
• Knowledge Graph Extraction: An offline task queue uses a local LLM (llama3.1:8b via Ollama) to extract entity triples (subject-relation-object). These are stored in a SQLite facts table (or Neo4j if you run the full Docker compose profile) and fused with the vector retrieval score.
• HyDE (Hypothetical Document Embeddings): Queries are pre-processed to generate a hypothetical answer, which is embedded together with the original query to bridge semantic gaps.
• Concurrency: Running SQLite in WAL (Write-Ahead Logging) mode allows the browser extension dashboard and active MCP sessions to read/write concurrently without locking.
• PII Redaction: Aggressive scrubbing of JWTs, API keys, emails, and IPs in the extension before data is saved.

The extension works on Claude.ai, ChatGPT, DeepSeek, Gemini, Grok, and Mistral. The MCP server runs out of the same backend database for your terminal agent or Cursor.

You can set it up with a single command: npx glia-ai-setup

Glia is completely open-source (MIT). If you like the local-first approach or want to contribute to the SQLite vector pipeline, PRs are very welcome, and a star on GitHub helps the project get discovered!

I would appreciate any feedback on the SQLite hybrid search scaling, the scoring fusion algorithm (RAG pipeline details are in RAG_PIPELINE.md), or local graph extraction performance!

Hi everyone,

I’ve spent the last few months building a custom knowledge graph extraction engine (which I call blAST) designed to map the architectural physics of massive software repositories.

Usually, extracting code into a graph requires an Abstract Syntax Tree (AST). The problem is ASTs are incredibly heavy, strictly monolingual, and fail if a repository doesn't compile. I wanted to map planetary-scale, multi-lingual enterprise systems, so I built a deterministic parser instead. It treats code like text and scans for keyword markers across 50+ languages to build the graph.

Here is how the graph ontology and analytics work:

1. The Ontology

• Nodes: Files, Classes, and Functions.
• Node Properties: 50+ dimensional vectors representing regex keyword hits (e.g., raw memory manipulation, state flux,etc).
• Edges: File (imports/dependencies) and functional execution paths (outbound calls/reachability).

2. Graph Analytics & Network Topology

Once the graph is built, the engine runs network math over the repository to find architectural bottlenecks. I calculate:

• Modularity & Average Path Length to measure encapsulation.
• Articulation Points to find the "God Nodes" (if these fail, the graph shatters).
• Cyclic Loop Density to measure static friction in the architecture.

3. K-Means Clustering on 1.5M Nodes

As all langauges have keywords that roughly mean the same thing, I analyzed 1000 repos of different languages and I took the regex count vectors of 1.59 million file nodes across 50 languages and ran them through an unsupervised K-Means clustering algorithm. The graph converged into 10 distinct architectural "micro-species" (e.g., UI View Layers, Highly Concurrent State Managers, Unshielded Native Core). The clustering algorithm successfully grouped a complex Java service and a defensive Rust file into the same exact node category based purely on their physical edge/property behavior.

4. Graph Traversal Use Cases

I used this graph engine to tear down Google DeepMind's original AlphaFold repo. By traversing the graph, the engine instantly isolated the absolute heaviest bottleneck in the network: a single node (contacts_network.py) running an $O(N^6)$ complexity loop holding up the entire pipeline.

code - https://github.com/squid-protocol/gitgalaxy

example data of google Deepmind's Alphafold - https://squid-protocol.github.io/gitgalaxy/museum-of-code/alphafold_teardown.html

Population data from 100's of repos - https://squid-protocol.github.io/gitgalaxy/03-04-claim-4-comparing-languages/

This is what your codebase actually looks like.

2032 nodes. 2878 edges. 7 relationship types.

Every service. Every dependency. Every API. Every owner. Every connection your team built over years — visualised in one graph.

Most AI coding assistants see none of this.

They see the file you have open.
Maybe the files you paste in.
Nothing else.

So when they generate code, they generate it blind.
No knowledge of what depends on what.
No knowledge of what breaks if you change something.
No knowledge of the relationships your team spent years building.

This is the real problem with AI in enterprise development.
It's not capability. The models are powerful.

It's context. AI operates on a fraction of the knowledge your senior engineers carry in their heads.

Mnemo builds this knowledge graph automatically from your codebase.

Services and their boundaries.
APIs and their consumers.
Dependencies and their blast radius.
Files and their owners.
Decisions and their history.

And then makes all of it available to your AI assistant — automatically, on every session.

No more blind generation.
No more code that compiles but breaks something downstream.
No more AI that doesn't know why things are the way they are.

This is what AI-assisted development should actually look like.

🔗 github.com/Mnemo-mcp/Mnemo

Drop a comment if you've ever had AI break something it didn't know existed.

hey guys so i wrote a database, NornicDB.

https://github.com/orneryd/NornicDB/releases/tag/v1.1.0-preview-1

it got mentioned in research last month. https://arxiv.org/pdf/2604.11364

the researcher actually commended on issue #100 here:

https://github.com/orneryd/NornicDB/issues/100#issuecomment-4296916032

and i’ve released a preview tag for people to play with. 1.1.0-preview. docker images, mac installer, or build it locally.

the idea is to convert memory decay into policy that can be declared in cypher. it started with Ebbinghaus but as the researcher pointed out, is insufficient for agentic memory.

with the policies you can define the decay curve profiles. when you enable memory decay, it sets up policies to match the Ebbinghaus-Roynard model as he describes in the paper. that plus the “canonical graph ledger” bootstrap enables you to move a lot of glue code into the database using the primitives i provide. (cardinality, temporal no-overlap constraints, etc…)

the way it works is a visibility suppression layer in between Cypher and badger. on-access meta is stored in a separate index. there are functions to reveal/decay scoring functions in cypher for debugging queries or bypassing the visibility layer. having the layer there and the meta flushed separately from the data itself maintains negligible performance overhead for enabling it at the data layer.

it’s research backed. I’m writing my own research paper in response to 4 different papers converging on my database implementation.

726 stars and counting. MIT licensed. neo4j and qdrant driver compatible.

enjoy!

edit: clarity on performance overhead. the way i’ve built it and benchmarked it, the performance overhead is within noise tolerances. +/- <1% variance across runs and overhead measures in nanoseconds in tests.