DEV Community

sonu samrat
sonu samrat

Posted on

I Built a Messaging App Where Nothing Stays

Most messaging apps say they care about privacy.

Then they ask for:

  • your phone number
  • your email
  • your contacts
  • your identity
  • your metadata
  • your backups

I wanted the opposite.

So I built GhostLine — a real-time messaging platform focused on disappearing communication, minimal data retention, and instant access.

🔗 https://ghostline.sbs

The Idea

I kept thinking:

Why does starting a “private” conversation require creating a permanent digital identity?

Sometimes you just want:

  • a temporary room
  • encrypted communication
  • no account
  • no installation
  • no history left behind

That became the core idea behind GhostLine.

Open the site.
Create a room.
Share the code.
Start talking.

No signup flow.
No profile building.
No social graph.

Tech Stack

GhostLine is built with:

  • Go backend
  • PostgreSQL
  • WebSockets for real-time messaging
  • WebRTC for peer communication
  • JavaScript + HTML/CSS frontend
  • Nginx reverse proxy
  • AWS deployment

The goal was speed and low latency while keeping infrastructure lightweight.

What Makes It Different?

1. No Signup System

You don't create an identity before using the app.

That removes friction and also reduces stored user data.

2. Ephemeral Communication

Rooms are temporary.
Messages are not designed to live forever.

The philosophy is simple:

conversations should disappear unless users intentionally preserve them.

3. Privacy-Focused Architecture

Instead of building a social platform first and privacy later, I tried building privacy into the core workflow.

4. Real-Time Performance

WebSockets handle instant messaging while WebRTC is used for direct communication features.

The result feels much closer to a native app than a traditional website.

Challenges I Faced

WebSocket Stability

One of the hardest parts was dealing with:

  • reconnect handling
  • proxy issues
  • SSL termination
  • unexpected disconnects
  • scaling concurrent rooms

Debugging real-time systems is very different from debugging normal REST APIs.

Deployment Issues

Nginx + TLS + WebSockets + reverse proxies can become painful fast.

I spent hours tracking:

  • 1006 WebSocket errors
  • upgrade header problems
  • SSL misconfigurations
  • Cloudflare/Nginx edge cases

Privacy vs Features

Every feature creates new privacy questions.

Even analytics become complicated when you're trying not to collect unnecessary data.

That tradeoff changed how I designed the platform.

What I Learned

Building a real-time privacy-focused app taught me:

  • simplicity is harder than feature overload
  • infrastructure matters as much as frontend UX
  • users care about friction more than most developers realize
  • “minimal” products often require more engineering discipline

Current Goals

Right now I'm focused on:

  • improving stability
  • better mobile experience
  • stronger room management
  • scaling concurrent users
  • improving encryption workflow

Try It

🔗 https://ghostline.sbs

Would genuinely love feedback from developers, security researchers, and people interested in privacy-focused products.

Especially around:

  • UX
  • performance
  • security architecture
  • real-world use cases

Thanks for reading.

Top comments (0)