YAMN Web 2 | Nym before YAMN
Description: YAMN Web 2 architecture: a Nym-before-YAMN send-only interface for email and Usenet messages.

Architecture note / send-only gateway

# Nym before YAMN.

The browser sends the form to this host over HTTPS or the Onion service. PHP then runs the local `yamn-encode` program, which creates the encrypted YAMN v2 packet in server memory before Nym transport starts.

Nym-first transport YAMN v2 envelope Email + Usenet Send-only

## Where YAMN encryption happens

It happens locally on the YAMNWeb host, before the message enters Nym. It does not happen in the browser, in JavaScript, in Apache, or in Nym.

### 1. Browser

The browser sends the form fields, including the message body, to YAMNWeb through HTTPS or the Onion service. The page contains no JavaScript cryptography and does not hold YAMN remailer keys.

### 2. Local encoder

Apache serves PHP. PHP validates the request and starts the local Go binary `yamn-encode`. That binary reads the selected remailers' public keys and creates the encrypted YAMN envelope in RAM on this host.

### 3. Nym transport

Only after encoding, PHP starts the local Rust Nym sender. It receives the finished armored YAMN envelope and the selected Entry address needed by the Nym relay service, not separate form fields.

This is server-side encryption, not browser-side end-to-end encryption. The plaintext exists in the PHP process and in `yamn-encode` memory while the packet is being built. The message becomes opaque to Nym only after the local YAMN encoder has finished.

## The active path

This diagram names the actual components. Apache is the web server, PHP is the application runtime, and `yamn-encode` is the local program that performs YAMN encryption.

01 / BROWSER

### Compose

No YAMN encryption or crypto JS

02 / APACHE + PHP

### Receive

Plaintext reaches PHP on this host

03 / GO ENCODER

### Encrypt

Builds YAMN v2 envelope in RAM

04 / NYM

### Mix

Carries envelope to the relay service

05 / RELAY SERVICE

### Forward

Reads Entry address, not message contents

06 / YAMN

### Open layers

Entry, Middle, Exit

    Browser -- HTTPS or Onion --> Apache + PHP -- plaintext in RAM --> local Go yamn-encode
            -- encrypted YAMN envelope --> Rust Nym sender --> Nym mixnet
            --> Nym relay service --> YAMN Entry --> Middle --> Exit --> SMTP or Mail-to-News

## Where Tor fits

### Onion interface

The existing Onion address provides an alternate way to reach the same web interface. It does not change the message format or create a second delivery protocol. The public HTTPS and Onion interfaces serve the same application.

### Remailer data

Tor is used for remailer statistics and public-key material downloads, with Victor's Echolot pinger as the primary configured source and fallback pingers when needed.

The message submission path is Nym-first after local YAMN encoding. On this host, PHP calls `yamn-encode`; that local program encrypts the message. PHP then gives Nym the opaque envelope and its selected Entry address. The Nym relay service receives the envelope and forwards it to that Entry.

The relay service can read the Entry address because it must choose the SMTP destination, but it cannot open the YAMN message or its next-hop headers. In the current deployment, it uses a Tor SOCKS connection for this SMTP leg to the YAMN Entry. This is separate from the browser-to-service transport.

## Cryptographic layers

YAMN uses hybrid cryptography: asymmetric encryption protects the instruction header for each remailer, while fresh symmetric keys encrypt the bulk packet layers. The Nym SDK is a separate transport layer with its own network cryptography.

- NaCl boxOne header is encrypted to the public key of every selected remailer, Entry, Middle, and Exit. Only the holder of that remailer's private key can open its header. It uses Curve25519 authenticated public-key encryption with XSalsa20-Poly1305.
- AES-256-CTRFresh, random symmetric keys encrypt the packet payload and intermediate header slots in nested layers. This is efficient for the fixed-size packet; the corresponding AES key is placed inside the header that only the relevant remailer can open.
- BLAKE2s-256Anti-tags and packet digests detect altered or incorrectly layered packet data.
- Random per messageKeys, IVs, packet identifiers, nonces, padding bytes, and header values are generated for each envelope.
- Transport boundaryThe Nym sender accepts the armored YAMN envelope and the selected Entry address needed by the Nym relay service. It does not receive the message fields separately.

## How a message is layered and opened

Yes: the completed packet is addressed first to the selected YAMN Entry. However, it already contains encrypted instructions for the Middle and Exit. Nym and the relay service do not decrypt YAMN; each remailer opens only the part intended for its role.

### 1. Building the packet

The encoder reads the selected Entry, Middle, and Exit public keys from the local keyring. It places the SMTP message in a fixed-size packet, encrypts it for the Exit with a fresh AES key, then wraps it in additional AES layers for the Middle and Entry.

It adds one public-key-encrypted header per remailer. The Entry header says how to reach the Middle and contains the key for the Entry layer; the Middle header similarly leads to the Exit; the Exit header contains the final AES key needed to recover the SMTP message.

### 2. Opening one step at a time

The relay service submits the finished packet to the selected Entry over SMTP. The Entry uses its private key to open only its header, learns the Middle address and the AES key for its outer layer, removes that layer, and forwards the packet.

The Middle repeats the operation for the Exit. Neither Entry nor Middle has the private key needed to open another remailer's header, and neither receives the final plaintext message.

### 3. Final delivery

The Exit opens the last header, verifies the packet integrity data, and uses the final AES key and initialization vector to recover the original SMTP message.

The Exit then delivers that ordinary message to the email recipient or to the configured Mail-to-News service. The final recipient does not need a YAMN key or special software.

Nym does not decrypt the message. Nym carries the already layered YAMN packet to the server-side relay service. The YAMN remailers perform the sequential opening, and the Exit is the component that turns the packet back into an SMTP message.

## YAMN chain and destinations

### Three YAMN roles

- Entry receives the packet and removes the first layer.
- Middle forwards the still-layered packet.
- Exit removes the final layer and delivers through SMTP.

The `*` option selects an available remailer from the local statistics list.

### Email or Usenet

For email, the selected recipient is placed inside the encrypted message. For Usenet, the selected newsgroup is preserved and the server-configured Mail-to-News recipient performs SMTP-to-NNTP conversion.

References accepts one or more Message-IDs and links the article to an existing Usenet thread. The last Message-ID is also emitted as In-Reply-To. The separate Reply-To field is an optional email response address; neither field enables message retrieval in this send-only service.

## Data handling and limits

### Kept minimal

- The message and encrypted envelope are held in memory by the submission route.
- The Nym client keeps only technical transport state.
- The public keyring and remailer statistics are service data.
- The web session stores CSRF and minimum request state.

### Send-only by design

There is no inbox, message fetching, message viewing, or reply retrieval. Acceptance by the Nym sender confirms that transport started, not that a remailer delivered the message.

YAMN remailer queues may introduce delays of several hours, especially for Usenet publication.

Privacy still depends on use. Message wording, timing, recipient choice, browser state, and operational mistakes can reveal information outside the cryptographic packet. Do not submit passwords, private keys, or data that must not leave your device.