Thanks for the question — I’m not a security researcher either, so let me answer in plain terms based on what I learned while designing the threat model.

The short answer: the platform (browser + server) is the ceiling, not the crypto. I could swap PBKDF2 for Argon2, or AES-GCM for XChaCha20, and it wouldn’t move sTELgano into “protects against governments” territory — because the web itself isn’t suited to that threat tier. A few well-known reasons:

1. The server ships the code. Every visit re-downloads anon.js from stelgano.com. If the server is compromised or legally compelled, it can serve a modified version that leaks the key. Native apps can be code-signed and pinned; websites can’t. This is the main reason Signal is an app and not a site — Tony Arcieri’s 2013 essay “What’s wrong with in-browser cryptography?” is still the canonical reference.
2. Metadata leaks outside the crypto. TLS SNI and DNS tell any upstream observer that a device connected to stelgano.com. No amount of payload encryption hides the connection itself.
3. No hardware-backed key storage in the browser. Native apps can use Secure Enclave / StrongBox. Browsers give you sessionStorage, which is cleartext to anyone with the device unlocked.

So I’d say the upgrades would be mostly futile for the state-actor threat tier — it’s a platform limit, not an implementation one. Which is why I scoped sTELgano to the intimate-access attacker specifically: the web platform is actually well-suited to that problem. Anyone who needs protection from law enforcement should use Signal on a hardened device; I’m not trying to duplicate that.

Worth noting that Arcieri’s post argues against in-browser crypto for all threat models, including mine. I disagree on that specific point — for the intimate-access attacker, the server-compromise risk he focuses on is much less salient than for the nation-state case. But his mechanical analysis of why the platform is a weak substrate is spot-on, and that’s what I’m pointing to.

Happy to be corrected by anyone with more security background than me.

Fully in-memory — technically yes, but it becomes a different product. Concrete consequences I’d want to not lose:

• Lockout counter reset-on-reboot = 10 attempts per uptime window, not per attacker career. Anyone who can trigger or wait for restarts refreshes their budget; the 30-minute time-based lockout guarantee becomes unenforceable — legitimate users also can’t know when theirs resets.
• “Every access is creation” works for synchronous / pure-P2P products. sTELgano is asynchronous: A sends, goes offline, B reads an hour later. A deploy between those two events drops the message. Reliability regression, not a privacy gain.
• TTL enforcement dies without persistence. Paid tier (1 year) and free tier (7 days) both need to survive restarts; in-memory resets the clock on every boot.
• Monetization needs persistence. extension_tokens have to outlive restarts or payments evaporate on the first deploy.

For the current product (asynchronous, time-based rate-limits, paid tiers), minimum persistence is the minimum. A stricter ephemeral product could work fully in-memory — but that’s a different product with a different UX contract. Happy to be convinced otherwise if there’s a specific version I’m missing.

Contact-note concern — let me reframe. I don’t think a new contact needs to be created at all. You add the generated steg number as an additional number on an existing real contact: John Doe already exists in your contacts with +254 722 222222; you just add +254 733 444444 as a second number on the same card. A suspicious partner browsing contacts sees “John Doe: two numbers” — completely unremarkable (work/personal, dual-SIM, new number, whatever). No note, no label, no new contact to justify — the contact’s name is the implicit label because it’s literally the person’s name. That mirrors what the product copy already implies (“saved in the other’s real contact card”), but the onboarding UX probably doesn’t make this pattern explicit enough today. Fair feedback — filing as a UX clarity fix.

PIN autofill by domain — real problem, you’re right to surface it. Current state: the app uses autocomplete="one-time-code" plus non-standard field attributes to discourage browser password managers from offering to save or fill the PIN. But browser heuristics change frequently, and a user with multiple channels on stelgano.com is exactly the case where “suggest the same PIN for this site” would break everything. Worth an actual audit on current Chrome/Firefox/Safari/Brave, not just trust the attributes. Filing.

Memorization load for users with >1 channels — unresolvable trade-off. Unique PIN per channel = more secure, harder to remember. Same PIN everywhere = single point of failure. Password manager = breaks the passcode test. The current design takes the security side, which means users with 3+ channels legitimately have memorization load. Worth naming in the docs as a known limit rather than pretending it isn’t there.

I didn’t know this is the intended usage pattern. Text only, 1 on 1 only, enforced N=1, Async communication make it very unique; and you will face quite some initial inertia.

If you decide to go down this route, then file/pic upload may not be very high on your priority list. Voice recording should be higher.