Why I built this
Most messaging systems assume one thing:
Everything should be stored forever.
That works for long-term collaboration, but I kept running into situations where it didn’t make sense:
- sharing API keys or temporary credentials
- debugging with someone in real-time
- sending logs or short-lived data
- quick discussions that don’t need history
Yet every tool I used (Slack, Discord, etc.) kept everything.
So I wanted to try something different:
What if conversations didn’t exist after they were done?
The idea: ephemeral chat
I built a small real-time system with a simple concept:
- no accounts
- instant room creation
- messages can auto-delete
- rooms are destroyed when inactive
No persistence by default.
Just:
open → share link → chat → disappear
Architecture decisions
I kept the system lightweight:
- WebSockets for real-time messaging
- in-memory room management (no long-term storage)
- lifecycle-based cleanup (rooms destroyed when empty)
The tricky part wasn’t sending messages — it was managing state and cleanup reliably.
What was harder than expected
1. Room lifecycle
Knowing when to delete a room sounds simple, but edge cases show up fast:
- user disconnects unexpectedly
- browser closes without cleanup
- multiple users joining/leaving rapidly
You need a reliable way to detect inactivity and safely destroy state.
2. Real-time consistency
With no persistence, everything depends on live state.
If something breaks:
there’s no fallback.
So handling:
- connection drops
- reconnections
- message ordering
becomes more critical.
3. Random internet traffic
Even with a small deployment, I started seeing:
- requests to
/phpmyadmin - probes for
/admin - random scanning behavior
Which was a reminder:
anything exposed publicly will get hit.
What surprised me
The biggest surprise wasn’t technical.
It was behavioral.
When users know messages won’t be stored:
- they type faster
- they overthink less
- conversations become more direct
It feels closer to a real conversation than a logged system.
The tradeoff
Ephemeral systems aren’t always better.
Sometimes you need history:
- debugging issues later
- tracking decisions
- auditing conversations
So the real challenge is:
When should something disappear, and when should it stay?
Most tools don’t give that choice.
Where this actually works well
So far, the strongest use cases:
- sharing temporary credentials
- quick debugging sessions
- short-lived dev collaboration
- anything that shouldn’t persist
What I’m exploring next
Trying to find a middle ground without breaking simplicity:
- optional short-lived recovery
- lightweight session controls
- keeping zero-friction as core
Try it
If you’re curious to see how it works:
Final thought
Not every system needs persistence.
Sometimes, removing history changes how people interact — and in some cases, that’s exactly what you want.
Top comments (0)