By pairing Tor v3 Client Authorization (Stealth Onions) with a decentralized, statically typed Webring Matrix compiled in OCaml, you can construct an immutable, authenticated ecosystem. This design ensures that unauthorized clients cannot resolve your infrastructure at the routing layer, while your applications remain light and dependency-free. Architectural Layout A stealth webring relies on decoupling network authorization from application coordination. The request flows through three distinct boundaries:

• The Authorized Client Boundary: The user inputs a stealth address into their browser. The local client-side Tor daemon intercepts the request, maps the address to a locally stored .auth_private key file, and initiates an x25519 cryptographic handshake across the network.
• The Network Routing Boundary: Unauthenticated requests are dropped at the Tor entry point nodes. Only traffic proving possession of the private key matches the public service descriptor and is successfully routed to the remote host.
• The Loopback Execution Boundary: Once authorized traffic passes the host's Tor daemon, it drops down to the local loopback interface (127.0.0.1). Here, a lightweight background server processes the connection locally and serves the type-safe static files compiled by the OCaml engine.

VPS Specifications for Stealth Nodes Because stealth onions completely mask infrastructure and drop unauthenticated connections at the Tor introduction points, web traffic never touches standard networking layers. This efficiency eliminates heavy background thread utilization, allowing you to run your nodes on minimal virtual machine configurations:

• The Micro Node Profile: This environment requires a basic 1 vCPU, 1GB RAM, and 10GB SSD footprint. It is tailored specifically for individual nodes or standalone sovereign dispatch terminals handling between 1 and 10 authorized peers.
• The Ring Coordinator Profile: Upgrading to 2 vCPU, 2GB RAM, and 30GB SSD provides the computing headroom necessary for higher capacity deployments. This profile is optimized for managing 50+ authorized peers, where the server frequently compiles, tests, and distributes global webring state files.

Key Management Pipeline Stealth authorization enforces access control via asymmetric key pairs without relying on external certificate authorities. The provisioning cycle moves sequentially through generation, server storage, secure distribution, and client initialization:

• Phase 1: Key Generation: Running your local key generator issues a cryptographically secure x25519 private key and extracts its matching public key token.
• Phase 2: Host Side Registration: The public token is stripped of any padding and stored within the server's local hidden service file system under /authorized_clients/ using a strict .auth format.
• Phase 3: Secure Handout: The operator sends the private key token to the end-user out-of-band via a secure encrypted channel.
• Phase 4: Client Configuration: The user appends the stealth onion URL and their matching private key token directly to their client-side Tor authentication profile or browser interface.

Server-Side Initialization To configure your Node to require keys, set up individual client authorization files inside your hidden service folder path:

1. Establish the internal authorization directory

sudo mkdir -p /var/lib/tor/sovereign_dispatch/authorized_clients/ sudo chown -R debian-tor:debian-tor /var/lib/tor/sovereign_dispatch/authorized_clients/ sudo chmod 700 /var/lib/tor/sovereign_dispatch/authorized_clients/

2. Add an authorized peer file (Must use the .auth extension)

echo "descriptor:x25519:base32encodedpublickey" | sudo tee /var/lib/tor/sovereign_dispatch/authorized_clients/andy.auth sudo chown debian-tor:debian-tor /var/lib/tor/sovereign_dispatch/authorized_clients/andy.auth sudo chmod 600 /var/lib/tor/sovereign_dispatch/authorized_clients/andy.auth

3. Reload Tor to lock down the interface

sudo systemctl restart tor

The OCaml Webring Compilation Engine Instead of relying on heavy databases, a webring can be compiled into a static, type-safe data array. Using OCaml guarantees that the directory state is validated at build time. Below is an index parsing engine that reads your peer array and cleanly generates safe navigation linkages. (* webring.ml - The Sovereign Webring Compiler *)

type node = { onion_address : string; display_name : string; admin_contact : string; }

(* Static webring registration block *) let webring_matrix : node list = [ { onion_address = "abcde1234567890onionaddress1.onion"; display_name = "Sovereign Dispatch"; admin_contact = "admin@nostr" }; { onion_address = "v3onionaddress2xyz789012345.onion"; display_name = "The Darkleaf Mint"; admin_contact = "mint@nostr" }; { onion_address = "anotherstealthaddress34567.onion"; display_name = "Libre Press Archive"; admin_contact = "lib@nostr" } ]

(* Pure structural function to find neighboring nodes *) let rec get_neighbors target list = match list with | [] -> None | [single] -> if single.onion_address = target then Some (single, single) else None | first :: second :: tl -> if first.onion_address = target then Some (List.hd (List.rev (second :: tl)), second) else get_neighbors target (second :: tl @ [first])

(* Generate raw HTML component string for embedding *) let generate_widget_html target = match get_neighbors target webring_matrix with | None -> "" | Some (prev_node, next_node) -> Printf.sprintf "

let () = (* Example build pipeline execution *) let target_node = "abcde1234567890onionaddress1.onion" in let html_output = generate_widget_html target_node in print_endline html_output

To build and integrate this into your deployment cycle, run it through the native compiler toolchain: ocamlopt -o compile_ring webring.ml ./compile_ring > webring_component.html

The resulting component file can be seamlessly included into your local vanilla index.html structure, providing type-safe, static, serverless peer routing throughout the private network. For an architectural overview of full-stack OCaml compilation and how static sites interface with pure language paradigms, you can explore the Full-Stack OCaml Compilation Overview, which details compiler targets and framework layout mechanics useful for sovereign systems. Feasibility Schema: Semantic Structures for Content Distribution When tables and visual layout containers fail to render across minimal or mobile publishing systems, the operational validity of a statically compiled, network-isolated architecture can be fully parsed through pure, linear semantic pillars:

• Zero-Trust Routing (The Network Pillar): Handshakes complete entirely within the Tor cryptographic layer before packets are passed to the inner web server. This mechanism provides an ideal runtime for distributing sensitive, encrypted code repositories or private digital archives exclusively to authenticated nodes.
• Compile-Time Safety (The Integrity Pillar): OCaml's strict compiler enforces that every single peer array entry and navigation link is structurally valid prior to compilation. This operational reality systematically eliminates broken links, runtime null pointer panics, and navigation failures when nodes go offline or change addresses.
• Zero-Dependency Footprint (The Portability Pillar): The engine avoids databases and heavy execution frameworks by compiling complex routing logic down to vanilla HTML component structures. This enables low-overhead publishing configurations that can be effortlessly mirrored onto offline backup drives, private local loops, or sovereign IPFS file systems.
• Asymmetric Revocation (The Access Control Pillar): Permissions are managed discretely on the server via separate files located inside the hidden service's authorization path. This structural layout lets the ring operator instantly revoke access for individual compromised keylines by deleting a single file and reloading the daemon, keeping the remaining publishing circle completely insulated.

Hardened State Management — Integrating Dynamic Databases, Nostr Communication Layers, and Sovereign Email Routing While statically compiled webrings provide structural rigidity for data distribution, functional commerce and real-time operational coordination require an active data persistence layer and interactive, out-of-band communication loops. By anchoring your environment with a localized MariaDB deployment and routing your business pipelines entirely through the Nostr protocol, you can bypass public telecommunication infrastructure entirely. This design bridges real-time store monitoring with cryptographically secured, peer-to-peer message routing. Architectural Layout (Dynamic Commerce & Messaging) Integrating relational storage and sovereign messaging shifts your network profile from an absolute static system to an active state engine without increasing external surface exposure. Traffic maps across three execution domains:

• The Secure Persistence Boundary: Incoming web traffic routes through the local Tor daemon and hits a lightweight background PHP server process. When data fields (such as order forms) are processed, inputs are scrubbed using rigid parameterization guidelines and securely written directly into a local MariaDB instance bound to loopback memory space (127.0.0.1).
• The Cryptographic Communications Boundary: Customer interactions, support channels, and order confirmations bypass standard SMTP and web-form mechanisms. Instead, transactions rely on asymmetric public-key cryptography via the Nostr protocol. Communications translate into discrete, signed JSON events distributed across decentralized relays.
• The Sovereign Routing Matrix (nmail & nostrplebs): Legacy communication channels like email are systematically containerized. By routing incoming mail blocks into Nostr-native clients like nmail and tying network identifiers to sovereign domains using nostrplebs, email structures are converted into encrypted Nostr-native direct messages (DMs) seamlessly.

Production DB Schema: Sovereign Storefront Terminal To maintain an active inventory matrix and store inbound cryptographically protected client transactions without exposing cleartext data, execute the following configuration scripts inside your MariaDB administrative console: -- Ensure database alignment CREATE DATABASE IF NOT EXISTS coffeestore; USE coffeestore;

-- Products Table: Dynamic Catalog Routing CREATE TABLE IF NOT EXISTS products ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL, description TEXT NOT NULL, price_btc DECIMAL(10, 4) NOT NULL, stock_status ENUM('IN STOCK', 'LOW STOCK', 'OUT OF STOCK') DEFAULT 'IN STOCK', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- Orders Table: Parameterized Inbound Transmission Log CREATE TABLE IF NOT EXISTS orders ( id INT AUTO_INCREMENT PRIMARY KEY, tx_signature VARCHAR(255) NOT NULL UNIQUE, item_variant VARCHAR(100) DEFAULT 'Whole Bean', encrypted_payload TEXT NOT NULL, internal_notes TEXT DEFAULT NULL, status ENUM('PENDING_VERIFICATION', 'PAID_PREPARING', 'SHIPPED', 'COMPLETED', 'FLAGGED') DEFAULT 'PENDING_VERIFICATION', submitted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- Clean out stale data and seed active product metrics TRUNCATE TABLE products;

INSERT INTO products (name, description, price_btc, stock_status) VALUES ( 'Dark Roast Sovereign Blend', 'A bold, single-origin dark roast packaged coffee designed for late-night terminal sessions. Responsibly sourced, nitrogen-flushed, and roasted in small batches to preserve distinct notes of dark cacao and smoke. Each package includes entry validation steps for verifying origin telemetry.', 0.0003, 'IN STOCK' );

Full-Stack PHP System Controller (db.php & index.php) This minimalist full-stack implementation establishes error exceptions while systematically stripping away runtime trace data to completely eliminate environment leaks or system path disclosures.

1. Hardened Connection Link (db.php)

try { $dsn = "mysql:host=" . DB_HOST . ";dbname=" . DB_NAME . ";charset=utf8mb4"; $options = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => false, ]; $pdo = new PDO($dsn, DB_USER, DB_PASS, $options); } catch (\PDOException $e) { // Suppress backtraces completely; yield uninformative failure block die("System Error: Secure database terminal link offline."); }

1. Monolithic Sovereign Checkout Interface (index.php)

try { $stmt = $pdo->query('SELECT id, name, description, price_btc, stock_status FROM products ORDER BY id ASC'); $products = $stmt->fetchAll(); } catch (\PDOException $e) { $products = []; } ?>

    <section>
        <?php foreach ($products as $item): ?>
        <div class="card">
            <h2><?= htmlspecialchars($item['name'], ENT_QUOTES, 'UTF-8') ?></h2>
            <p><?= htmlspecialchars($item['description'], ENT_QUOTES, 'UTF-8') ?></p>
            <p>Rate: <span class="price"><?= number_format((float)$item['price_btc'], 4) ?> BTC</span> | Status: <strong><?= $item['stock_status'] ?></strong></p>
        </div>
        <?php endforeach; ?>
    </section>

    <section class="card">
        <h3>Transmit Cryptographic Order</h3>
        <form action="submit_order.php" method="POST">
            <label>1. Encrypted PGP Payload Block (Targeting Shop Fingerprint)</label>
            <textarea name="encrypted_payload" class="input-block" style="height:120px;" required placeholder="-----BEGIN PGP MESSAGE-----..."></textarea>
            
            <label>2. Transaction Ledger Signature (TxID Reference)</label>
            <input type="text" name="tx_signature" class="input-block" required placeholder="Paste verified transaction reference string">
            
            <button type="submit" class="btn">Commit Order to Ledger Queue</button>
        </form>
    </section>

    <footer>
        <p class="footer-pubkey"><strong>Shop PGP Fingerprint:</strong> 0123 4567 89AB CDEF FEDC BA98 7654 3210 FFFF EEEE</p>
        <p class="footer-pubkey"><strong>Support Identity (Nostr Npub):</strong> npub1fictionalcoffeeshopidentitystringgoeshereforoutofbandcommunications</p>
    </footer>
</div>

Decoupled Communication Infrastructure: Nostr Native Layer Relying on standard cleartext web contact forms or centralized email services bypasses the structural core of onion-routing architecture. By integrating Nostr as your infrastructure's communications engine, you maintain complete cryptographic verification and transport continuity. SOVEREIGN SUPPORT ECOSYSTEM DATA FLOW

[ PIPELINE A: Legacy Email ]

• Origin: Cleartext Mail Sender └──> Routes to: Public MX Relay └──> Processes via: nostrplebs Verification └──> Feeds into: nmail Engine └──> (Merges into Decentralized Relay Layer)

[ PIPELINE B: Tor Storefront ]

• Origin: Client UI / Tor Browser └──> Inbound Data: Pastes PGP Payload └──> Writes to: Hardened Hidden Service └──> Database Action: Parameterized Write └──> (Merges into Decentralized Relay Layer)

[ CENTRAL CONVERGENCE LAYER ] DECENTRALIZED RELAY NETWORK LAYER (Protocol: NIP-04 Encrypted DMs / NIP-17 Gift Wrappers) └──> Execution Link: nmail Command Interface └──> End Point: Secure Terminal Decryption

1. Replacing Web-Forms with NIP-04/NIP-17 Encrypted DMs Instead of hosting interactive mail scripts locally, customer interaction is directed to your business's Nostr Public Key (npub).

• Cryptographic Signatures: Every message sent via Nostr is an atomic JSON data event cryptographically signed by the user’s private key. This ensures metadata authenticity and completely removes target tracking vulnerabilities.
• Gift Wrapped Data Transport (NIP-17): Modern Nostr clients leverage gift wrapping protocols to envelop conversations inside ephemeral wrappers. This masks tracking metadata on open relays, protecting the transaction flow from external observation.

1. Bridging Legacy Networks with nmail & nostrplebs To interact with enterprise entities that rely on standard legacy architectures, incoming standard email strings can be funneled directly into Nostr's transport infrastructure:

• Sovereign Handles via nostrplebs: By standardizing your public brand key with a verified nostrplebs mapping, you gain a human-readable NIP-05 lightning address and a matching communication alias (e.g., roastery@coffeedomain.com) without hosting an actual, unprotected IMAP/SMTP server cluster.
• Operations via nmail: nmail acts as a flutter app driven utility that monitors a configured Nostr keypair and converts incoming routed email transmissions directly into encrypted Nostr clearnet email or to anyone in Nostr. To audit, extract, or monitor your background operations terminal while maintaining compliance with clean coding principles, operators can systematically leverage foundational "Learning To Read Code As A Developer concepts—such as tracking Cognitive Complexity and mapping Fan-In/Fan-Out structural loops—safeguarding production speeds across resource-constrained backend profiles.

For an architectural overview of full-stack OCaml compilation and how static sites interface with pure language paradigms, you can explore this Full-Stack OCaml Compilation Overview, which details compiler targets and framework layout mechanics useful for sovereign systems. nostr-mail A modern, cross-platform email encryption tool that bridges Nostr and email protocols, providing end-to-end encrypted communication using secp256k1 key pairs and the decentralized Nostr social key registry. What can it do? nostr-mail encrypts email payloads utilizing an asymmetric shared secret derived from the sender's private key and the recipient's public key. By leveraging Nostr's decentralized protocol for public key infrastructure (PKI) and identity discovery, it eliminates the traditional friction points of email encryption (like PGP key servers and web-of-trust management) while maintaining compatibility with standard SMTP and IMAP servers for data routing. Why nostr-mail? Traditional email encryption tools like PGP have struggled with mainstream adoption due to complex key distribution, lack of a unified key registry, and poor user experiences. nostr-mail decouples the identity/encryption registry from the transport layer, allowing existing email infrastructure to serve as an abstract data pipe while identity and encryption handshakes happen natively on Nostr relays. Technical Architecture & Sovereign Routing For security-conscious environments, nostr-mail can be deployed inside an isolated, metadata-resistant workstation pipeline. This architecture ensures absolute localization by routing traffic strictly through local loopbacks, private onion daemons, and decentralized relays, cutting out cleartext leak vectors entirely. Sovereign Support Ecosystem Data Flow SOVEREIGN SUPPORT ECOSYSTEM DATA FLOW

[ PIPELINE A: Legacy Email ]

• Origin: Cleartext Mail Sender └──> Routes to: Public MX Relay └──> Processes via: nostrplebs Verification └──> Feeds into: nmail Engine └──> (Merges into Decentralized Relay Layer)

[ PIPELINE B: Tor Storefront ]

• Origin: Client UI / Tor Browser └──> Inbound Data: Pastes PGP Payload └──> Writes to: Hardened Hidden Service └──> Database Action: Parameterized Write └──> (Merges into Decentralized Relay Layer)

[ CENTRAL CONVERGENCE LAYER ] DECENTRALIZED RELAY NETWORK LAYER (Protocol: NIP-04 Encrypted DMs / NIP-17 Gift Wrappers) └──> Execution Link: nmail Command Interface └──> End Point: Secure Terminal Decryption

Incompatible Technologies (Architectural Constraints) To preserve the anonymity and isolation guarantees of this ecosystem, the following technologies cannot be substituted into the pipeline:

• Outbound Webhooks / REST Push APIs (Slack, Discord, Telegram): Incompatible. These require the internal environment to make outbound cleartext HTTPS connections to centralized servers, leaking the host's true IP address via the TCP handshake.
• Standard Cleartext SMTP Transports (SendGrid, Postfix over WAN): Incompatible. Standard email routing leaks server hosting locations within headers and relies on public DNS tracking. The native nmail + nostrplebs engine avoids this by pulling data directly to an isolated relay inbox instead of pushing trackable artifacts.
• Centralized Cloud Databases (AWS RDS, Managed SQL): Incompatible. Exposing database socket connections outside the local loopback matrix (127.0.0.1) introduces significant external attack surfaces and breaks isolation guarantees.
• Standard WebSockets over Clearnet: Incompatible. These are highly vulnerable to traffic analysis and timing patterns over Tor, and frequently drop states during circuit cycling. Persistent communication must rely on atomic, parameterized cryptographic form actions.

Application Core Features 📧 Email Management

• SMTP Transport Layer: Outbound email delivery via standard authenticated SMTP servers.
• IMAP Sync Engine: Direct inbox fetching and mail synchronization from remote IMAP servers.
• Local Storage & File Operations: Attachment encryption using hybrid wrappers, local database draft persistence, and deep metadata search.

🔐 Nostr Native Operations

• Cryptographic Key Management: Generation and secure local import of secp256k1 key pairs (handled in native nsec/npub formats).
• NIP-44 & NIP-04 Compliance: Implements modern NIP-44 standard encryption by default for robust padding and forward-security, while preserving legacy NIP-04 support for backward parsing.
• Relay Fabric Sync: Real-time synchronization of contact profiles, follow lists, and Kind 4 / Kind 1059 direct messages over user-defined relays.

System Stack Frontend Architecture

• Vanilla JavaScript: Framework-free interface construction minimizing the memory footprint and eliminating downstream dependencies.
• HTML5 & CSS3 Flexbox/Grid: Completely semantic markup paired with responsive layouts and variable-driven styling for effortless light/dark theme switching.

Backend Infrastructure (Tauri Framework)

• Rust: High-performance, memory-safe execution core driving cryptographic computations, file handling, and network connectivity.
• Tauri API Bridge: Low-overhead inter-process communication (IPC) mapping frontend JavaScript bindings directly to compiled Rust commands.
• SQLite Persistence Layer: Embedded relational database caching encrypted local logs, contact indices, metadata states, and network configuration profiles.

Installation & Environment Configuration Prerequisites

• Rust Toolchain: Latest stable version of rustc and cargo.
• Tauri Command Line Tooling: Installed via cargo install tauri-cli.
• Platform Dependencies:
• Linux (Debian/Ubuntu): libwebkit2gtk-4.0-dev, build-essential, curl, wget, libssl-dev, libgtk-3-dev, libayatana-appindicator3-dev, librsvg2-dev
• macOS: Xcode Command Line Tools.
• Windows: Microsoft Visual Studio C++ Build Tools.

Installation Steps

Clone the codebase repository

git clone https://github.com/asherp/nostr-mail cd nostr-mail/tauri-app

Initialize the interactive desktop development build

cargo tauri dev

Initial Configuration Sequence

• Identity Injection: Navigate to Settings -> Nostr Settings. Input your private key or select Generate New Keypair. Safely export and archive your backup variables.
• Mail Pipeline Authorization: Navigate to Settings -> Email Settings. Populate your outbound SMTP endpoint and incoming IMAP variables. If using a service like Gmail, generate a dedicated App Password from your service dashboard and ensure IMAP is explicitly active within your server parameters.
• Relay Initialization: Define your active network pathways within Relay Settings (e.g., wss://relay.damus.io).
• Directory Sync: Under the Contacts view, execute a manual Refresh to crawl your Nostr identity graph and resolve corresponding recipient addresses.

Application Layout Modules

1. Compose Page Designed for structural messaging setup. Users input their message parameters, choose recipient public keys, and load attachment paths.

• Hybrid Cryptographic Routine: Large payload file attachments are split and encrypted using randomized symmetric AES-256-GCM keys. These payload keys are then securely wrapped using the recipient's public key via NIP-44.
• Dual-Channel Dispatch: Activating Send Matching DM triggers a simultaneous notification ping containing the email metadata to the contact's Nostr DM inbox alongside the standard SMTP delivery route.

1. Inbox & Sent Ledgers

• Dynamic Decryption Matrix: incoming messages are dynamically indexed from your IMAP node. Encrypted blocks are decrypted locally using your private key. If signature enforcement is active, unverified or cryptographically corrupt blocks are dropped from view.
• Locally Hardened History: Sent records are kept entirely within the offline local database to avoid exposing cleartext metadata patterns to your public email service provider.

1. Client Direct Messages (DMs) Provides a real-time conversational interface mapping Kind 4 or modern encrypted events directly to a clean UI layout. Conversations are clustered cleanly by sender public key and sorted by chronological thread updates.
2. Identity & Contact Profiles

• Local Indexing: Contact indices, profile names, and media arrays are stored in your local cache to enable instantaneous loading states and full offline accessibility.
• Kind 0 Publishing Engine: Updating your identity parameters creates a signed Nostr Kind 0 metadata event and publishes the new attributes directly across all active relays.

How To Operate Sales Running an anonymous, metadata-resistant storefront using this exact architecture, you use the Tor Storefront Pipeline to capture orders securely, and the Legacy Email Pipeline as your administrative notification engine. By combining your hardened onion site with nostr-mail, you can manage a business without a single byte of cleartext order data or server location leaking to the clearnet. Here is the operational blueprint for running your store: 🏢 The Operational Workflow CUSTOMER SITE VISIT ADMINISTRATOR TERMINAL [Tor Browser] [Secure Workstation] │ │ ▼ ▼

1. Pastes PGP Payload 4. nmail Syncs Relays │ │ ▼ ▼
2. Onion Service Write 5. Local NIP-44 Decryption │ │ ▼ ▼
3. Nostr DM Dispatched 6. Order Processed Offline

Step 1: The Customer's Order (Onion Side)

• The customer accesses your storefront through their Tor Browser via your .onion address.
• At checkout, the store requires them to provide a shipping address or delivery detail. To keep this safe, the customer encrypts this text locally with your Store Public PGP Key before pasting it into the form.
• The customer submits the order. Your backend runs a Parameterized Write, saving the transaction safely into the local database.

Step 2: The Silent Notification (The Bridge)

• The moment the database write succeeds, your backend server does not send an email or an outbound webhook (which would leak your IP).
• Instead, the server uses a headless script or your local nmail Engine to sign a Nostr NIP-17 Gift Wrap DM or NIP-04 Encrypted DM.
• This DM simply contains a notification message (e.g., "New Order #1084 received. Check local database.").
• The server pushes this encrypted message out to your configured decentralized Nostr relays.

Step 3: Administrative Processing (Your Side)

• On your secure terminal workstation, you open your nostr-mail application.
• Because your app is connected to the same Nostr relays, it instantly pulls down the incoming DM notifications.
• The app uses your secp256k1 private key to decrypt the notification thread locally via NIP-44.
• You log directly into your hidden server's secure admin panel over Tor (or check your mirrored DB) to pull down the raw order payload.
• You use your offline PGP private key to decrypt the customer's shipping information inside your secure terminal.

🛠️ Essential Store Security Rules To ensure your store setup remains completely secure, follow these three operational guidelines:

Rule 1: Never Mix Your Keys Keep your Nostr private key (nsec) completely separate from your master PGP key. Your Nostr key handles the automated notification routing, while your PGP key ensures that even if someone gains access to your database or Nostr relays, your customer's cleartext delivery information remains completely unreadable. Rule 2: Turn on Automatic Encryption In nostr-mail -> Settings -> Advanced Settings, turn on Automatically Encrypt and Automatically Sign using NIP-44. This ensures all communication sent back and forth between your server scripts and your administrative client is cryptaging by default. Rule 3: Enforce Local DB Backups Only Never use a cloud database sync for your sales ledgers. Keep your order tables strictly on the local loopback (127.0.0.1). If you need backups, use an offline tool to create encrypted backups, rather than streaming live data across the open internet. 📈 Running the Day-to-Day Business

• Inventory Updates: When you need to modify products, you don't use a public web portal. You connect to your hidden service through an authenticated Tor session or ssh over an onion address to update files locally.
• Customer Support: If a customer needs help, they can email your public nostrplebs address. The incoming cleartext mail hits the Public MX Relay, converts into an encrypted Nostr message via the nmail Engine, and lands safely in your nostr-mail desktop client inbox as a unified, encrypted thread.