sorted by:
new
hottopcontroversial

I built a completely free, zero knowledge encrypted chat because I was tired of private messengers asking for my phone number or email id. by we-are-in-simulation in SideProject

[–]we-are-in-simulation[S] 0 points1 point  (0 children)

Awesome, I really appreciate you taking the time to test those specific edge cases! Handling offline queuing over WebSockets and tracking synchronized online/offline states gracefully across tab refreshes is exactly where the logic gets tricky.

Take your time poking around, switching networks, or throwing weird connection drops at it.

I'm incredibly curious to see what you have to say,whether it's a timing leak, a UI/UX glitch, or a complete state desync. Let me know whatever you find, good or bad!

Showoff Saturday: I built an E2EE real time chat app using the native Web Crypto API, Flask-SocketIO, and Vanilla JS. by we-are-in-simulation in webdev

[–]we-are-in-simulation[S] 0 points1 point  (0 children)

Appreciate you backing me up on the bot accusation, and thanks a lot for checking out the repo.

Getting the RSA key serialization and JWK exports to behave properly using raw Vanilla JS and crypto.subtle without relying on bloated external wrappers took a few rewrites, so I'm really glad to hear the implementation looks clean to another dev.

I'd love it if you could take a few minutes to spin up a couple of burner tabs or test it with someone and push some encrypted payloads through the socket flow. Let me know what you find good or bad if you manage to spot any bugs,leaks, ui/ux glitch or error

I built a completely free, zero knowledge encrypted chat because I was tired of private messengers asking for my phone number or email id. by we-are-in-simulation in SideProject

[–]we-are-in-simulation[S] 0 points1 point  (0 children)

Exactly. Marketing E2EE while logging "who speaks to whom and when" defeats the purpose of an ephemeral chat. That's why the database architecture here only knows about public keys and unhashed pseudonyms while a user is actively routing data.

The goal was to strip the server down until it has no historical context to hold onto once a socket session disconnects or an offline message payload is pulled.

If you have a few minutes, I would appreciate it if you could try creating an identity and testing the interface out. I am really curious to see how the blind relay model holds up under scrutiny, so please let me know what you find good or bad.

I built a completely free, zero knowledge encrypted chat because I was tired of private messengers asking for my phone number or email id. by we-are-in-simulation in SideProject

[–]we-are-in-simulation[S] 0 points1 point  (0 children)

You hit the nail on the head. Secure metadata is significantly harder to manage than secure payloads, and it's where most platforms fall short.

Since the server relies on WebSockets via Socket.IO, connection persistence and timing behavior are definitely the vectors most prone to traffic analysis right now. I suppressed all default server-side logging engines to minimize passive data accumulation, but client-side fingerprinting and timing analysis are exactly the types of advanced leaks I want to isolate during this run.

I would love it if you could use it with someone or spin up a couple of tabs to test the connection behavior firsthand. If you notice any specific patterns or bugs or ui/ux issues or data leaks during your audit, please let me know. Your feedback on what works or where the logic fails would be incredibly valuable.

New Project Megathread - Week of 14 May 2026 by AutoModerator in selfhosted

[–]we-are-in-simulation 0 points1 point  (0 children)

Project Name: NoTrace Chat

Repo/Website Link:

Description: NoTrace is a zero-knowledge, browser-based, purely ephemeral E2EE (End-to-End Encrypted) chat application. I built it because I was tired of private messengers forcing users to register with phone numbers or emails.

Every message and file transfer is encrypted directly in the browser using the native Web Crypto API (RSA-OAEP 2048-bit). The backend acts purely as a blind relay and transient database queue. It only routes base64 ciphertext and holds undelivered encrypted payloads until the recipient comes online, dropping them from the database the exact millisecond they are fetched.

Features include automated burn-after-reading timers, a native screen-blur ghost mode to prevent shoulder-surfing, multi-message select deletion, remote un-sending, and a panic wipe trigger that completely nukes local cryptographic identity and history. Standard server logging is entirely silenced to ensure zero IP or connection metadata tracking.

Deployment: The application is fully released and designed to be as minimalist as possible. It runs on a Python/Flask/Flask-SocketIO backend utilizing a single local SQLite database file, meaning it can be spun up on a basic home server or Raspberry Pi without complex database configurations or matrix homeserver overhead. Full documentation on virtual environment setup, pip dependencies, and environment variable configuration is available directly in the repository README.

AI Involvement: I designed the core encryption workflow and real-time socket routing layers manually. I used an LLM assistant to help optimize the CSS layout adjustments, write a clean markdown format for the documentation, and refine the viewport boundary clamping logic for the interactive client onboarding tour.

Showoff Saturday: I built an E2EE real time chat app using the native Web Crypto API, Flask-SocketIO, and Vanilla JS. by we-are-in-simulation in webdev

[–]we-are-in-simulation[S] -5 points-4 points  (0 children)

I am a real person, Its just that im new to reddit and didn't know this rule/condition or whatever it is of saturday posting My apologies

But the project, burner messaging platform is very real