What Visitors Need to Comment with utterances

Updated

To comment through the utterances widget, a visitor needs a GitHub account and must authorize the utterances app via GitHub OAuth so it can post on their behalf. As an alternative, they can skip the widget entirely and comment directly on the GitHub issue that backs the page. Both paths require a GitHub account; there is no anonymous or non-GitHub commenting option described.

The two commenting paths

1. Comment through the widget (OAuth)

When a visitor types into the comment box on your site, utterances triggers the GitHub OAuth flow. The visitor signs in to GitHub and grants the utterances app permission to post comments on their behalf. After that, their comment appears both in the widget and in the corresponding GitHub issue.

What the visitor experiences:

  • A prompt to sign in to GitHub, or to authorize the utterances app if they are already signed in.
  • A consent screen listing the permission being granted (posting on their behalf).
  • Return to your page, where the comment is submitted.

2. Comment directly on the GitHub issue

Every page's comment thread is a GitHub issue. A visitor who prefers not to authorize the app can open that issue on GitHub and comment there with their normal GitHub account. The comment will show up in the widget the next time the thread loads, because the widget reads from the issue.

This path is useful for visitors who are cautious about granting OAuth permissions to third-party apps, or who are already browsing GitHub.

What happens on a page with no comments yet

The first commenter does not need to create anything manually. When utterances loads, it searches GitHub issues for one matching the page by url, pathname, or title. If no matching issue exists, utterances-bot creates one automatically the first time someone comments. So the visitor's only job is to authorize and post; issue creation is handled for them.

Requirements at a glance

Requirement Widget path Direct-on-GitHub path
GitHub account Yes Yes
Authorize utterances app (OAuth) Yes No
Create the issue manually No (bot does it) No (bot does it)
Comment appears in the widget Yes Yes, on next load

Practical notes for site owners

  • Expect a sign-in step. Visitors without a GitHub account cannot comment through the widget. If your audience is unlikely to have GitHub accounts, utterances may not fit; the site describes it as built on GitHub issues with no lock-in, and all data lives in GitHub issues.
  • The OAuth prompt is the main friction point. Some visitors will abandon at the authorization screen. Offering a visible link to the underlying GitHub issue gives them a second route.
  • Moderation happens on GitHub. Since comments are issues, you manage them with GitHub's own tools rather than a separate dashboard.
  • No tracking or ads. The project states it uses no tracking and no ads and is always free, which is relevant if visitors ask what the authorization is used for: it is for posting comments, not for analytics.

Common sticking points

  • "I commented but it didn't appear." If the visitor commented directly on GitHub, the widget may need a reload to pick up the new comment.
  • "The sign-in page looks unfamiliar." It is GitHub's standard OAuth consent screen; the visitor is granting the utterances app permission to post on their behalf, not handing over their password.
  • "There's no comment box." The widget only renders where the site owner has installed the script; if it is missing, commenting through the page is not possible, though the GitHub issue may still exist.