Updated: March 3, 2026
Security and Source Transparency
On this page, we define what can be verified technically, which architecture components we disclose publicly, and which repositories are already published for independent audit.
1) Document status
- With this page, we supplement our Security Disclosure, Privacy Policy, and Terms of Service.
- We use this page as a public transparency log: no marketing wording, only verifiable technical boundaries.
- Where this text conflicts with mandatory law, mandatory law prevails.
2) What is verifiable now
- Transport: we encrypt client-server channels via TLS/WSS; network observers can see connection metadata (IP/port/time/volume), but not plaintext E2E payload content.
- Server boundary: we process routing, delivery, authorization, and metadata on our servers, but under the intended key model we should not have technical access to E2E plaintext.
- KSMP Whisper Ultra OOB message cryptography is Signal Protocol based (Kasty-adapted implementation) with Double Ratchet semantics.
- Regular chats created via profile/token are not KSMP Whisper E2E mode; automated moderation is applied to open content (public feed videos, open comments, avatars, stickers).
- We document our message and call crypto model, including modes and limitations, on our Security page.
- Detailed protocol specs are published in our Docs section with revision tracking and MUST/SHOULD requirements.
3) Public audit repositories
- whisper-chatstore: client-side KSMP Whisper Ultra OOB layer (models, local storage, key-transparency logic). Repository: github.com/8dch4vtp24-boop/whisper-chatstore.
- ksmp-whisper-core: cryptographic and media layer for KSMP Whisper / WhisperStreamVoice profile (call models, media stream, codecs, transport-adjacent logic). Repository: github.com/8dch4vtp24-boop/ksmp-whisper-core.
- ksmp-server-boundary: minimal backend trust-boundary audit set (bootstrap public keys, hash-only room auth token, key transparency, call E2E boundary excerpt). Repository: github.com/8dch4vtp24-boop/ksmp-server-boundary.
- All repositories are published as source-available for security and interoperability review, not as open-source licenses for code reuse.
- Each repository contains `MANIFEST.sha256`, `SNAPSHOT_METADATA.md`, `TEST_PLAN.md`, and sanity-check scripts for reproducible review.
- Current license restrictions: redistribution, resale, integration into third-party products (including open-source projects), and operational usage are prohibited without separate written permission from the rights holder Kasty Vladimir Usanov.
4) What remains closed
- We do not disclose anti-abuse heuristics, anti-spam logic, and internal risk-scoring rules.
- We do not disclose operational secrets, environment key material, infrastructure hardening details, and internal incident-response playbooks.
- We do not publish code portions when publication would materially increase abuse risk without improving cryptographic verifiability.
5) Audits and disclosure practice
- We plan independent audits focused on cryptographic invariants and critical protocol-state correctness.
- After each audit, we will publish a public summary: scope, methodology, critical findings, and fix status.
- Vulnerability and suspicious-activity reports are accepted via support with the Security label.
