Distillation

Date: Aug 5, 2026

• 🟡 (17:14) User asked whether the permanent fixes for the Standard.site publication/document issue had been committed to the repository.
• 🔴 (17:15) User supplied Standard.site documentation, including the site.standard.graph.subscription lexicon, site.standard.authFull and site.standard.authSocial permission sets, publication/document verification requirements, and extensibility guidance.
• 🟡 (17:15) User asked how difficult it would be to create a mailing list using AT Protocol and Standard.site specifications.
• 🟡 (17:16) Assistant distinguished two products: an AT Protocol subscription feed versus a conventional email newsletter.
• 🟡 (17:16) Assistant explained that site.standard.graph.subscription stores a reader-to-publication relationship as a record in the reader’s own PDS; required property is publication (an AT-URI), with optional createdAt datetime. Example publication URI referenced: at://did:plc:kl3s4yablm3fgnxfkn47uy5r/site.standard.publication/27wwoxjyk66jt.
• 🟡 (17:16) Assistant outlined AT Protocol subscription implementation steps in order: add a “Subscribe with AT Protocol” flow; authenticate readers with AT Protocol OAuth; request OAuth scope include:site.standard.authSocial; create/delete site.standard.graph.subscription records in the reader’s PDS; add a reader-facing UI or rely on existing Standard.site clients; keep the publication record discoverable and stable.
• 🟡 (17:16) Assistant stated that AT Protocol subscriptions do not expose readers’ email addresses and AT Protocol does not send email.
• 🟡 (17:16) Assistant listed conventional email-newsletter requirements: email collection form; double opt-in and unsubscribe handling; consent records and retention rules; delivery provider such as Buttondown, Loops, Mailchimp, ConvertKit, or Amazon SES; job detecting new site.standard.document records; templates; bounce handling; rate limits; delivery monitoring.
• 🟡 (17:16) Assistant recommended a combined architecture: retain site.standard.publication and site.standard.document; add AT Protocol subscriptions for portable app-based follows; add a separate email signup; continue publishing through the existing GitHub Actions workflow; after successful publication, trigger the email provider with the generated document URL and content; keep email addresses outside the public AT Protocol repository.
• 🟡 (17:16) Assistant estimated an initial Astro-site implementation using an existing email provider at a day or two, while a production-ready self-hosted system with AT Protocol OAuth, email delivery, consent management, and reliable retries would take several days to a couple of weeks.
• 🟡 (17:16) Assistant’s architectural distinction: site.standard.graph.subscription is a portable social follow; an email mailing list is a private contact-and-delivery system; both can use the same publication/document source but are not interchangeable.