Real-Time Email Notifications

The Polling Problem

Most temporary email services use polling to check for new messages. Your browser sends a request to the server every few seconds asking "any new emails?" The server checks, responds, and your browser waits and asks again. This creates a noticeable delay — anywhere from 5 to 30 seconds depending on the polling interval.

From a user perspective, this delay is painful. You have just submitted a signup form and you are staring at an empty inbox waiting for the verification email. You do not know if the email has not arrived yet, if it is being delayed, or if something went wrong. So you start clicking the refresh button, which sometimes resets the polling timer and makes the wait even longer.

Some services try to mask this with a "Checking for new emails..." animation, but the underlying problem remains: there is a gap between when the email actually arrives at the server and when your browser finds out about it.

Polling also wastes bandwidth and server resources. Every polling request is a full HTTP round-trip, even when there are no new messages. Multiply that by thousands of concurrent users polling every 5 seconds and you have significant load on the server doing nothing useful. This is one reason why some services have slow or inconsistent performance — their infrastructure spends more time answering "no new mail" than actually processing emails.

How Real-Time Delivery Works

NukeMail uses Supabase Realtime, a WebSocket-based system that maintains a persistent connection between your browser and the database. When a new email is inserted into the messages table, Supabase immediately pushes a notification through the WebSocket to every connected client that is subscribed to that inbox.

The practical result is that emails appear in your inbox within one to two seconds of hitting the mail server. There is no polling interval, no refresh button, and no manual checking. The email just appears, usually before you have finished switching tabs back to NukeMail.

The connection is lightweight — a single WebSocket uses minimal bandwidth and battery compared to repeated HTTP polling requests. If the connection drops (network blip, laptop sleeping), it automatically reconnects when the page becomes active again.

Why This Matters for Verification Emails

The most common use case for temporary email is receiving verification codes and confirmation links. These are time-sensitive — some verification codes expire in 5 or 10 minutes. A temp email service with a 15-second polling interval wastes 15 seconds of that window on every attempt.

With real-time delivery, the verification email appears almost immediately after the sending service dispatches it. You click the link or copy the code without any dead time. For services that send a code and then show a countdown timer, the difference between instant delivery and a 15-second delay can matter.

This is especially relevant for two-factor authentication, where you are typically staring at a login form on one screen and your temp email on another. The faster the code appears, the smoother the entire flow feels. Real-time makes temporary email feel like using your real email inbox.

Visual Feedback

NukeMail shows a subtle pulsing indicator when your inbox is actively listening for new emails. This gives you confidence that the real-time connection is working — you know the system is ready to show you emails the moment they arrive.

When a new email does arrive, it appears in the list with a brief fade-in animation. This is the only animation in the interface — everything else is static and immediate. The animation serves a functional purpose: it draws your eye to the new entry so you do not miss it, especially if you have looked away from the screen.

There are no desktop notifications, no sound effects, and no popup alerts. The email simply appears in the list. If you are on the page, you see it. If you are not, it will be there when you return. This keeps the experience focused and non-intrusive.

The visual feedback design reflects the overall NukeMail philosophy: functional, not flashy. The pulsing dot is not an animated loading spinner meant to entertain you — it is a status indicator that communicates system state. The fade-in on new emails is not a decorative transition — it prevents you from missing a new entry in the list. Every visual element serves a purpose.

Technical Reliability

Real-time systems add complexity compared to simple polling, but the tradeoff is worth it for the user experience. NukeMail handles the common failure modes: if the WebSocket connection drops, the client attempts to reconnect automatically. If the reconnection fails, it falls back to showing a "Connection lost" indicator so you know to refresh manually.

The real-time subscription is scoped to your specific inbox, so you only receive notifications about emails addressed to you. The server does not broadcast all emails to all connected clients — each connection is filtered at the database level to only your address IDs.

On the server side, Haraka processes the incoming email and inserts it into the database. Supabase detects the insertion and pushes the notification through the Realtime channel. The entire pipeline from SMTP receipt to browser display typically takes 1-3 seconds, most of which is Haraka parsing the email content.