Distillation

Date: Aug 5, 2026

• 🟡 (17:18) Assistant explained the proposed architecture: Standard.site publication discovery and document source → user’s service for tenants, consent, scheduling, rendering, orchestration → Loops for contacts, campaigns, delivery, unsubscribe, and suppression.
• 🟡 (17:18) Assistant identified Standard.site capabilities: publication discovery through site.standard.publication, post discovery through site.standard.document, portable social subscriptions through site.standard.graph.subscription, and OAuth scopes for reading/managing Standard.site records.
• 🟡 (17:18) Assistant advised keeping email identity and consent in the private service and Loops rather than storing email addresses publicly in AT Protocol.
• 🟡 (17:18) Assistant proposed mapping each publication to a Loops mailing list using publication AT-URI -> your publication record -> Loops mailing list ID.
• 🟡 (17:18) Assistant identified Loops multi-tenancy as a key limitation: API keys belong to a Loops team, so using one service-owned key for every publisher would combine contacts and sending activity in one account unless deliberately accepted.
• 🟡 (17:18) Assistant evaluated multi-tenant credential approaches: preferred model is for each publisher to connect their own Loops account, authorize the service if suitable account-level integration exists, and have the service store encrypted publisher credentials; fallback is publisher-supplied API keys for an MVP, which is workable but less pleasant and harder to secure.
• 🟡 (17:18) Assistant recommended an email-first MVP rather than inferring email consent from AT subscriptions. Ordered flow: 1. publisher enters a publication AT-URI; 2. service resolves and verifies it; 3. publisher connects Loops; 4. service creates a publication mailing list; 5. service provides an embeddable signup form; 6. reader submits an email; 7. service creates a Loops contact with double opt-in; 8. service periodically discovers new site.standard.document records; 9. publisher approves or schedules a campaign; 10. service creates and sends the campaign through Loops; 11. Loops webhooks update delivery, unsubscribe, and suppression state.
• 🟡 (17:18) Assistant recommended adding AT Protocol integration later: reader signs in with AT Protocol OAuth, creates a site.standard.graph.subscription record in their own PDS, and the service optionally associates it with an email address after explicit consent.
• 🟡 (17:18) Assistant distinguished AT Protocol follows from email subscriptions: readers should be able to unsubscribe socially, by email, or both, but an AT Protocol follow must not silently become an email subscription.
• 🟡 (17:18) Assistant listed remaining hard problems after adopting Loops: multi-tenant authentication and credential isolation; reliable publication/document discovery; duplicate-send prevention during polling/retries; campaign approval/scheduling; double-opt-in and unsubscribe semantics; deleted/edited document handling; safe rendering of arbitrary Standard.site documents; publisher ownership verification; abuse prevention; and rate limiting.
• 🟡 (17:18) Assistant recommended publisher approval before sending rather than automatic sends when documents appear, because external documents may be malformed, accidental drafts, or content the publisher did not intend to email.
• 🟡 (17:18) Assistant estimated effort: proof of concept for one publication and one Loops account, 1 to 3 days; small multi-publication MVP with signup, campaigns, retries, and webhooks, 1 to 2 weeks; production multi-tenant service with OAuth, billing, abuse controls, audit logs, and robust AT event processing, several weeks to a few months.