Audio by arcologies
< RETURN TO TERMINAL

NVSBL - Technical Security Whitepaper

Revision: August 18, 2026

1. What Is NVSBL?

NVSBL is a privacy-first communications terminal designed around four things traditional messaging apps often separate: identity, communication, local control, and intentional destruction.

Instead of making a phone number, email address, public profile, or conventional social account the center of every relationship, NVSBL lets users communicate through pseudonymous Mesh IDs. Two users deliberately establish a secure relationship, exchange cryptographic material, and then use that relationship for messaging, protected attachments, voice/video communication, and private local storage.

Communication should have an exit. NVSBL is built not only around how a secure relationship begins, but also how sensitive information is compartmentalized, how long it persists, what happens if a device is lost, and how a relationship can be deliberately destroyed.

2. Why NVSBL Exists

End-to-end encryption solves an important problem: keeping ordinary communication content private while it travels through untrusted infrastructure. But privacy does not stop there.

Real-world privacy also involves questions such as:

  • Do I have to give another person my phone number or email address to speak with them?
  • Where do sensitive files live after they are received?
  • What happens if I lose control of my phone?
  • What if a contact is compromised?
  • What if a message should not become permanent history?
  • Can I deliberately destroy a secure relationship instead of simply hiding it?

NVSBL was designed around those questions.

3. Core Design Principles

3.1 Pseudonymous Identity

NVSBL users establish relationships through Mesh IDs rather than exposing a phone number, email address, or public social identity to another NVSBL user. Backend authorization uses a pseudonymous anonymous identity rather than requiring a conventional email/password account for ordinary operation.

3.2 Deliberate Relationships

NVSBL does not center the experience around public feeds, follower counts, searchable social profiles, or random stranger matching. Secure relationships are intentionally established between Mesh terminals.

3.3 Local Control

Sensitive application state—including chat history, contacts, Vault content, block state, and cryptographic/session material—is designed to remain encrypted locally rather than existing only as a readable cloud account history.

3.4 Intentional Data Destruction

NVSBL treats deletion as a first-class security action. Incinerator, Dead Drop, Deep Lock, RipWire, Ghost Wipe, and configurable decoy controls give users different ways to reduce persistence or decommission a secure relationship or terminal.

4. Threat Model

NVSBL is designed to reduce common risks without pretending that any application can provide perfect security or invisibility.

4.1 Network Observation

Threat: An observer watches traffic moving between a device and internet infrastructure.

Defense: NVSBL encrypts application payloads and uses encrypted transport so ordinary plaintext messages and files are not exposed merely by observing network traffic. Metadata such as IP addresses, timing, traffic volume, provider endpoints, and connection state may still be visible.

4.2 Backend Compromise

Threat: An attacker compromises or gains access to backend infrastructure.

Defense: Ordinary private messages and protected attachments are designed to be handled as ciphertext rather than readable plaintext. Mesh routing uses hashed or derived identifiers where supported by the feature. A backend compromise can still expose encrypted payloads, pseudonymous identifiers, timestamps, delivery state, signaling information, abuse reports, and operational metadata.

4.3 Device Theft or Offline Extraction

Threat: An attacker gains physical access to a device or copies application storage.

Defense: Sensitive local NVSBL state is encrypted. Argon2id is used to increase the computational and memory cost of local credential guessing. A six-digit convenience PIN remains a finite secret, which is why the stronger Master Phrase is important.

4.4 Loss of Physical Control

Threat: A user loses control of an unlocked device, is coerced, or cannot return to a terminal before sensitive data should be destroyed.

Defense: Deep Lock, RipWire, Ghost Wipe, and decoy controls give the user options to remove active access or destroy NVSBL application state.

4.5 Abusive Contacts

Threat: A legitimate peer uses a secure relationship to harass, spam, or send abusive content.

Defense:NVSBL supports blocking and user-initiated reporting. A user who confirms REPORT & BLOCK may intentionally disclose selected readable evidence to NVSBL for moderation.

5. Cryptographic Building Blocks

5.1 SHA-256: Pseudonymous Routing

NVSBL uses SHA-256 hashing to derive fixed-length identifiers from Mesh IDs for routing and access control. Hashing reduces routine exposure of the readable Mesh ID in backend tables. Hashing is not encryption and does not make low-entropy identifiers impossible to guess.

5.2 Argon2id: Local Key Derivation

Argon2id is a memory-hard password-based derivation function used to increase the cost of guessing local credentials. It is used for local verification and key derivation rather than sending the user's plaintext PIN or Master Phrase to NVSBL servers.

5.3 AES-GCM: Authenticated Encryption

NVSBL uses AES-GCM for authenticated encryption of sensitive local application data and protected file payloads. AES-GCM provides confidentiality and integrity when keys and nonces are handled correctly.

5.4 Signal-Style Session Encryption

NVSBL uses a Signal Protocol-compatible implementation to create per-contact encrypted sessions and ratcheting message keys. Session state evolves as messages are exchanged instead of relying on one static conversation key indefinitely.

Use of a Signal-compatible open-source library does not imply certification, audit, or endorsement by Signal.

6. Messaging Architecture

6.1 Establishing a Mesh Relationship

A user supplies another terminal's Mesh ID, assigns a local alias, and initiates the public-key exchange needed to establish a secure relationship. NVSBL then maintains per-contact cryptographic session state for protected communication.

6.2 Sending a Message

  1. The sender creates plaintext on the local terminal.
  2. The secure session derives the message encryption material.
  3. The plaintext is encrypted before backend delivery.
  4. Supabase routes the protected payload using pseudonymous/hashed identifiers and service state.
  5. The receiving terminal retrieves the payload and decrypts it locally.

This means the server's job is primarily to move protected payloads and operational state—not to act as the place where ordinary conversation plaintext lives.

6.3 Incinerator

Incinerator gives qualifying messages a short application-level retention lifecycle. It is designed for communication that should not become permanent history. It cannot prevent a legitimate recipient from copying, photographing, or otherwise preserving content they were able to read.

6.4 Dead Drop

Dead Drop provides a one-time protected transfer workflow. A successfully consumed Dead Drop is intended to become unavailable after retrieval, reducing the need to create a permanent standing contact relationship for every exchange.

6.5 Report & Block

NVSBL preserves ordinary message confidentiality while still providing a deliberate safety path. When a user confirms REPORT & BLOCK, the selected evidence can be disclosed to NVSBL for moderation and the reported Mesh identity is blocked on that terminal.

7. Attachment Security & Vault

Sensitive documents and images often deserve stronger handling than a normal download folder. NVSBL therefore combines encrypted attachment delivery with local Vault storage.

  1. Local encryption: The sender generates a file-specific symmetric key and encrypts the file before upload.
  2. Protected key transfer: File-key material and metadata travel inside the secure messaging relationship.
  3. Restricted object access: Attachment storage is not exposed as a public bucket; authenticated capability/signed access is used.
  4. Local decryption: The authorized recipient retrieves ciphertext and decrypts it on-device.
  5. Vault: The recipient can retain sensitive files inside NVSBL's encrypted local Vault.
  6. Cleanup: Temporary access capabilities and attachment objects are cleaned up according to the transfer workflow.

8. Encrypted Voice & Video

NVSBL integrates voice and video into the same Mesh relationship rather than requiring users to expose a separate phone number or external communications account.

8.1 WebRTC Transport

NVSBL uses WebRTC-based encrypted transport for voice and video. Offer/answer signaling and call setup data are protected through the secure relationship where supported by the current call path.

8.2 Native iOS Call Behavior

Supported audio calls integrate with native iOS call behavior so incoming NVSBL calls can participate in familiar lock-screen and system calling flows.

8.3 Network Metadata

Peer-to-peer WebRTC can expose network addressing information to the other participant and to connectivity services. NVSBL therefore describes these calls as encrypted—not untraceable.

8.4 Ghost Filter

The Ghost Filter applies real-time audio processing intended to alter characteristics of the transmitted voice. It can make casual voice recognition more difficult, but it is not a guarantee of biometric anonymity.

9. Local Enclave

NVSBL stores sensitive local state in encrypted form. When the terminal is unlocked, needed cryptographic material is loaded into application memory so messaging, Vault, and contact features can function.

The design reduces exposure of readable local data at rest but does not claim control over every iOS memory-management behavior, hardware forensic technique, system backup, or compromised operating system.

10. Deep Lock, RipWire & Ghost Wipe

10.1 Deep Lock

Deep Lock removes the normal convenience unlock path and forces the stronger recovery workflow configured by the user. It is intended for situations where ordinary quick access should no longer be sufficient.

10.2 RipWire

RipWire is an optional dead-man's-switch style control. NVSBL records a local heartbeat and evaluates whether the configured interval has expired. If triggered, it can initiate terminal decommissioning.

10.3 Full Ghost Wipe / Terminal Decommission

A full Ghost Wipe is designed to destroy the initiating terminal's NVSBL identity. The application queues protected sever notices for linked peers, requests authenticated backend deletion, clears local NVSBL state, and returns the installation toward a fresh terminal state.

Backend deletion is treated as something that must be verified. If server deletion cannot be verified immediately, NVSBL can retain a narrowly scoped pending kill order tied to the original authenticated identity so cleanup can be retried safely.

10.4 Contact Severing

A linked peer that receives a valid Ghost Wipe sever instruction can remove the shared local conversation, contact relationship, and cryptographic session material. This is not the same as allowing one user to erase another person's entire NVSBL account.

10.5 Decoy Controls

NVSBL's grid-based interface can contain decoy controls configured to trigger destructive security behavior. This is intended for users who want the interface itself to participate in their local threat model.

11. Backend Architecture

The current NVSBL backend uses Supabase.

  • Supabase Auth: Pseudonymous anonymous authentication identities authorize protected network operations.
  • Postgres / Realtime: Supports routing state, messaging operations, call coordination, and other service data.
  • Row Level Security: Restricts direct client access to protected data paths.
  • Server functions: Sensitive workflows are moved into authenticated RPCs or Edge Functions where appropriate.
  • Protected Storage: Attachments use restricted access and temporary capability/signed-URL authorization rather than public browsing.

12. Push Notifications

NVSBL uses OneSignal and native iOS push infrastructure to wake devices for incoming activity. Push delivery requires a device token and pseudonymous notification identity.

The current privacy-preserving push design is intended not to place ordinary plaintext message content or a readable sender Mesh identity inside routine notification payloads.

13. Purchases & Entitlements

The iOS build uses Apple In-App Purchase for supported digital purchases and RevenueCat to assist with entitlement management. RevenueCat is linked to a pseudonymous NVSBL backend identity rather than a conventional email-address account.

14. What NVSBL Does Not Claim

Strong security engineering requires being clear about boundaries.

  • NVSBL does not claim to be unhackable or mathematically perfect.
  • NVSBL does not claim peer-to-peer WebRTC is untraceable.
  • NVSBL does not claim a six-digit PIN has unlimited entropy.
  • NVSBL cannot stop a legitimate recipient from copying content they receive.
  • NVSBL cannot guarantee protection on a fully compromised or jailbroken device.
  • NVSBL cannot guarantee that third-party infrastructure keeps no operational logs.
  • NVSBL has not yet undergone a comprehensive independent security audit.

15. Who NVSBL Is For

NVSBL is intended for people who value compartmentalized private communication: journalists and sources, privacy-conscious individuals, founders and teams discussing sensitive work, travelers, researchers, creators, consultants, and anyone who simply does not want every private relationship tied to a personal phone number or email address.

A user does not need an extraordinary threat model to value a separate communication identity. For many people, the benefit is simpler: talk privately without making your personal identity the price of admission.

16. Roadmap

Future work may further reduce metadata exposure, improve relay privacy, harden device compatibility, simplify architecture, and expand independent security testing. Roadmap items are development goals, not promises that a feature already exists or will ship on a specific date.

17. Contact & Responsible Disclosure

Security, privacy, or implementation questions may be sent to:
support@nvsbl.app

Security researchers are encouraged to provide reproducible details and avoid accessing or disrupting data belonging to other users while investigating potential issues.