+## Syndication autodiscovery for comment feeds
+
+A standard `\[[!inline]]` directive adds links to the autogenerated syndication feeds using link tags in the header:
+
+ <link rel="alternate" type="application/rss+xml" title="$title" href="$page.atom" />
+ <link rel="alternate" type="application/atom+xml" title="$title" href="$page.atom" />
+
+These links aren't added to my pages that include comments even though comments generate syndication feeds. How can I configure the comments plugin to add these links to the header? (These links are required for user-agent autodiscovery of syndication feeds.) --[[anderbubble]]
+
+## Moderating comments from the CLI
+
+How do you do this, without using the UI in the Preferences?
+
+Please put this info on the page. Many thanks --[[Kai Hendry]]
+
## Why internal pages? (unresolved)
Comments are saved as internal pages, so they can never be edited through the CGI,
> have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
> should take a pagespec, so you can have postcomment(link(tags/commentable))?)
>
-> This is why `anonok_pages => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
+> This is why `anonok_pagespec => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
> are necessary to allow anonymous and logged-in editing (respectively).
>
>> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment`
>>> all directives will contine to be inexpensive and safe enough that it's
>>> sensible to allow users to (ab)use them on open wikis.
>>> --[[Joey]]
+
+----
+
+I have a test ikiwiki setup somewhere to investigate adopting the comments
+plugin. It is setup with no auth enabled and I got hammered with a spam attack
+over the last weekend (predictably). What surprised me was the scale of the
+attack: ikiwiki eventually triggered OOM and brought the box down. When I got
+it back up, I checked out a copy of the underlying git repository, and it
+measured 280M in size after being packed. Of that, about 300K was data prior
+to the spam attack, so the rest was entirely spam text, compressed via git's
+efficient delta compression.
+
+I had two thoughts about possible improvements to the comments plugin in the
+wake of this:
+
+ * comment pagination - there is a hard-to-define upper limit on the number
+ of comments that can be appended to a wiki page whilst the page remains
+ legible. It would be useful if comments could be paginated into sub-pages.
+
+ * crude flood control - asides from spam attacks (and I am aware of
+ [[plugins/blogspam]]), people can crap flood or just aggressively flame
+ repeatedly. An interesting prevention measure might be to not let an IP
+ post more than 3 sequential comments to a page, or to the site, without
+ at least one other comment being interleaved. I say 3 rather than 2 since
+ correction follow-ups are common.
+
+-- [[Jon]]
+
+
+---
+
+## Comment threads
+
+Any thoughts about implementing some simple threading in the comments?
+
+Or at least a reply functionality that quotes the subject/contents?
+
+-- [[iustin]]
+
+---
+
+## Disabling certain formats for comments
+
+It seems that comments plugin allows using all enabled formats and
+there is not way to disable some of them. For my blog, I want to use
+additional formats for writing posts but I do not want commenters to
+use those formats because it would be a security problem.
+
+Any suggestions or hints how to implement this?
+
+-- [[wentasah]]
+
+> I've implemented this. See [[todo/Restrict_formats_allowed_for_comments]].
+> --[[wentasah]]
+
+## URLs in anonymous-style comments committed directly via VCS
+
+[[!template id=gitbranch branch=schmonz/comments-anonymous-url-vcs author="[[schmonz]]"]]
+
+I recently imported my site from Textpattern into ikiwiki (using
+an `ikiwiki-import` program that may someday make its way into
+ikiwiki proper). Textpattern's comments behave much like ikiwiki's
+anonymous comments, so piping each imported comment through
+`ikiwiki-comment` and regenerating the site with `comments_allowauthor=1`
+preserved almost all the information.
+
+What's missing: if a comment directive has a `url` param, I'd expect
+the rendered page to href the author's name to that URL. This works
+as I expect for new comments added via the CGI, but not for imported
+comments added via the VCS directly.
+
+My branch has a fix that doesn't break `t/comments.t`, doesn't
+appear to break anonymous or signed-in comments via the CGI in any
+way I've tried, and lets me render my (incredibly valuable ;-)
+imported blog comments with full fidelity. OK to commit?
+
+> Ship it. --[[smcv]]
+
+>> Thanks, have done. --[[schmonz]]
+
+
+## Keeping comments separate from content to avoid triggering rebuilds
+
+Is there a way of preventing comments from triggering long chains of rebuilds? Currently comments trigger the same chain of events as if the page itself had been modified (at least this seems to be the case). A way of keeping comments lightweight and out of ikiwiki would be great. This has obvious consequences but currently comments are to slow for my users. My site is complex with tags and trails (albums) so commenting the wrong page leads to several minutes of rebuild (being conservative here...). For my use case comments don't need wikilinks or any wiki features.
+
+To my thinking it could be useful to have comments as a very lightweight type of data that enables interactivity but not the full force of ikiwiki. Any thoughts?