Generate & answer
Text generation and question answering.
← Back to home
Local intelligence.
Hey N / Technology
Local intelligence.
Structured for control.
Hey N is a local artificial intelligence platform developed to make AI technologies as simple, accessible, and secure as possible for individuals and businesses.
- Local-first processing
- Modular AI models
- Controlled access
Architecture overview
Local-first
01User applicationsDesktop clients
02Approved integrationsOAuth 2.0
N
Orchestration layerHey N Engine
Private by design
03Local AI engineCompatible models
04Secure data layerEncrypted storage
05On-premises serverBusiness control
Architecture note. Some components shown on this page represent current infrastructure, while others are under development or part of Hey N’s target technical architecture.
01 / System architecture
Designed around your environment
Intelligence stays close.
The system is designed to consist of user applications, a local AI engine, an on-premises central server, a secure data layer, and external application integrations.
Hey N’s core approach is to process user data within the user’s device or the organization’s infrastructure wherever possible.
In the business version, the AI model will be able to run on the company’s own server, while employees connect through the Hey N application installed on their computers.
Documents, conversations, and corporate data are intended to stay away from third-party AI services unless access is necessary and authorized.02 / Local AI engine
Choose the intelligence
One interface.
Compatible local models.
Hey N is being developed so users will not be limited to the models provided with the platform. Compatible open-source AI models will be installable on personal devices or company servers.
Hey N Engine is planned to detect an installed model’s format, capabilities, and system requirements, then determine the appropriate runtime environment. This will allow different open-source models to operate through the Hey N interface in sync with supported features.
Analyze documents
Document and PDF analysis.
Search knowledge
Search within corporate documents.
Work with email
Email drafting and editing.
Build with code
Code generation and code review.
Use local files
Work with files stored on your device.
Reach internal context
Access an internal company knowledge base.
Automate workflows
Task and workflow automation.
Feature availability depends on model compatibility. Hey N will gradually expand its supported model formats and runtime infrastructures.
03 / Client and server
Built for organizations
Your server.
Your operational boundary.
Within Hey N Business, employees will connect to the organization’s local Hey N server through the desktop application.
The central server is planned to handle authentication, device management, model execution, authorization, message delivery, and integration management.
Employee clients
Desktop applications connect from approved devices.
Hey N server
Identity, authorization, models, messages, and integrations.
Assigned resources
Models, documents, integrations, and features by role.
RBAC
A role-based access control system is intended to ensure that each employee can access only the resources assigned to them or their department.
04 / Application integrations
Permission-based connections
Your workspace,
connected deliberately.
Hey N is expected to synchronize with Google Drive, Gmail, Microsoft Outlook, Dropbox, and Microsoft Teams. With permission, files, emails, calendar data, and related workspace resources can become accessible through Hey N.
Connections will use official APIs, OAuth 2.0, and supported secure authorization technologies. Permissions will be limited to the minimum required access and remain manageable by users.
- GDGoogle DrivePlanned
- GMGmailPlanned
- OMicrosoft OutlookPlanned
- DDropboxPlanned
- TMicrosoft TeamsPlanned
05 / Encryption and security
Layered protection
Encrypted before it leaves.
Hey N’s security architecture is being designed around protecting user data, preventing unauthorized access to message content, and keeping data within the organization’s infrastructure wherever possible.
For internal messaging, the target architecture encrypts messages on the sender’s device and decrypts them only on the recipient’s device, leaving the central server with encrypted content rather than plaintext.
Planned security technologies
Target stack / subject to validation| Security layer | Planned technology |
|---|---|
| One-to-one messaging | Double Ratchet-based end-to-end encryption |
| Group messaging | MLS — RFC 9420 |
| Message encryption | AES-256-GCM or ChaCha20-Poly1305 |
| Identity authentication | Ed25519 digital signature key |
| Key agreement | X25519 or the selected protocol’s secure key agreement |
| Private key storage | Windows TPM/DPAPI, macOS Keychain/Secure Enclave, Linux Secret Service/TPM |
| Server connection | TLS 1.3 |
| Server disks and backups | Additional AES-256 or LUKS-based disk encryption |
Plaintext belongs on authorized devices.
A message is intended to be encrypted before leaving the sender’s device. The central server may deliver and store it in encrypted form, but it does not possess the private key required to decrypt it. Plaintext returns only on an authorized recipient’s device, so even an administrator with database or server access is intended to see ciphertext rather than message content.
MLS and cryptographic epochs.
MLS, the IETF-standardized Messaging Layer Security protocol, is planned for group conversations. Membership changes create a new cryptographic epoch so removed users cannot read future messages and new users cannot decrypt unauthorized history.
Authenticated encryption.
AES-256-GCM or ChaCha20-Poly1305 are being considered to protect confidentiality and integrity. Modified content fails verification and is rejected, with a unique cryptographic value and, wherever possible, a separate key per message.
Identity anchored to each device.
Each Hey N device is planned to receive a unique identity key pair. Public keys may be stored on the server for verification, while private keys remain protected on-device. Ed25519 will verify identities; X25519 or the selected protocol’s secure mechanism will support key agreement. New devices are expected to require notification and trusted-device verification.
No universal administrator key.
Private keys are not intended to be stored in plaintext on the central server or in the application database.
- Windows: TPM and DPAPI
- macOS: Keychain and Secure Enclave
- Linux: Secret Service and TPM
The target architecture does not include a shared key capable of decrypting every message.
Protection in transit and at rest.
Client-to-server connections will use TLS 1.3. AES-256 or LUKS-based encryption is planned for server disks, databases, and backups as an additional layer supporting end-to-end encryption. Disk encryption alone cannot prevent administrator access to messages and is not a substitute for end-to-end encryption.
Separate keys for shared files.
Files sent through messaging are expected to be encrypted on-device with a random file key. Only the encrypted file reaches the server; its key travels to the recipient through an end-to-end encrypted message.
AI access requires intent.
End-to-end encrypted conversations will not be automatically readable by AI. Users must explicitly authorize content for analysis. Processing will occur on-device wherever possible; local server models receive only content deliberately submitted by the user.
06 / Release planning
A deliberate rollout
Built in stages.
Tested in reality.
Some AI models, security features, and integrations may not be supported in the initial individual beta. The beta will assess stability, improve the experience, and test model compatibility across devices.
Planned AI capabilities, security technologies, and external integrations are expected to be introduced gradually for individuals and businesses in the full release.
NowFoundation
Core infrastructure and product validation.
BetaTest & learn
Stability, usability, and model compatibility.
Full releaseExpand carefully
Capabilities, integrations, and security layers introduced gradually.
A clear expectation. Some components described here may not be available on the initial release date. Some represent current infrastructure, some are under development, and others describe the target architecture.
Certain security functions, integrations, and device-based key storage features may be limited in the individual beta. The planned security layers are expected to be introduced gradually for individual and business users in the full release.
Our goal is to make local artificial intelligence as simple as possible for businesses while keeping data security and user privacy fundamental to the system architecture.
Discuss Hey N Business