Synapse

Thesis

A tool for turning an unstructured social graph into a queryable knowledge base. The portfolio pitch is semantic search over a personal network — "who do I know that's built fintech products?" — with embedding-based retrieval, composite scoring, and privacy-first local query parsing.

⚠️ Source tension

The portfolio narrative and the public repo describe different products under the same name:

	Portfolio (`/projects/synapse`)	Repo (`xaid-vfx/synapse`, live at `synapse-orqys.vercel.app`)
Domain	Personal contact network	Twitter (X) followers
Ingest	Multi-source contacts, normalized	Paginated follower fetch via RapidAPI
AI	OpenAI embeddings + Ollama query parsing + composite scoring	None in current shipped form (streaming analysis is roadmap)
Frontend	Next.js, search-first	React + Vite, grid of follower cards

Likely explanations (open question): (a) portfolio is aspirational for where Synapse is headed; (b) the repo is an early wedge — using follower networks as the first real dataset — and the contact-network version is the generalization; (c) name collision between two builds. The repo's vercel domain (synapse-orqys) suggests it sits under the Orqys umbrella.

Status

shipped (repo is live; portfolio marks as Live). The tension above means the wiki may need to split this into two project pages if the answer to the open question is "these are different products."

Stack

Repo (current): React + Vite + Tailwind frontend, Express backend, Twitter OAuth 2.0 PKCE, RapidAPI twitter283, SSE streaming for paginated follower delivery.
Portfolio (pitched/planned): Next.js frontend, OpenAI embeddings, Ollama local query parsing, Rapid API for enrichment, composite scoring combining semantic similarity + interaction recency + relationship strength.

Key decisions

Composite scoring over pure cosine (portfolio): naive embedding similarity returns too many false positives; layering relationship/recency signals dramatically improves result quality.
Local Ollama query parsing before retrieval (portfolio): extract intent and constraints first to prevent "everything is similar" failure mode.
SSE over request-response (repo): follower fetch can return thousands of items across dozens of API pages; streaming each batch as it arrives gives a responsive UI instead of a long spinner.
Server-side pagination loop (repo): hide RapidAPI's cursor protocol from the frontend; emit uniform followers events.

Learnings

Cold start: a name + email is not enough signal to build a useful embedding. Enrichment from public data is a prerequisite, not a nice-to-have.
Privacy constraints drive architecture: local parsing of queries before hitting cloud embeddings is a data-minimization move.

Outcomes

Follower-analysis version: live and usable for accounts up to ~2k followers (safety cap of 100 pages at 20/page). Roadmap: MongoDB persistence, background job queue for 100k+ accounts, per-follower tweet fetching, engagement scoring.
Contact-network version (portfolio narrative): described as an active intelligence layer surfacing connections that would otherwise require manual scanning.

Open questions

Biggest: are these one project or two? Needs user to confirm. If two, split into synapse-followers (repo) and synapse-network (portfolio narrative) in a future lint pass.
If one project: what's the ingest pipeline that turns follower data into the "contacts-with-embeddings" model?
How is "relationship strength" actually computed when interaction data is sparse?