Audio by arcologies
< RETURN TO TERMINAL

NVSBL - Privacy Policy

Last Updated: August 18, 2026

1. Privacy Is the Product

NVSBL is built for users who want to communicate without making a phone number, email address, or public social profile the center of every relationship.

The application uses pseudonymous Mesh IDs, encrypted messaging, protected file transfer, encrypted local storage, and deliberate privacy controls so users have more control over identity exposure, communication history, sensitive files, and what happens when a secure relationship needs to end.

Our design goal: ordinary communication content should be readable by the participating terminals—not routinely available to NVSBL as plaintext.

2. Information We Do Not Require for Ordinary Use

NVSBL does not require a conventional user profile containing a real name, telephone number, email address, GPS location, or facial biometric identifier in order to create an ordinary terminal.

  • Quick Access PIN and Master Phrase: These credentials are intended to remain on the user's device. NVSBL does not require their plaintext values on its servers.
  • Ordinary message content: Private messages are designed to be end-to-end encrypted between participating terminals.
  • Ordinary file content: Supported attachments are encrypted before protected server transport/storage and decrypted by the authorized receiving terminal.
  • Call media: NVSBL does not operate a service whose purpose is to record users' voice or video calls.

3. Information We Process to Make NVSBL Work

Private communication still requires limited technical information to route encrypted payloads, establish calls, wake devices, process purchases, prevent abuse, and maintain service state.

  • Pseudonymous backend identity: NVSBL uses anonymous Supabase authentication to authorize network operations without requiring a conventional email/password account.
  • Mesh and routing identifiers: Mesh IDs identify terminals to users; hashed or derived versions may be used for backend routing and relationship operations.
  • Operator Alias: A user-selected nickname may be stored locally and transmitted to contacts as part of a secure relationship.
  • Encrypted communications data: Ciphertext, encrypted signaling, attachment objects, delivery state, and related routing records may be processed or stored to provide requested features.
  • Push data: Device push tokens, a pseudonymous NVSBL notification identifier, and routing information are processed to notify sleeping devices of incoming activity.
  • Call connectivity data: Call setup can require pseudonymous identifiers, encrypted offer/answer signaling, ICE candidates, timestamps, call state, and network connectivity information.
  • Purchase and entitlement data: Product identifiers, transaction or receipt information, entitlement status, and a pseudonymous NVSBL identifier may be processed to provide iOS purchases and network-time entitlements.
  • Security and diagnostics: NVSBL and infrastructure providers may process IP addresses, timestamps, errors, rate-limit information, device/OS details, and operational metadata needed to protect and maintain the service.

4. End-to-End Encrypted Messages

NVSBL is designed so ordinary private message plaintext is encrypted on the sending terminal and decrypted on the receiving terminal. NVSBL does not routinely decrypt ordinary private conversations on its servers.

Encrypted content privacy does not mean metadata does not exist. Delivery state, timestamps, pseudonymous routing identifiers, encrypted payloads, and infrastructure logs may still be required to operate the service.

5. REPORT & BLOCK: The User-Controlled Safety Exception

NVSBL gives users a way to report abuse without pretending moderation can happen magically inside an encrypted system.

If a user deliberately selects REPORT & BLOCK, the reporting user may choose to disclose the selected message or related evidence to NVSBL for safety, moderation, abuse prevention, and enforcement. That evidence may be readable because the reporting user has intentionally chosen to disclose it.

Report evidence may be retained for as long as reasonably necessary to investigate abuse, protect users and infrastructure, comply with applicable law, resolve disputes, and enforce NVSBL rules.

6. Protected Attachments & Vault

NVSBL encrypts supported attachments on the sending device using a file-specific encryption key. Protected server storage is used to move the encrypted object, while authorized recipients receive the information needed to retrieve and decrypt it locally.

Received files may be stored inside NVSBL's local encrypted Vault. NVSBL uses restricted storage authorization and temporary access mechanisms rather than exposing attachment storage as a public browsing location.

7. Voice & Video Calls

NVSBL uses encrypted WebRTC transport for supported voice and video calling and integrates with native iOS call behavior for supported audio workflows.

Direct peer-to-peer connectivity can expose network addresses to the other participant and to connectivity infrastructure. Where relays are used, those services may process connection metadata. NVSBL does not promise anonymity against peers, network providers, traffic analysis, or device compromise.

8. Privacy Controls & Data Destruction

NVSBL includes controls intended to reduce unwanted persistence and give users meaningful ways to end a secure relationship or decommission a terminal.

  • Incinerator: Applies a short retention lifecycle to qualifying messages.
  • Dead Drop: Supports one-time protected transfer behavior.
  • Deep Lock: Forces the stronger recovery path configured by the user.
  • RipWire: May trigger destructive terminal decommissioning if the configured timer expires.
  • Ghost Wipe / Terminal Decommission: Designed to delete the relevant NVSBL identity, associated backend identity records, and local NVSBL application data accessible to the app.
  • Contact severing: Can remove the shared relationship, local conversation data, and cryptographic session material on participating terminals.

9. Permanent Account / Mesh Deletion

Users can initiate permanent deletion from within NVSBL using the Ghost Wipe / Terminal Decommission workflow. The process is designed to remove the relevant NVSBL network identity and associated server-side identity records and clear NVSBL's locally stored encrypted application data and cryptographic material accessible to the app.

Because deletion is destructive, it may be irreversible. NVSBL does not claim that an application can securely overwrite every operating-system cache, physical storage location, backup, provider log, or memory location outside its control.

10. Third-Party Services

  • Supabase: Used for anonymous authentication, database/realtime operations, protected server functions, signaling, selected storage, and other backend services.
  • OneSignal: Used for push notifications and may process the device push token, a pseudonymous NVSBL identifier, and standard device/network metadata.
  • Apple: Operates the App Store, Apple Push Notification service, and iOS In-App Purchase system.
  • RevenueCat: Assists with in-app purchase and entitlement management and may process a pseudonymous NVSBL identifier, App Store transaction information, product identifiers, and entitlement state.
  • WebRTC connectivity services: STUN, TURN, or related connectivity services may process IP addresses and connection metadata.

11. Retention

  • Local encrypted data: Chat history, contacts, Vault content, and local security state may remain on the user's device until deleted, expired, or destroyed by a security workflow.
  • Encrypted routing data: Ciphertext, signaling records, and attachment objects may remain only as long as needed for delivery, retry, cleanup, or feature operation.
  • Abuse reports: User-submitted evidence may be retained as described above.
  • Provider logs: Third-party infrastructure providers may retain operational logs under their own policies and service requirements.

12. User Choices

  • Choose whether to establish a secure relationship with another Mesh ID.
  • Block a Mesh identity.
  • Choose whether to disclose selected evidence through REPORT & BLOCK.
  • Choose whether to enable RipWire and other optional destructive controls.
  • Initiate permanent Ghost Wipe / Terminal Decommission.
  • Manage notification permissions in iOS Settings.
  • Manage eligible App Store purchases through Apple's account and purchase tools.

13. Security

NVSBL uses modern cryptographic and access-control measures intended to protect communications and local application data. These measures reduce risk but cannot eliminate every vulnerability, compromised device, malicious recipient, operating-system exploit, provider compromise, implementation defect, or future attack.

14. Changes to This Policy

NVSBL may update this policy as the architecture, providers, features, legal obligations, or privacy practices change. The date at the top identifies the latest published revision.

15. Contact

Questions about privacy, safety, deletion, or data handling may be sent to:
support@nvsbl.app