Wie MSN Messenger heeft gebruikt, herinnert zich waarschijnlijk het geluid van een binnenkomend bericht. Of de nudge die je scherm liet schudden. MSN voelde persoonlijk maar ook een onderdeel van wie je was. Dat gevoel wilden we terugbrengen, maar dan met de privacy die je vandaag van een messenger mag verwachten.
Zo ontstond Lynn Messenger: een desktopapp met een klassieke en een moderne uitstraling, gebouwd op end-to-end versleuteling. Achter de vertrouwde functies zit een architectuur waarin de client berichten versleutelt en de server ze aflevert zonder de inhoud te kunnen lezen.
In dit artikel laten we zien welke keuzes we maakten en hoe de onderdelen samenwerken.
Het uitgangspunt: de server hoeft je berichten niet te lezen
Bij Lynn worden berichten op het apparaat van de verzender versleuteld. Pas op het apparaat van de ontvanger worden ze weer leesbaar. De server bewaart en verstuurt de versleutelde berichten, maar beschikt niet over de privésleutels waarmee hij de inhoud kan openen.
Die verdeling bepaalt de hele architectuur. De desktopapp verzorgt de versleuteling en de gebruikerservaring. De backend in Rust regelt onder meer accounts, aflevering, online status en de opslag van versleutelde gegevens. PostgreSQL bewaart berichten, Redis helpt bij realtime gebeurtenissen en S3-compatibele objectopslag bevat versleutelde bestanden met een maximum van 30 dagen. Hierna worden ze automatisch verwijderd.
Voor bellen is er een aparte signaling-service. Die helpt gebruikers een verbinding op te zetten. Het gesprek zelf loopt waar mogelijk rechtstreeks en end-to-end versleuteld tussen de deelnemers.
Waarom we Rust kozen voor de backend
De backend van Lynn is geschreven in Rust, met Tokio en Axum voor de asynchrone services. Die keuze past bij software waarin betrouwbaarheid en beveiliging een grote rol spelen.
Rust voorkomt tijdens het compileren veel fouten met geheugenbeheer en gelijktijdige processen. We beperken het gebruik van onveilige code verder met #![forbid(unsafe_code)]. Ook de productieconfiguratie is bewust ingericht: als het proces op een onverwachte fout stuit, stopt het in plaats van door te draaien in een onzekere toestand.
Dat neemt de noodzaak van tests en controles niet weg. Het geeft ons wel een stevige basis voor de services die berichten verwerken.
Versleuteling voor gesprekken van vandaag en morgen
Voor de versleuteling gebruiken we het Signal-protocol als basis. De sleuteluitwisseling combineert klassieke cryptografie met een post-quantum component. Daarmee houden we rekening met het scenario waarin iemand vandaag versleuteld verkeer opslaat om het later met krachtigere computers te proberen te ontsleutelen.
Na het opzetten van een gesprek zorgt de Double Ratchet ervoor dat sleutels blijven veranderen. Daardoor hangt de bescherming van een volledige chatgeschiedenis niet af van één blijvende sleutel.
De belangrijkste regel blijft eenvoudig: een leesbaar bericht en de sleutels om het te openen horen bij de gebruikers, niet op onze server.
Inloggen zonder je wachtwoord te versturen
Ook bij het inloggen wilden we voorkomen dat de server een leesbaar wachtwoord ontvangt. Daarom gebruikt Lynn OPAQUE. Met dit protocol kunnen client en server vaststellen dat iemand het juiste wachtwoord kent, zonder dat wachtwoord zelf over de verbinding te sturen.
De clientkant draait als een Rust-module die naar WebAssembly is gecompileerd. Zo kunnen we dezelfde implementatie in de desktopapp gebruiken en afzonderlijk testen.
Minder zicht op de afzender
De inhoud van berichten versleutelen is één stap. Gegevens over wie met wie communiceert, verdienen ook aandacht. Lynn ondersteunt daarom sealed sender voor berichten waarbij de identiteit van de afzender niet in de gebruikelijke vorm aan de server wordt doorgegeven.
Dat maakt niet alle metadata onzichtbaar. Een server heeft bijvoorbeeld informatie nodig om een bericht af te leveren. We beperken die informatie waar de architectuur dat toelaat.
Bellen draait in een aparte service en werkt P2P
De signaling-service voor WebRTC-gesprekken draait los van de chatservice. Dat helpt om storingen te isoleren: een probleem met bellen hoeft het versturen van berichten niet stil te leggen.
De twee services gebruiken tokens met asymmetrische sleutels. De chatservice kan een token uitgeven met een privésleutel. De signaling-service heeft alleen de publieke sleutel en kan daarmee controleren of het token geldig is. Hij kan zelf geen geldige tokens namens de chatservice maken.
De daadwerkelijke call wordt altijd peer-to-peer opgezet. De server brengt enkel de clients in contact met elkaar om te laten weten dat er een inbound call is. Dit geldt voor zowel audio als video.
Foto’s en bestanden worden vóór het uploaden versleuteld
Een foto, spraakbericht of document wordt op het apparaat van de verzender versleuteld voordat het wordt geüpload. De versleutelde versie gaat rechtstreeks naar de objectopslag via een tijdelijke uploadlink.
De ontvanger krijgt via een end-to-end versleuteld bericht de verwijzing naar het bestand en de sleutel die nodig is om het te openen. De opslaglocatie bevat dus wel de versleutelde bytes, maar niet de sleutel om de oorspronkelijke inhoud te lezen.
Lynn bewaart daarnaast alleen de metadata die nodig is om bestanden te beheren. Verlopen gegevens en afgeleverde berichten kunnen volgens de ingestelde bewaartermijnen worden opgeruimd.
Realtime chat zonder alles op één server te laten draaien
Een messenger moet direct reageren. Berichten verschijnen zodra ze binnenkomen, je ziet wanneer iemand typt en een nudge komt meteen aan. Lynn gebruikt hiervoor WebSockets.
Wanneer gebruikers met verschillende serverprocessen verbonden zijn, verspreidt Redis de gebeurtenissen tussen die processen. PostgreSQL bewaart berichten totdat ze zijn afgeleverd. Zo blijft een bericht beschikbaar als een gebruiker tijdelijk offline is of een proces opnieuw moet starten.
Redis helpt ook bij gedeelde limieten voor verzoeken, bijvoorbeeld rond inloggen en het ophalen van sleutels. Die limieten gelden over de serverprocessen heen.
De techniek moet ook als MSN voelen
Beveiliging vormt de basis, maar de ervaring maakt Lynn herkenbaar. De desktopapp is gebouwd met Electron, React en TypeScript en heeft twee verschijningsvormen: een moderne Lynn-interface en een klassieke skin die verwijst naar Windows Live Messenger*.
In die klassieke weergave krijgt de contactenlijst een eigen venster en opent ieder gesprek apart. Ook de kleine functies zijn terug: emoticons met bekende tekens zoals (L), winks, nudges, statusberichten en de vertrouwde aanduidingen beschikbaar, bezet, afwezig en offline.
Deze functies gebruiken dezelfde versleutelde berichtinfrastructuur als gewone chatberichten. Een nudge lijkt misschien een klein detail, maar hoort technisch bij dezelfde privacykeuzes.
Van ontwerp naar een app die je kunt gebruiken
Een messenger bouwen vraagt meer dan een werkende chatdemo. Lynn is ingericht voor distributie op macOS, Windows en Linux, met onder meer ondertekende builds en automatische updates. Volledig geautomatiseerd.
Ook de ontwikkeling erachter telt mee. Tests draaien voordat een versie verdergaat richting productie. Daarnaast hebben we het dreigingsmodel en de belangrijkste ontwerpkeuzes vastgelegd, zodat we beveiligingsbeslissingen kunnen toetsen en uitleggen.
Waarom we deze keuzes delen
Lynn Messenger laat zien hoe we bij Dynalogical software bouwen. We beginnen bij de vraag wat een product voor mensen moet doen en werken daarna uit welke techniek daarvoor nodig is.
Bij Lynn betekende dat: het plezier van een vertrouwde messenger terugbrengen, terwijl we wachtwoorden, berichten en bestanden zo behandelen dat gebruikers de controle over hun gegevens houden. Dat vraagt soms meer werk achter de schermen. Juist dat werk bepaalt of een app ook buiten een demo goed functioneert.
Benieuwd naar Lynn en wil je het zelf gebruiken?
Bekijk hier de website 👉 https://www.lynnmessenger.nl/
Wil je bespreken hoe we zo’n aanpak voor jouw project kunnen inzetten? Neem contact met ons op.
Lynn Messenger is een eigen product van Dynalogical.
*Lynn Messenger is niet verbonden aan, gesponsord door of goedgekeurd door Microsoft. De klassieke weergave is een eerbetoon aan Windows Live Messenger en MSN, en aan de nostalgie daaromheen.
"Windows Live Messenger", "MSN" en alle bijbehorende namen, logo's en handelsmerken zijn eigendom van Microsoft Corporation. Wij claimen daarop geen enkel recht; alle rechten berusten volledig bij Microsoft. Verwijzingen dienen uitsluitend ter herkenning en als nostalgisch eerbetoon.
