This document specifies the architecture, cryptographic layers, and transport mechanisms comprising the AfterSMTP platform representing the next-generation messaging standard (AMP).

1. Decentralized Identity (DID) and Cryptography

Every participant (user, server, automation service) in the AfterSMTP ecosystem operates under a Decentralized Identifier (DID) formatted as did:aftersmtp:<domain>:<user>. Example: did:aftersmtp:msgs.global:ryan

Identities are independent of any single centralized registrar, shifting identity mapping onto an immutable Substrate/Merkle-based blockchain transparency log.

Key Matrices

Each identity possesses two discrete keypairs linked immutably to their DID on the ledger: - Ed25519 (Signing Key): Used exclusively to construct cryptographic signatures confirming message authorship and preventing spoofing. - X25519 (Encryption Key): Used exclusively to construct End-to-End Encrypted ciphertexts between two DIDs.

DNS Integration (The Genesis Mapping)

While the blockchain layer (ledger) maintains the ultimate truth of identity keys, domains utilize standard DNS TXT records to designate their primary AfterSMTP Gateways. - To bridge legacy environments, _aftersmtp._tcp.msgs.global. IN TXT "v=aftersmtp1; p=amp.msgs.global:4433" tells external realms how to route AMP traffic for a domain before falling back to the ledger directly. - The platform also rigidly enforces DNSSEC and DANE (TLSA) records over standard UDP/TCP DNS queries to ensure that out-of-band TLS connections cannot be intercepted by rogue intermediate MX gateways.

2. Server Architecture

The AfterSMTP Gateway acts as a highly-concurrent monolithic application. It multiplexes streams of data on three discrete protocols:

A. The QUIC Transport (Native AMP)

Riding over UDP port 4434, the server implements a native HTTP/3 (QUIC) multiplexer. - Zero-Trust: Mutual authentication of identities. - Speed: Stream-based deliveries bypassing standard TCP handshake latency (0-RTT), essential for cross-global encrypted node meshing. - Packets are serialized AMPMessage Protobuf structures immediately validated against the Ledger.

B. The gRPC Streaming Transport (Enterprise Ingress)

Riding over TCP port 4433 using TLS 1.3, this satisfies standard enterprise load-balancing environments (Envoy/Nginx) that strictly command HTTP/2 ingress.

C. The Proof of Transit Consensus

All inbound messages on either transport are routed to the Core Engine. Following successful cryptographic signature verification and decryption policy checks, a mathematical Hash of the message transmission is submitted directly to the Substrate Blockchain as an extrinsic block (similar to a smart-contract transaction). This Proof prevents deniability.

3. The Client Implementation

Clients interact natively with AfterSMTP utilizing the aftersmtp-cli commands, or by adopting the generated Go, Python, and Node SDKs (located in library/).

The E2E Sending Flow: 1. Resolution: Client queries the decentralized Ledger resolving did:aftersmtp:target:user yielding their X25519 encryption key. 2. Key Exchange: Client generates an ephemeral X25519 key and uses Diffie-Hellman (ECDH) against the recipient's public key to create a symmetric Shared Secret. 3. Sealing: Client converts the payload into an AMFPayload Protobuf and encrypts it utilizing AES-GCM-256 under the Shared Secret. 4. Signature: Client seals the encrypted payload, attaching a Ed25519 cryptographic signature over the metadata (timestamp, id, sender rules) via their private key. 5. Dispatch: Client writes the bytes to the gRPC stream.

The Verification Flow: Upon receiving a message, a node immediately drops the payload unless the mathematical signature (crypto.Verify(SenderPubKey, Payload, Signature)) aligns completely with the Sender DID's public key registered firmly on the blockchain ledger.

Legacy SMTP

For interoperability with external systems incapable of deciphering AMP (e.g. Gmail), refer to the /INTEGRATION.md.