Local Embedding and Local Vector Store for Indexing

[PaperBoardOfficial]

What specific problem does this solve?

Roo Code is based on the spirit on open source, zero cost, and privacy. Code Indexing has been introduced recently but it uses Qdrant as vector store and OpenAI etc. for embedding. I think it would better if we integrate a local vector store and local embedder. One can use qdrant locally via docker but that is an extra step and requires setup.

I suggest these libraries:

• Vector Store
  I think we should use a file based vector store (something like what sqlite is for database).
  @mastra/libsql
  langchain/faiss (NB: This is typescript version of python library that is used in a lot of open source projects.)

• Embedder
  @mastra/fastembed
  langchain/all-MiniLM-L6-v2 (NB: This is typescript version of python library that is used in a lot of open source projects.)

I am open to discussion about more local embedders and vector stores but I think the criteria of selection should be simplicity and less impact on resources and efficiency. I think for now free non-local emedding models like Gemini are also good. So we can leave the local embedder implementation for future. But for vector store, I think we should use a local one which doesn't run in docker container.
@daniel-lxs Please share your thoughts on this.

Additional context (optional)

No response

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

No response

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

No response

Technical considerations (REQUIRED if contributing, optional otherwise)

No response

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

No response

[daniel-lxs]

Hey @PaperBoardOfficial, I actually implemented the codebase indexing and originally tried to do exactly what you're proposing. It turned out to be a lot trickier than expected.

Here’s what I ran into:

• The .vsix file ballooned from ~10MB to ~150MB
• We had to customize the build process for each OS because of how the native module and .wasm files had to be copied and bundled
• Resource usage became a problem since the extension runs in a single process. Using child processes to isolate the indexer helped somewhat, but it added a bunch of complexity (e.g. passing paths, loading the modules correctly across platforms, etc.)

At this point we’re not sure how to make this work without significantly increasing Roo Code’s complexity. Definitely open to new ideas though!

[PaperBoardOfficial]

Interesting insights!
I won't argue much on this because you have done great work with code indexing already and I believe you made the right design choices (because the end product is amazing!).

Just for tinkering and learning, I would try getting some local vector store running for myself. If that becomes successful, I'll let you know.

Once again thanks for Roo Code.