Van inbox naar workspace: waarom ik Corrilo bouw

Een inbox vertelt je wat er is binnengekomen. Maar niet automatisch wat een bericht betekent, waar het bij hoort of wanneer je er ruimte voor hebt.

Dat verschil is de aanleiding voor Corrilo: een developer-friendly mailclient waarin gewone mail, agenda’s, planning en testmail niet als losse onderdelen bestaan, maar samen één werkruimte vormen.

Corrilo bestaat nog niet als afgeronde applicatie. De visie en architectuurrichting staan er wel. In dit eerste artikel leg ik uit welk probleem ik wil oplossen en hoe ik de technische basis voor me zie.

Waarom nog een mailclient?

Ik wil niet simpelweg Gmail of Outlook opnieuw bouwen. Beide zijn sterke producten, maar ze zijn in de kern georganiseerd rond een account, inbox, folder en bericht.

In mijn dagelijkse werk is een e-mail zelden alleen een bericht. Een mail kan horen bij:

• een klant of organisatie;
• een project;
• een afspraak;
• een deadline;
• een taak of follow-up;
• een document of beslissing.

Die relaties bestaan nu vooral in mijn hoofd of worden handmatig verdeeld over een agenda, takenlijst en projecttool. De mailclient weet dat de informatie er is, maar behandelt haar nauwelijks als structuur.

Mijn uitgangspunt is daarom anders: wat als een mailclient niet begint bij folders, maar bij context?

Eén inbox boven Gmail, Outlook en IMAP

De eerste productbelofte is een unified inbox. Je moet een persoonlijke Gmail, een zakelijke Microsoft 365-mailbox en een generiek IMAP-account kunnen koppelen zonder drie afzonderlijke werelden te beheren.

Dat betekent niet dat de verschillen tussen providers verdwijnen. Gmail-labels werken anders dan Outlook-folders en IMAP kent weer andere mogelijkheden. De applicatie moet die verschillen eerlijk bewaren, maar ze vertalen naar een gezamenlijk intern model voor onder andere:

• accounts en mailboxen;
• messages en threads;
• afzenders en ontvangers;
• labels en folders;
• attachments;
• synchronisatiestatus.

De gebruiker krijgt zo één rustige workspace, terwijl de techniek de nuances per provider blijft respecteren.

Mail en agenda horen bij elkaar

Een groot deel van planning begint in e-mail. Iemand vraagt of dinsdagmiddag uitkomt. Een factuur moet voor vrijdag worden goedgekeurd. Een contract loopt volgende maand af.

Een gewone mailclient laat die tekst zien. Deze workspace moet ook de relevante agenda’s en planning ernaast kunnen plaatsen.

Bij een voorstel als “kunnen we dit dinsdagmiddag bespreken?” wil ik uiteindelijk direct kunnen zien:

• welke gekoppelde agenda’s relevant zijn;
• wanneer er ruimte is;
• bij welk contact en project het gesprek hoort;
• welke vervolgstap na het antwoord nodig is.

De applicatie mag daarbij voorstellen doen, maar de gebruiker houdt controle. Automatisering moet inzicht geven en werk verminderen, niet onzichtbaar beslissingen nemen.

Structured entities in plaats van alleen vrije tekst

De kern van het domein bestaat uit expliciete entities:

Message
Thread
Contact
Organization
Project
Task
CalendarEvent
Attachment
Account
Mailbox
Label
Reminder

Een bericht kan vervolgens relaties krijgen met meerdere van die entities. Een contractmail hoort bijvoorbeeld bij een organisatie en project, bevat een attachment, levert een taak op en noemt een deadline.

Dat maakt nieuwe views mogelijk. Niet alleen “alle ongelezen mail”, maar ook:

• alles wat vandaag aandacht nodig heeft;
• alle communicatie en afspraken rond één project;
• openstaande follow-ups per contact;
• deadlines die uit berichten en agenda’s samenkomen.

De mail blijft de bron. De structuur maakt de inhoud bruikbaar.

Een developer/test SMTP inbox in dezelfde workspace

Naast dagelijkse communicatie wil ik een developer-inbox bouwen. Tijdens het ontwikkelen van een applicatie wil je registratie-, reset-, factuur- en notificatiemails kunnen testen zonder ze per ongeluk naar echte ontvangers te sturen.

Een lokale SMTP catcher vangt die berichten veilig af. In de workspace moet een developer vervolgens kunnen inspecteren:

• de HTML- en tekstversie;
• headers en ontvangers;
• attachments;
• links en basisinhoud;
• de ruwe bron van het bericht.

Later kan daar een API bij komen waarmee geautomatiseerde tests controleren of een bericht is verzonden en de verwachte inhoud bevat.

Deze functie lijkt op het eerste gezicht een apart product. Voor mij past zij juist bij dezelfde kern: mail betrouwbaar ontvangen, normaliseren, structureren en inzichtelijk maken.

Provider-agnostic vanaf de kern

De grootste architectuurkeuze is dat Gmail, Microsoft en IMAP niet het domein mogen bepalen.

Ik wil werken met adapters:

Gmail API ─────────┐
Microsoft Graph ──┼──> Provider adapters ──> Application ──> Domain
IMAP / SMTP ──────┤
Calendar APIs ────┘

Iedere adapter vertaalt de mogelijkheden en gegevens van een provider naar het interne model. De domeinlaag weet wat een message, thread, task of calendar event is, maar niet hoe Microsoft Graph een response structureert.

Dat levert extra werk op aan het begin. Daar staat tegenover dat synchronisatie, planning en projectrelaties later niet aan één externe API vastzitten. Ook wordt het eenvoudiger om providers gecontroleerd te testen en stapsgewijs toe te voegen.

Waarom PHP, Laravel en NativePHP?

Corrilo wordt een Laravel-applicatie die met NativePHP als echte desktopapp wordt uitgebracht voor macOS, Windows en Linux. Daarmee kan ik de bekende PHP- en Laravel-stack gebruiken, maar het product wel installeren en gebruiken als lokale applicatie.

De provider-onafhankelijke modellen en regels rond messages, threads, contacten, projecten, taken en agenda-events blijven gewone PHP-modules binnen de applicatie. Laravel verzorgt onder andere Artisan-commando’s, queues, events, scheduling, authenticatie en integraties. NativePHP vormt de brug naar het besturingssysteem en de distributie als desktopapp.

De eerste focus ligt op desktop. Later wil ik dezelfde Laravel- en PHP-basis met NativePHP Mobile gebruiken voor iOS en Android. Zo hoeven het domein, de provider-adapters en een groot deel van de synchronisatielogica niet opnieuw te worden ontworpen.

Lokaal ligt SQLite voor de hand, zodat mail en planning ook offline beschikbaar zijn. PostgreSQL en Redis blijven opties voor een latere synchronisatie- en accountbackend. Voor de externe laag verwacht ik te werken met de Gmail API, Microsoft Graph, IMAP, SMTP en kalenderstandaarden.

Waarom open source?

Ik wil de kern van Corrilo als open source ontwikkelen. Dat past bij het developer-first karakter van het product, maar ook bij de manier waarop ik dit project wil bouwen: beslissingen zichtbaar maken, feedback vroeg ophalen en anderen de mogelijkheid geven om het systeem zelf te gebruiken of eraan bij te dragen.

De bedoeling is dat in ieder geval de mail-core, provider-adapters en developer/test SMTP inbox publiek beschikbaar worden. Voordat de repository opengaat, wil ik zorgen voor duidelijke domeingrenzen, tests, lokale installatie-instructies en richtlijnen voor bijdragen en security.

Credentials, tokens en echte mailboxdata horen vanzelfsprekend nooit in de repository. Providerconfiguratie moet veilig via de omgeving verlopen en voorbeelden gebruiken die geen persoonlijke gegevens bevatten.

Voor de licentie kijk ik voorlopig naar MIT en Apache 2.0. Ik wil die keuze pas definitief maken nadat ik goed heb bekeken wat zij betekenen voor bijdragen, hergebruik en een mogelijke managed versie in de toekomst.

Open source betekent voor mij hier niet alleen dat de code leesbaar is. De roadmap, architectuurbesluiten en bekende beperkingen moeten eveneens openbaar en begrijpelijk zijn.

Klein beginnen

De visie is breed, maar de eerste versie wordt dat niet.

De eerste verticale slice is bewust klein:

1. een testbericht via SMTP ontvangen;
2. het bericht parsen en valideren;
3. de kerngegevens en ruwe bron opslaan;
4. HTML, tekst, headers en attachments tonen;
5. deze flow automatisch testen.

Daarna volgen pas de echte providers, unified inbox, kalenderkoppelingen en structured relationships. Iedere fase moet op zichzelf bruikbaar en testbaar zijn.

Wat volgt

Dit artikel vormt het begin van een technische serie over de ontwikkeling van Corrilo. De geplande onderwerpen zijn:

• Part 1 — het maildomein ontwerpen;
• Part 2 — een SMTP server en testinbox bouwen in PHP;
• Part 3 — Gmail, Outlook en IMAP synchroniseren;
• Part 4 — threads over providers heen normaliseren;
• Part 5 — mail verbinden met agenda en planning;
• Part 6 — structured relationships en follow-ups;
• daarnaast — de repository, contribution flow en open-source lessen.

Sommige aannames zullen onderweg veranderen. In toekomstige artikelen leg ik uit welke keuzes werkten, welke niet en waarom.

De levende visie, roadmap en actuele status staan op de projectpagina van Corrilo.