Security & readiness
Designed for sensitive conversations.
SecureStreamHub is in development. This overview describes the intended model and distinguishes it from the current demonstration.
The intended message model
Seeker–mentor messages are intended to be encrypted on the user’s device before server storage. The goal is for the server to hold encrypted message content it cannot read. Organisational coordination records and access metadata are a separate category; authorised staff may need access to them.
Access and community
Aliases, scoped invitations, partner workspaces and role-based permissions are part of the plan. Community membership and video admission must be enforced by the backend, not only by visible buttons. Live video remains subject to server setup, membership checks and testing.
Version 1.0 security objectives
- On-device encryption of seeker–mentor messages.
- Post-quantum protection, subject to implementation and verification.
- Protected lessons and video access.
- Closed cohorts and scoped partner roles.
- Offline-capable web access.
- A local Kill Switch that clears local data, keys and sessions.
Limits matter
Local deletion does not remove recipients’ copies, screenshots or records held by other services. Neither encryption nor an emergency feature can guarantee personal safety. We do not claim a completed independent audit, a current SOC 2 attestation or verified production encryption specifications on this page.
Before production use
The implementation, data boundaries, retention practices and incident response procedures need to be verified and reflected consistently in the public documentation. The Year 3 plan includes a SOC 2 Type II objective; it is not a current certification.
Questions
For questions about the security model and partner workflow, use the contact details below. Avoid sending sensitive seeker information by email.
Manish Das
Managing Director
Arise Media & IT Consultants Ltd.
mdas@am-it-consultants.com