Querying comments by author_id



So, I’m having a go at making a user profile display for commenters similar to other systems like disqus with a feed of the users comments and their basic user info.

Trouble is, querying comments ala comments(query {author_id: $id}) will return a filtered list for admins/mods and just ignores the argument for anonymous users.

I see that this is happening in the comments loader here:

  // Only let an admin request any user or the current user request themself.
  if (
    ctx.user &&
    (ctx.user.can(SEARCH_OTHERS_COMMENTS) || ctx.user.id === author_id) &&
    author_id != null
  ) {
    query.merge({ author_id });

Before I build a basically equivalent endpoint from a plugin where searching by id is allowed, I thought I’d ask if there might be a different way I should go about this.

So I think I have a few questions:

  • Why does this permission exist? Seemingly an intrepid anon could still get all of the comments and find a particular user?
  • When providing an author_id for this query and running it as an anon, shouldn’t it return a permission denied error instead of ignoring the filter and returning all comments?
  • How should I, in Talk, otherwise display a feed of comments for a particular user? Build an api endpoint/new graph type? Maybe PublicComment?


Hi Mika

I’ll let our devs point you to the right place in the code if it exists… however, there are strong design-led reasons why we didn’t build this ourselves.

We don’t allow users to see each others’ personal information (beyond when they created their account), nor a list of all their comments, because we want to make it harder to abuse, stalk, attack, and harass people on our platform.

While in the minority, we have seen some commenters follow users across a site, downvoting/replying/harassing every comment in their user history as a way of silencing them and making them feel unwelcome. In rare occasions, commenters will encourage others to do this as well. If you were to contribute such a feature to the code, we’d probably reject it for that reason.

Instead, we think a better feature would be for a commenter to ‘pin’ their favorite, say, 5 comments to a public profile. They could choose comments on threads that are already closed, or choose not to do it at all, with no real consequence. That will allow for some personalization without adding undue vulnerability.

What do you think about that idea?

Thanks for reaching out!



Hi Andrew, thanks for taking a look!

I like the user curated public comment list idea and understand how this conflicts with the Talk product vision. We’ll have to think a bit about what we’d like to do for our particular use case here. We have a heavily curated/moderated user base that is having a hard time finding one another in long comment streams to have discussions together, so a profile with a stream was our first idea.

That aside, I think part of the current behavior should be considered a bug. When a request is made against graphql with parameters the user does not have permission to use (author_id for regular/anonymous users), it should throw an insufficient permissions error rather than silently ignoring the filter and returning unfiltered results.