Corrilo

Visie

E-mail bevat veel meer dan berichten. Een gesprek kan tegelijk bij een klant, project, deadline, afspraak en taak horen. Toch behandelen de meeste mailclients ieder bericht vooral als een los item in een inbox.

Corrilo wordt een centrale laag boven mailboxen en agenda’s. De applicatie brengt communicatie, planning en context samen, zodat je niet langer tussen accounts, agenda’s en losse tools hoeft te schakelen om te begrijpen wat er moet gebeuren.

De eerste productvorm wordt een echte desktopapp voor macOS, Windows en Linux. Vanuit dezelfde Laravel- en PHP-basis kan Corrilo later worden uitgebreid naar mobiele apps voor iOS en Android.

Het product krijgt daarnaast een developer-first kant: dezelfde workspace bevat een veilige SMTP-inbox voor testmails, inspectie van headers en attachments, en later een API voor geautomatiseerde tests.

De ambitie is om de kern als open source te ontwikkelen. Zo worden niet alleen het resultaat, maar ook het domeinmodel, de architectuurkeuzes en de voortgang zichtbaar en bespreekbaar.

Probleemstelling

Werk en communicatie zijn verspreid over Gmail, Microsoft 365, IMAP-mailboxen, gedeelde inboxen en verschillende agenda’s. Daardoor ontstaan terugkerende problemen:

• belangrijke context zit opgesloten in één account of thread;
• afspraken en deadlines uit e-mail staan los van de agenda;
• taken en follow-ups worden handmatig overgenomen;
• contacten, organisaties en projecten zijn niet structureel gekoppeld;
• developers gebruiken een aparte tool om testmail te bekijken.

De workspace moet die versnippering oplossen zonder zelf afhankelijk te worden van één provider.

Kernfeatures

Unified inbox

Eén overzicht voor Gmail, Outlook en generieke IMAP-accounts, met behoud van de herkomst van ieder bericht. Threads, labels en zoekresultaten worden genormaliseerd zodat meerdere accounts als één werkruimte aanvoelen.

Kalender en planning

Gekoppelde Google- en Microsoft-agenda’s worden naast e-mail zichtbaar. Een datum, deadline of voorstel als “dinsdagmiddag” kan zo direct in de context van de beschikbare tijd worden beoordeeld.

Structured mail

Berichten worden niet alleen opgeslagen, maar gekoppeld aan betekenisvolle entities:

Message ── Thread ── Contact ── Organization
   │          │          │
   ├── Task   ├── Project
   ├── Event  └── Label
   └── Attachment

Daardoor kan een mail bij een project horen, een taak opleveren, een deadline bevatten en verbonden zijn met een agenda-afspraak — zonder dat die relaties in vrije tekst verdwijnen.

Developer en test SMTP inbox

Een ingebouwde SMTP catcher vangt mail uit lokale en testomgevingen veilig af. Developers kunnen de HTML- en tekstversie, headers, attachments en verzendgegevens inspecteren zonder echte ontvangers te benaderen.

Today en follow-ups

Een dagelijkse view combineert afspraken, belangrijke berichten, openstaande taken en deadlines. De gebruiker ziet niet alleen wat er binnenkwam, maar vooral wat aandacht nodig heeft.

Architectuur

De kern wordt provider-agnostic. Gmail, Microsoft Graph, IMAP/SMTP en kalenderproviders krijgen ieder een adapter rond hetzelfde interne model.

Corrilo wordt gebouwd als Laravel-applicatie en met NativePHP verpakt als native desktopapp. Het domein en de synchronisatielogica blijven gewone, herbruikbare PHP-modules, zodat dezelfde kern later ook in de mobiele NativePHP-app kan worden gebruikt.

Productvormen
├── NativePHP Desktop
│   ├── macOS
│   ├── Windows
│   └── Linux
└── NativePHP Mobile — later
    ├── iOS
    └── Android
        │
        ▼
Laravel application
├── Synchronization
├── Threading
├── Search
├── Planning
└── Automation
        │
        ▼
PHP domain
├── Message / Thread
├── Contact / Organization
├── Project / Task
├── CalendarEvent / Reminder
└── Account / Mailbox
        │
        ▼
Provider adapters
├── Gmail API
├── Microsoft Graph
├── IMAP / SMTP
├── Google Calendar
└── Microsoft Calendar

Deze scheiding houdt provider-specifieke details buiten het domein. Een nieuwe integratie kan worden toegevoegd zonder de logica rond projecten, planning of follow-ups opnieuw te ontwerpen.

Tech stack

• PHP voor het gedeelde domein, mail parsing en de kernregels
• Laravel voor de applicatie, Artisan-commando’s, queues, events, scheduling en integraties
• NativePHP Desktop voor distributie naar macOS, Windows en Linux
• NativePHP Mobile voor een latere uitbreiding naar iOS en Android
• SQLite voor lokale, offline beschikbare mail-, relatie- en planningsdata
• PostgreSQL en Redis voor een eventuele synchronisatie- en accountbackend
• Provider APIs en protocollen: Gmail API, Microsoft Graph, IMAP, SMTP en iCalendar
• Docker voor een reproduceerbare lokale ontwikkelomgeving

De desktopapp is het eerste doel. De technische prioriteit ligt bij een betrouwbare lokale mail-core, offline opslag en heldere grenzen, zodat de mobiele app later dezelfde basis kan hergebruiken.

Open source

De mail-core, provider-adapters en developer/test SMTP inbox zijn bedoeld om publiek beschikbaar te worden. De repository gaat open zodra de eerste verticale slice voldoende duidelijke grenzen, tests en documentatie heeft om bruikbaar te zijn voor anderen.

De open-source basis krijgt in ieder geval:

• een heldere README met lokale installatie en eerste gebruik;
• architectuurbesluiten die uitleggen waarom belangrijke keuzes zijn gemaakt;
• een publieke roadmap, issues en ruimte voor technische discussie;
• contribution- en securityrichtlijnen;
• veilige configuratie waarbij credentials en mailboxdata nooit in de repository thuishoren.

Voor de eerste release wordt een passende permissieve licentie gekozen, waarschijnlijk MIT of Apache 2.0. Die keuze blijft open totdat de gevolgen voor bijdragen, hergebruik en eventuele managed diensten goed zijn afgewogen.

Roadmap

Fase 1 — Mail domain en basis

• domeinmodel voor accounts, mailboxen, messages en threads;
• opslag, parsing en normalisatie van berichten;
• eerste NativePHP-desktopapp voor macOS, Windows en Linux;
• lokale SQLite-opslag;
• eerste CLI- en testflows;
• basisdocumentatie en voorbereiding van de publieke repository.

Fase 2 — Developer inbox

• lokale SMTP catcher;
• veilige testinbox;
• inspectie van HTML, tekst, headers en attachments;
• API-basis voor geautomatiseerde tests.

Fase 3 — Mailproviders

• Gmail-integratie;
• Microsoft 365 via Microsoft Graph;
• generieke IMAP-synchronisatie;
• incrementele sync en foutafhandeling.

Fase 4 — Unified inbox

• genormaliseerde threads over meerdere accounts;
• zoeken, filters, labels en mailboxviews;
• contacten en organisaties herkennen.

Fase 5 — Kalender en planning

• Google en Microsoft Calendar koppelen;
• afspraken, deadlines en beschikbaarheid samenbrengen;
• Today-view en reminders.

Fase 6 — Structured workspace

• relaties tussen mail, projecten, taken en personen;
• follow-ups en automatisering;
• slimme voorstellen met altijd zichtbare gebruikerscontrole.

Fase 7 — Mobile

• Corrilo met NativePHP Mobile naar iOS en Android brengen;
• gedeelde domein- en synchronisatielogica hergebruiken;
• een mobile-first inbox, Today-view en notificaties;
• offline gebruik en veilige synchronisatie tussen apparaten.

Status

In ontwikkeling — concept- en architectuurfase.

De visie, kernentities en gefaseerde roadmap zijn vastgelegd. De eerstvolgende stap is een kleine verticale slice in de NativePHP-desktopapp: een bericht ontvangen, parsen, lokaal opslaan en tonen in de developer inbox.

Corrilo wordt voorbereid als open-source project. Ontwerpbeslissingen, technische afwegingen en geleerde lessen verschijnen in vervolg op het eerste artikel over Corrilo.