Comments

Comments are off until you turn them on, from the Comments page or with set_comment_settings. The newsletter needs its website on, since comments sit under each issue's page. You choose who can comment (every active subscriber, or paid subscribers only) and what waits for your review: nothing, comments with a link, or every comment. An issue can follow the newsletter or be set on or off by itself, which is also how you close a thread. An issue for paid subscribers only has a teaser page, so it has no comments.

A reader proves they are a subscriber with a signed link, not a password. The footer of an issue's email has a Discuss this issue link that signs them in on the issue's page, and {{comment_link}} puts the same link anywhere in an issue. On the web page, Sign in with your email sends a one-time link to the address, through the newsletter's own sending path: it works once and for 30 minutes, and the page it opens asks for one click so that a mail scanner can't use it up.

The answer to that form is the same for every address, subscribed or not, so it can't be used to find out who subscribes. Only an active subscriber can comment: someone who unsubscribed, bounced, complained or never confirmed can't, even with a link that still works. The link starts a session for that newsletter only, kept in a cookie for 30 days.

A comment shows a display name, never an email address. It starts as the part of the address before the @ (ana.lopez becomes Ana Lopez), and the reader can change it once, with their first comment. You, the owner, see the address next to each comment on the Comments page. Everything is stored in your account's own database, in the region you chose, and nowhere else (see Regions). When you delete a contact, their comments stay for the replies' sake as the Deleted reader's, with nothing that links them to a person.

Plain text, up to 4,000 characters, with line breaks, web addresses and links written as [words](https://address). At most 3 links. Nothing is HTML: markup a reader types is printed as typed, and only http and https links work. A reader can reply to a comment, one level deep, change their own for 15 minutes (a change is judged by your rules again, so adding a link to a comment under hold-links holds it), and delete it at any time. They can report a comment, with a reason if they like; nothing happens until you decide.

Spam is kept down without judging anyone's words: a limit on comments per reader and per network, a hidden field that bots fill in, and the same words only once on an issue. What counts as acceptable is yours to say.

• Held. A comment your settings hold waits on the Comments page with the reason it was held. Its writer sees it, marked as waiting, with the same reason.
• Hide. Takes a comment off the page and keeps it; you can approve it again. A reason is required.
• Remove. Takes it off the page for good, unless you approve it again. A reason is required.
• Block a commenter. Turns commenting off for one subscriber, with a reason they read when they try. They stay subscribed and keep getting your emails.

The author always sees the reason, on the issue's page and in an email sent the way your newsletter's other emails are (suppressed addresses and blocked accounts get none). Replies to a comment you hid stay on the page under a note.

Nothing nags. You get one email about new comments and reports an hour at most, however many come, and you can turn it off. A reader gets one email when someone replies to their comment, at most three a day, with a link that turns them off. The sign-in link and the notices about a hidden or removed comment are the only others.

list_comments, get_comment, moderate_comment, set_comment_settings, block_commenter, unblock_commenter and list_comment_reports work from the REST API and MCP. export_account_data includes each newsletter's comments as a CSV, and deleting the account deletes them.