Prosjektgjennomgang · eget produkt
InboxIntel
Under utviklingEt egendriftet verktøy for innboks-intelligens og opprydding — semantisk søk, AI-sammendrag og innboks-helse over e-posten din.
TL;DR
- Hva
- Innboks-intelligens: delt visning, semantisk søk, AI-sammendrag, innboks-helse og trygg opprydding.
- Hvorfor
- For å øve på Clean Architecture skikkelig, gjøre søk nyttig og destruktive operasjoner trygge fra bunnen.
- Stack
- .NET 10 · PostgreSQL + pgvector · React · Ollama · Docker · Clean Architecture.
- Rolle
- Eneste arkitekt og utvikler, fra ende til ende.
Problem og kontekst
En travel innboks er vanskelig å søke i og farlig å rydde i — nøkkelordsøk bommer på det du mente, og ett feil massefilter sletter ting du ikke får tilbake. Jeg bygde InboxIntel for å gjøre en innboks faktisk søkbar (på mening, ikke bare ord), forståelig med ett blikk, og trygg å rydde i — alt egendriftet, med en ryddig og testbar backend.
Arkitektur
En React-app over et ASP.NET Core-API bygget som Clean Architecture — avhengighetsregelen peker innover (Api → Infrastructure → Application → Domain), og kontrollerne har ingen forretningslogikk. En bakgrunnstjeneste synkroniserer Gmail inn i PostgreSQL; en lokal Ollama-modell lager embeddings (lagret med pgvector) og sammendrag, som driver hybrid semantisk + fulltekst-søk.
- Lesing: en fast liste ved siden av en justerbar rute med AI-sammendrag — sorter uten å åpne en ny fane.
- Søk: semantisk (pgvector) + fulltekst, med treff-forklaring og relevans-score.
- Analyse: en innboks-helsekarakter, e-post per kategori, 90-dagers volumtrend og toppavsendere.
- Opprydding: forhåndsvis-så-bekreft på hver destruktive handling; AI-en er kun rådgivende.
Viktige valg og avveininger
-
01 Lokale Ollama-embeddings + pgvector for semantisk søk.
alt: Et hostet embeddings-API og en egen vektordatabase.
E-post er privat, så embeddings blir på min egen maskin og ligger rett ved siden av dataene i Postgres via pgvector — én datalagring, ingen tredjepart, ingen kostnad per kall. Avveiningen er å drifte modellen selv.
-
02 Kryptere OAuth-refresh-tokens i ro og aldri logge dem.
alt: Lagre dem som vanlige kolonner.
Refresh-tokens er langlevde nøkler til noens innboks. De krypteres med ASP.NET Core Data Protection API (AES), med nøkler lagret på et montert volum — det viktigste sikkerhetsvalget i appen.
-
03 Alle destruktive handlinger er forhåndsvis-så-bekreft.
alt: Slette umiddelbart ved forespørsel.
All opprydding og avmelding krever en server-side forhåndsvisning og et eksplisitt Confirmed-flagg. AI-laget er kun rådgivende og kan aldri utløse en sletting.
Sikkerhet og drift
- Google-OAuth-beskyttet; Gmail-scopes er kun lese/endre — send-scope blir aldri etterspurt.
- Embeddings og sammendrag lages lokalt (Ollama); e-post forlater aldri maskinen til en tredjepartsmodell.
- Polly retry/backoff mot Gmails rategrenser; strukturert Serilog-logging som aldri lagrer tokens.
- Clean Architecture holder lagene testbare; integrasjonstester starter API-verten og sjekker autorisasjon.
Skjermbilder
Status og veien videre
Under aktiv utvikling. Søk, sammendrag og analyse fungerer ende til ende; neste steg er å justere tersklene for semantisk gjenfinning, utvide integrasjonstestene, og jobbe mot koblinger utover Gmail slik at det blir et virkelig universelt innboks-verktøy.