ARCTIC MESSENGER WORKING TESTBED
A working testbed for encrypted messaging, local history and delivery across a relay. The next version is in active development and testing.
01 / Chats / local history
The Chats screen brings together local conversations and encrypted-message counts. A restored account can reopen its existing history without turning the conversation list into a wall of message previews.
Find a conversation on this device, check its local history and open it when you want to read. The build banner identifies the test configuration behind this capture.
02 / Contacts / trust and identity
Contacts keeps a local label beside each contact’s verification state. The labels “samsung” and “16e” identify the contacts on this device; changing a label does not change the contact’s cryptographic identity.
Use a recognisable local label, then compare the device verification code through a trusted independent channel. A Verified badge records that local confirmation; it is not identity certification by Arctic.
03 / Contact Card / QR import
Scan a QR code, choose its image from Photos or open an image file. The QR carries an Arctic Contact Card: structured information that helps the app address encrypted delivery and identify the peer’s public key.
Review a card before adding the contact. A valid QR is a way to exchange contact information, not proof of who sent it. Compare the device verification code before trusting the new contact.
04 / Username / discovery preferences
An account username is intended to offer a readable way to find a contact. It is distinct from the private labels you assign locally and from the public key used for encryption.
Read the current status and discovery control separately from a saved registration result. Once a contact has been resolved, key verification remains a separate step; a matching name does not authenticate a person.
05 / Privacy / account overview
The Privacy screen groups account readiness, connection details, encrypted storage, unread counts and notification settings. It gives the user one place to inspect those different boundaries.
Start here when checking whether the account is ready or looking for a specific privacy control. Open the relevant section instead of inferring every subsystem’s state from one green indicator.
06 / Private relay / delivery service
A relay routes and temporarily queues encrypted message envelopes. The client holds the message-decryption keys. The displayed mailbox is a routing identifier; it is different from the protected retrieval credential used to collect its queued envelopes.
Inspect the connection and request a relay check. Connection health tells you whether an endpoint responds; it does not prove that a particular message reached another person or was read.
07 / Encrypted storage / local totals
Storage shows aggregate ciphertext counts and sizes, including local media, the outbound queue and incoming staging. These totals can be calculated without opening message previews.
Check which stage holds data before cleaning up. The media action clears eligible sent or received photo and voice items locally; text and queued attachments are excluded.
08 / Local attention / private notifications
Unread counts and manual reminder marks stay on this device. Protocol 0.1 sends no read receipts. The notification example uses a generic “Arctic — New message” alert without a sender name or message content.
Manage what needs attention locally and keep message details off system alerts. Marking a conversation read here does not send a read confirmation to the other person.
INCLUDED FREE / BUILT-IN MEDIA TOOLS
Voice transformation and photo compression are part of Messenger’s free feature set. Both are implemented in the current testbed and process media on the device before message encryption.
Voice notes pass through a local transformation that gives recordings the standard Arctic robotic timbre. The transformed recording is encoded and encrypted before delivery; raw microphone audio is not sent to a voice-processing service.
The current testbed supports clips up to 15 seconds. The effect changes how a voice sounds; it does not guarantee that a speaker cannot be recognised.
Photos are resized and compressed on the device before encryption. Re-encoding produces a new JPEG without the original GPS/EXIF fields, reducing the data sent and keeping source camera metadata out of that outgoing copy.
Photos are compressed toward a target size of 512 kB, with a maximum of about 524 KB per image. Compression can reduce image detail; visible information within the picture remains visible to its recipient.
PRODUCT DIRECTION / FREE AND PAID FEATURES
Our product model keeps voice transformation and photo compression free. Planned paid additions will expand shared conversations and personalisation.
Create spaces for a community, project or team to talk together. Group creation and expanded shared-chat capabilities are planned paid features, separate from the one-to-one conversation flow shown in this testbed.
A distinctive set of Arctic emoji and optional cosmetic additions will give conversations their own character. Premium collections and appearance options are part of the planned paid offering.
Groups, shared chat spaces and cosmetic collections are in the product roadmap. Final packages, prices and release dates have not been announced; these additions are not demonstrated by the current screenshots.
FOR ORGANISATIONS / PLANNED PAID SERVICE
For organisations planning private employee groups and chat spaces, we intend to offer separately priced relay deployments. Servers would be provisioned for the company in agreed locations, with its messaging traffic assigned to that dedicated network.
For a company with offices in two countries, the proposed setup places dedicated VPS relay nodes in both agreed locations. Corporate clients would be configured to use those company-assigned relays, with no automatic fallback to the shared public relay pool.
An authenticated, encrypted VPN tunnel would link the company’s relay nodes across the public internet. It adds protection to inter-server traffic while message contents remain encrypted for their recipients.
The paid deployment would be agreed around company locations, capacity, administration and support needs. Employee membership, group key management and relay access policy require their own implementation and validation before this service can launch.
Server locations describe where the relay nodes are hosted. They do not guarantee that every internet packet stays within those countries. Routing, operational metadata, retention and failover would be defined explicitly for each deployment.
Message encryption protects content from the sender’s device to authorised recipients. The server-to-server VPN protects the connection between relay nodes. The tunnel does not require relays to decrypt the message body, and it does not replace client authentication or recipient-key verification.
Deployment concept for a future paid corporate offering. Dedicated corporate routing, employee groups and inter-relay VPN links are not live service claims for the current testbed.
NAMES, CARDS AND KEYS
A label in your local contact list. It is presentation, not a public account name or a cryptographic identity.
A readable account name in the developing discovery flow. Availability depends on the current service and build; a saved result is not fresh confirmation.
A QR or contact link carries public identity and delivery information. It gives no permission to retrieve the recipient’s mailbox.
Compare the code through a trusted independent channel. A changed peer key clears its prior verification state.
ENCRYPTION AND DELIVERY
Protection comes from separate layers: verifying a contact, encrypting message content, protecting the transport connection and encrypting local storage. Each layer has a specific job.
Protocol 0.1 uses X25519 key agreement, HKDF-SHA-256 key derivation and XChaCha20-Poly1305 authenticated encryption, with a fresh random nonce for each message. TLS protects the connection to the service; it is separate from the encryption of the message body.
The active protocol uses long-term pairwise keys and does not provide forward secrecy. Compromise of the relevant long-term private-key material can endanger recorded past messages. This remains a limitation of the current testbed.
The relay processes routing and mailbox state, encrypted envelope sizes, expiry and acknowledgments. The exact information available depends on its role. Network observers can see connection addresses, timing and traffic volume.
Keeping message content encrypted does not make all metadata invisible. A relay health check also says nothing about whether a recipient has read a particular message.
The documented clients store ciphertext message bodies within a SQLCipher-encrypted database, using an independent database key held through platform secure storage. Identity keys are protected through iOS Keychain or, on Android, a Keystore wrapping key.
Reading and composing require temporary plaintext on the device. The app clears buffers it owns across privacy boundaries, but cannot promise to erase every copy made by the operating system, keyboard or UI framework. End-to-end encryption cannot protect displayed content from an attacker controlling an unlocked endpoint.
The current app is a working testbed for connectivity, encrypted delivery and application behaviour. Work and testing on the next product generation are active, including a separate session-encryption programme.
The Session 0.2 candidate remains disabled in the active client protocol. Its development tests are not a production security approval. Independent cryptographic and mobile-security review, migration and device-lifecycle evidence remain necessary before activation.
PART OF ARCTIC FRONTIER SYSTEMS
Messenger carries encrypted conversations. Relay Monitor helps an operator inspect infrastructure health and peer connections. Its measurements are separate from message content and do not prove message delivery.
Explore Relay Monitor ↗Explore Arctic Vault ↗Screens shown from the owner’s Protocol 0.1 test build. Relay connection identifiers are replaced for illustration; application states are preserved. This page describes development work, not an independently audited production release.