Building Neptune: Rethinking Secure Messaging Without Server Storage
Most messaging applications today follow the same architectural pattern.
A client sends a message to a server. The server stores it in a database, forwards it to the recipient, synchronizes it across devices, and often retains it for days, months, or indefinitely.
End-to-end encryption has significantly improved privacy, but in many systems, the server is still at the center of everything. It stores metadata, manages synchronization, and becomes the single source of truth for conversations.
That made me wonder:
Can we build a messaging system where servers are responsible for transport, but never for storing conversations?
That question led me to start building Neptune.
What is Neptune?
Neptune is a privacy-first, open-source messaging system built around a simple principle:
Every device is a node.
Instead of treating mobile devices as thin clients that depend entirely on a centralized backend, Neptune allows every device to participate in the network. Each device can act as a client, a relay, and a server depending on the available transport.
The goal isn’t to remove servers completely.
The goal is to remove their responsibility for storing your conversations.
Privacy Should Be an Architectural Property
Many applications advertise privacy as a feature.
I believe privacy should be part of the architecture itself.
In Neptune:
- Chat content is never persisted on a server.
- The backend cannot read messages.
- The backend cannot reconstruct conversations.
- The backend simply routes encrypted packets between devices when internet connectivity is required.
That distinction is important.
Instead of building trust around policies like “we promise not to read your data,” the system is designed so that it cannot read your data.
A Stateless Internet Relay
One common misconception is that Neptune is completely peer-to-peer.
Not exactly.
When two devices can communicate directly over Bluetooth Low Energy (BLE) or a local network, they do.
When they are separated by the internet, Neptune uses a lightweight backend built with Elixir and the Phoenix Framework.
This backend has a very limited responsibility:
- Receive encrypted packets.
- Route them to connected peers.
- Never store chat history.
- Never decrypt messages.
- Never become a permanent source of truth.
It’s intentionally stateless with respect to conversations.
Think of it as a courier carrying sealed envelopes. It knows where the package needs to go, but it has no idea what’s inside.
End-to-End Encryption by Default
Every message in Neptune is encrypted using NIP-44, the encryption standard from the Nostr ecosystem.
NIP-44 uses ChaCha20-Poly1305, providing authenticated encryption so that:
- only the intended recipient can decrypt the message,
- tampering can be detected,
- intermediaries only ever see ciphertext.
Even if someone controls the relay server, they still cannot inspect message contents.
Data Belongs on the Device
If conversations aren’t stored on servers, where are they stored?
Only on your device.
Structured data is encrypted using SQLCipher, while cryptographic keys are protected by the operating system’s secure hardware-backed storage (Keychain on iOS and Keystore on Android whenever available).
The result is simple:
Your conversations remain under your control instead of being replicated across centralized infrastructure.
Messaging Across Multiple Transports
One of the most interesting parts of Neptune isn’t encryption.
Get Debojyoti (Deb) Singha’s stories in your inbox
Join Medium for free to get updates from this writer.
It’s networking.
Messaging should not depend on a single transport.
Depending on availability, Neptune can route messages over:
- Bluetooth Low Energy (BLE)
- Local Area Network (LAN)
- Peer relays
- Internet connectivity
The application automatically chooses the most appropriate transport.
Whether two users are sitting next to each other, connected to the same Wi-Fi network, or communicating across continents, the messaging model remains the same.
The transport changes.
The user experience doesn’t.
Built on Open Standards
Rather than inventing another identity system, Neptune builds on the Nostr ecosystem.
Currently it uses:
- NIP-01 for relay protocol
- NIP-44 for encryption
- secp256k1 public/private key identities
Building on existing standards makes interoperability possible while allowing the project to benefit from an already active ecosystem.
The Interesting Problems
Building chat interfaces isn’t particularly difficult anymore.
The interesting engineering begins after that.
Questions like these become much more challenging:
- How do devices discover each other?
- How should routing adapt as network conditions change?
- How should offline messages be synchronized?
- How do peers recover after long periods offline?
- How do we maintain reliability without introducing centralized state?
- How should encryption keys rotate over time?
- How do we keep the system efficient on battery-powered mobile devices?
These are distributed systems problems more than messaging problems.
They’re also what make Neptune such an enjoyable project to work on.
Still a Work in Progress
Neptune is still in active development.
Many components are evolving, and there are plenty of ideas to explore -from improving peer discovery and synchronization to expanding transport capabilities and refining the developer experience.
The project is completely open source, and I’d genuinely love contributions from the community.
Whether you’re interested in:
- Mobile engineering
- Distributed systems
- Elixir
- Phoenix
- Cryptography
- Networking
- Nostr
- Security architecture
…your feedback, ideas, issues, or pull requests are always welcome.
Looking Ahead
I don’t think centralized messaging is going away anytime soon.
But I do think we should continue exploring architectures that reduce unnecessary trust and give users greater ownership of their data.
Neptune is my attempt to explore one of those architectures.
If nothing else, I hope it sparks discussions about what privacy-first messaging can look like when we stop treating servers as permanent storage.
If you’d like to follow along, contribute, or simply explore the code:
GitHub: https://github.com/debojyoti452/neptune-chat
I’m excited to see where the project goes -and even more excited to build it with the open-source community.
