Docs Dashboard Sign in

Comments and reactions

Every share carries a comments section and a row of reaction buttons below the body. Both are off-by-default-ish: they are present, but only signed-in users can post or react. Anonymous visitors see them and are redirected to sign in if they try to interact.

Comments#

Each comment shows:

  • The author's username.
  • A relative timestamp (e.g. "3 hours ago"), with the ISO timestamp on hover, plus an "(edited)" tag if it has been changed since.
  • The body, rendered as plain text (URLs are auto-linked; nothing else is parsed).
  • A reaction bar under the comment.
  • A resolved badge naming whoever marked it handled, when it has been resolved.

Posting#

Two ways in, and they produce the same comment.

On a specific passage. Select text in the document. A Comment on selection button appears; clicking it opens a small composer beside the selection — in the right gutter where the window is wide enough, as a bottom sheet on a phone. The page does not move, and the passage you picked stays highlighted while you type, so you can still see what you're commenting on. Esc, Cancel, or a click outside dismisses it and leaves nothing behind. The posted comment gets an underline in the text and a pin beside the paragraph.

On the document as a whole. Scroll below the share body, type into the textarea, click Comment. This is also the path with JavaScript disabled.

Either way you must be signed in. An anonymous visitor clicking Comment lands on the sign-in card, which offers both Google and a magic link — recipients without a Google account are not locked out — and returns to the share afterwards.

What you can and can't do#

  • Plain text only. Markdown, HTML, and other formatting are not rendered. URLs are auto-linked.
  • Edit your own. Editing is author-scoped; the share render tags an edited comment so recipients can tell.
  • Delete your own — and, as the share owner or an org admin, anyone's comment on your document. Deletes are soft: the row is kept so reactions and the forensic trail survive, and it disappears from every view immediately. Moderating someone else's comment writes a comment.moderate_delete entry to the org audit log. A share-level editor deliberately cannot moderate — they can change the document, not police the discussion.
  • Reply to a comment. A reply is recorded against the comment it answers and renders indented under it. One level only: this exists so "that edit addressed this feedback" lands next to the feedback, not as a general threading model.
  • Resolve a comment. Anyone who can comment on the share can mark one handled, and un-resolve it again. Resolving is bookkeeping, not removal — the comment still renders and keeps its reactions; it just wears a badge and recedes.

Length#

Comments are capped at 2,000 characters per body. Submitting a longer one returns a 400 with the validation error.

Closing the loop from the CLI or an agent#

This is the half of the review cycle that used to be missing: an agent could read every comment on a document and apply them, but had no way to report back, so the threads stayed open and a human had to reconcile them by hand.

anchorify comments my-deliverable                       # ids + resolved state
anchorify comments reply   my-deliverable --id <id> --body "Fixed in the latest publish."
anchorify comments resolve my-deliverable --id <id>
anchorify comments edit    my-deliverable --id <id> --body "..."
anchorify comments delete  my-deliverable --id <id>

MCP clients get the same five as tools (anchorify_comments_list, anchorify_comment_add, anchorify_comment_reply, anchorify_comment_resolve, anchorify_comment_edit, anchorify_comment_delete). The HTTP shapes are in the API reference.

There is no bulk resolve, on purpose — per-comment only, so an agent can't blanket-close threads it didn't address.

Reactions#

Reactions are six emoji buttons, available on:

  • The share itself, in a bar between the body and the comments section.
  • Each comment, immediately below the comment body.

The six emojis are: 👍 👎 😄 🎉 😕 ❤️.

How it works#

Click a button to add your reaction; click it again to remove it. The count on each button is the total across all signed-in users. The button has a pressed state when you have reacted with that emoji.

Reactions are signed-in only. Clicking a button as an anonymous visitor sends you to /auth/google with a return URL back to the share. After sign-in, the page reloads with you authed; click the button again.

A single user can react to a target with multiple emojis (e.g. both 👍 and ❤️), but only once per emoji per target.

Where reactions appear#

  • Share-level reactions — between the share body and the comments section. One bar per share.
  • Comment-level reactions — under each comment. One bar per comment.

The same client-side handler drives both bars.

Disabling comments or reactions#

There is no per-share toggle to disable comments or reactions today. Every share has both. A per-share opt-out is on the roadmap but not yet built.

Next steps#

  • Web dashboard — where comments and reactions appear in the owner's view.
  • REST API — POST /api/v1/shares/:id/comments, POST /api/v1/reactions.