Distillation

Date: Aug 5, 2026

• 🟡 (17:22) User asked how to build the Standard.site publication-to-email service using Amazon SES instead of Loops.
• 🟡 (17:23) Assistant explained that Amazon SES is primarily an email delivery backend, unlike Loops, so the service must implement publication registration and verification, subscriber storage, double opt-in, unsubscribe and preference pages, campaign creation and scheduling, idempotent send tracking, HTML/plain-text rendering, bounce and complaint processing, abuse prevention, tenant isolation, audit logs, and delivery status.
• 🟡 (17:23) Assistant stated SES handles HTML/plain-text sending, delivery retries, bounces, complaints, suppression handling, sending quotas, reputation metrics, open/click events through configuration sets, and domain authentication through DKIM and custom MAIL FROM.
• 🟡 (17:23) Assistant proposed an AWS architecture: Standard.site records → publication discovery service → DynamoDB for subscribers, consent/confirmation tokens, sent-document records, and tenant configuration → Amazon SES SendEmail/SendBulkEmail with a configuration set → SNS or EventBridge events → SQS/Lambda processing for bounces, complaints, deliveries, opens, and clicks.
• 🟡 (17:23) Assistant recommended the publication workflow: submit a Standard.site publication AT-URI; resolve it and verify its .well-known endpoint; store the publication URI as the tenant’s stable identifier; discover site.standard.document records; configure sender and reply-to addresses; collect reader subscriptions; send confirmation through SES; activate only confirmed subscribers; create a campaign for each new document; require publisher approval initially; send one email per recipient or use SES bulk sending; record document AT-URI plus recipient version to prevent duplicate sends; and suppress bounced or complained addresses.
• 🟡 (17:23) Assistant listed SES setup steps: choose one SES region consistently; verify the sender email or sending domain; add DKIM DNS records; configure a custom MAIL FROM domain; request production access because new accounts usually begin in the SES sandbox; create a configuration set; route bounce, complaint, delivery, and subscription events through SNS, EventBridge, or Kinesis; place events onto SQS before processing; add CloudWatch alarms for bounce and complaint rates; and configure account-level sending limits plus per-tenant quotas.
• 🟡 (17:23) Assistant advised starting multi-tenant sending with one verified sender domain such as newsletter@yourservice.example, using the publication owner’s address as Reply-To; later options are publisher-owned sending domains or bring-your-own-AWS-account.
• 🟡 (17:23) Assistant identified SES multi-tenant risks: arbitrary users must not send from arbitrary domains through the shared SES account; every publication, campaign, and subscriber query must be scoped by internal tenant ID; a publication AT-URI is an identifier rather than proof of ownership; sending requires domain verification or authenticated publisher identity; tenants must not select another tenant’s campaign or subscriber list; publication discovery, signup, and sending require rate limits; new tenants need recipient and campaign caps; unsubscribe state must remain authoritative in the private database; email addresses must not be placed in AT Protocol records.
• 🟡 (17:23) Assistant identified shared SES reputation as the main operational risk: a customer importing a poor-quality list or sending unwanted mail could damage the shared SES account; mitigation requires approval, throttling, complaint monitoring, and eventually separate SES accounts or sending pools.
• 🟡 (17:23) Assistant compared SES and Loops: SES offers excellent delivery, lower cost at scale, greater control, and less AWS-provider lock-in, but requires building contact management, double opt-in, unsubscribe handling, campaign editing, bounce processing, and multi-tenancy; Loops includes those product features and has lower AWS complexity but higher cost and less control.
• 🟡 (17:23) Assistant estimated effort for SES: 2 to 4 days for a single-publication proof of concept; 2 to 4 weeks for a usable service with signup, confirmation, unsubscribe, document polling, and SES sending; and 1 to 3 months for production multi-tenant functionality with abuse controls, publisher verification, event processing, scheduling, and billing.
• 🟡 (17:23) Assistant recommended an initial AWS stack: Lambda or a small Node service for the API; DynamoDB for tenants, subscribers, consent, campaigns, and send history; SES v2 for email; SQS for sending jobs and SES event processing; EventBridge Scheduler for publication polling and scheduled sends; Secrets Manager for SES credentials and signing secrets; and CloudWatch for quotas, errors, bounce rate, and complaint rate.
• 🟡 (17:23) Assistant defined the responsibility boundary: AT Protocol and Standard.site are the public publication source; the private service owns tenants, consent, campaigns, rendering, and orchestration; Amazon SES provides email transport and delivery signals.
• 🟡 (17:23) Assistant concluded that SES is preferable for control and low per-email cost when the builder is prepared to operate newsletter infrastructure, while Loops is preferable when the product’s primary value is Standard.site integration rather than email infrastructure.